Una de las características interesantes de PostgreSQL desde la versión 9.4 es la capacidad de controlar la eliminación de archivos WAL mediante ranuras de replicación. El lado oscuro es que las ranuras de replicación pueden hacer que los discos se llenen con WAL antiguo, matando al servidor de producción principal. En este artículo explico las ranuras de replicación de PostgreSQL y cómo una nueva función en PostgreSQL 13 ayuda a prevenir este problema.

Producción WAL

Como sabe, WAL se produce para cambios de base de datos en un servidor primario:inserciones, actualizaciones, etc. . Una base de datos más activa producirá más WAL:en un servidor muy activo, se pueden producir muchos gigabytes de WAL por minuto. WAL se escribe en archivos con nombres en una secuencia numérica creciente, y los archivos siempre tienen el mismo tamaño (16 MB es el predeterminado y típico). Una vez que los datos de un archivo ya no son necesarios, ese archivo se puede reciclar , lo que significa cambiarle el nombre a una posición con un número más alto en la secuencia para que pueda llenarse con nuevos datos más tarde.

(Hay situaciones especiales, como un aumento en la actividad que conduce a la creación de archivos adicionales; cuando más tarde el aumento disminuye, esos archivos adicionales se eliminan en lugar de reciclarse).

Debido a que toda la actividad de escritura de la base de datos produce WAL, es fundamental que haya espacio disponible en el disco. Cuando el disco que almacena WAL está lleno, el servidor no podrá procesar nuevas transacciones y puede atascarse, o peor aún:puede caerse por completo. Así que esta es una situación que debe evitarse por todos los medios posibles.

Ranuras de replicación

La replicación en PostgreSQL funciona mediante el procesamiento de archivos WAL. Para que esto funcione, todos los archivos WAL deben estar disponibles de forma transitoria hasta que se procesen. Por lo tanto, se necesita un mecanismo para decirle a la administración principal de WAL que no recicle ni elimine archivos.

Introduzca las ranuras de replicación. Las tragamonedas son un mecanismo que indica que este la copia de seguridad que estamos realizando requerirá eso WAL, y por favor no lo elimine todavía; o esto la réplica aún no ha procesado eso WAL, entonces, ¿pueden dejarlo solo por un rato?

Por sí mismas, las ranuras de replicación ocupan muy poco espacio en disco. Solo almacenan una pequeña cantidad de metadatos, incluido un puntero a una posición en WAL. Pero los datos WAL que protege son otra cosa:en un servidor muy activo, se pueden medir en gigabytes o peor.

Consumo WAL

Alimentar datos a una réplica física significa copiar los datos WAL de su servidor principal. De manera similar, una réplica lógica necesita leer datos WAL (y transmitir una versión interpretada a la réplica). La posición WAL que se lee es lo que la ranura realiza un seguimiento. Una vez que la réplica ha asegurado los datos WAL de alguna manera, la ranura se puede avanzar; esto le dice a la administración de WAL en el primario que el archivo WAL está disponible para su eliminación. Esto sucede continuamente cuando la réplica está activa, por lo que WAL en el servidor principal utilizará la misma cantidad de espacio en disco o quizás solo un poco más. Incluso el doble o diez veces más podría ser aceptable, dependiendo de las condiciones.

El problema es que si una réplica muere por completo y no se recupera durante un largo período de tiempo; o la réplica se destruye y el DBA se olvida de quitar la ranura de replicación; o la ranura es un remanente olvidado de algún experimento; o incluso la réplica se alimenta a través de un enlace de red lento, entonces el WAL reservado crecerá sin límites. Y eso se convierte en una bomba de tiempo.

Limitación del tamaño de la ranura

Para combatir este problema, Kyotaro Horiguchi había estado trabajando desde febrero de 2017 en un parche de PostgreSQL para limitar el tamaño de WAL reservado por una ranura. Después de un proceso de revisión y reelaboración muy largo, lo integré para PostgreSQL 13, mejorando la administración de las granjas de PostgreSQL de alta disponibilidad.

El principio principal es que es mejor eliminar una réplica (haciendo que su ranura no sea válida de alguna manera; más sobre eso a continuación) que eliminar el servidor principal que alimenta esa réplica y acabar con toda la producción.

La forma en que funciona es bastante sencilla:configure max_slot_wal_keep_size (documentación) en postgresql.conf a la cantidad máxima de espacio en disco de WAL que las ranuras de replicación pueden reservar. Si una ranura llega a ese punto y se produce un punto de control, esa ranura se marcará como no válida y es posible que se eliminen algunos archivos WAL. Si la ranura estaba en uso activo por un walsender proceso, ese proceso será señalado para que termine. Si walsender comienza de nuevo, encontrará que los archivos WAL necesarios ya no estarán allí. La réplica que usa esa ranura deberá volver a clonarse.

Si max_slot_wal_keep_size es cero, que es el valor predeterminado, entonces no hay límite. No recomiendo esto, porque conduce a fallas cuando las ranuras llenan el disco.

Supervisión del estado de las ranuras

También se incluyen algunas características de monitoreo. Dos columnas en pg_replication_slots son relevantes. El más crítico es wal_status . Si esa columna está reserved , entonces la ranura apunta a datos dentro de max_wal_size; si es extended luego excedió max_wal_size , pero todavía está protegido por wal_keep_size o max_slot_wal_keep_size (incluido cuando max_slot_wal_keep_size es cero). Cualquier estado es bueno y normal. Sin embargo, cuando un espacio supera el límite, primero se convierte en unreserved , lo que significa que está en peligro inminente, pero aún puede recuperarse si es lo suficientemente rápido. Finalmente, el estado se vuelve lost cuando los archivos WAL se han eliminado y no es posible recuperarlos.

La otra columna es safe_wal_size :muestra la cantidad de bytes de WAL que se pueden escribir antes de que esta ranura corra el peligro de que se eliminen los archivos WAL. Le sugerimos que vigile de cerca esta columna en su sistema de monitoreo y active alertas cuando esté baja. Cero o negativo significa que su réplica estará muerta tan pronto como ocurra un punto de control:

SELECT slot_name, active, wal_status, safe_wal_size
  FROM pg_catalog.pg_replication_slots;

Creemos que esta nueva característica hace que el mantenimiento de las réplicas sea más fácil y robusto; esperemos que no veamos más desastres con la producción caída debido a estos problemas.

(Una nota:safe_wal_size se introdujo en 13beta3, así que asegúrese de consultar la documentación actualizada, o verá min_safe_lsn en cambio. Ignóralo.)

Gracias

Un agradecimiento especial a Kyotaro Horiguchi por trabajar para resolver este problema. Varios revisores profundizaron en esto, entre los cuales me gustaría agradecer especialmente a Masahiko Sawada, Fujii Masao, Jehan-Guillaume de Rorthais y Amit Kapila (sin ningún orden en particular).