pg_rewind — sincroniza un directorio de datos de PostgreSQL con otro directorio de datos que se bifurcó de él
pg_rewind [option...] { -D | --target-pgdata } directory { --source-pgdata= | directory--source-server= } connstr
pg_rewind es una herramienta para sincronizar un clúster de PostgreSQL con otra copia del mismo clúster, después de que las líneas de tiempo (timelines) de los clústeres se hayan bifurcado. Un escenario típico es volver a poner en línea un antiguo servidor primario después de una conmutación por error (failover) como un servidor en espera (standby) que sigue al nuevo primario.
Después de una rebobinación (rewind) exitosa, el estado del directorio de datos de destino es análogo a una copia de seguridad base (base backup) del directorio de datos de origen. A diferencia de realizar una nueva copia de seguridad base o usar una herramienta como rsync, pg_rewind no requiere comparar o copiar bloques de relación que no hayan cambiado en el clúster. Solo se copian los bloques cambiados de los archivos de relación existentes; todos los demás archivos, incluidos los nuevos archivos de relación, los archivos de configuración y los segmentos WAL, se copian en su totalidad. Por lo tanto, la operación de rebobinado es significativamente más rápida que otros enfoques cuando la base de datos es grande y solo una pequeña fracción de los bloques difiere entre los clústeres.
pg_rewind examina los historiales de líneas de tiempo de los
clústeres de origen y destino para determinar el punto en el que se bifurcaron, y espera
encontrar WAL en el directorio pg_wal del clúster de destino que llegue
hasta el punto de bifurcación. El punto de bifurcación se puede encontrar en la línea de tiempo de
destino, en la línea de tiempo de origen o en su ancestro común. En el escenario típico de
conmutación por error en el que el clúster de destino se apagó poco después de la bifurcación,
esto no es un problema, pero si el clúster de destino se ejecutó durante mucho tiempo después
de la bifurcación, es posible que sus archivos WAL antiguos ya no estén presentes. En este
caso, puedes copiarlos manualmente desde el archivo WAL al directorio pg_wal,
o ejecutar pg_rewind con la opción -c para
recuperarlos automáticamente desde el archivo WAL. El uso de pg_rewind
no se limita a la conmutación por error; por ejemplo, un servidor en espera puede promoverse,
ejecutar algunas transacciones de escritura y luego rebobinarse para convertirse en un servidor
en espera de nuevo.
Después de ejecutar pg_rewind, debe completarse la reproducción
de WAL para que el directorio de datos quede en un estado consistente. Cuando el servidor de
destino se inicie de nuevo, entrará en recuperación de archivos (archive recovery) y reproducirá
todo el WAL generado en el servidor de origen desde el último punto de control (checkpoint) antes del
punto de bifurcación. Si parte del WAL ya no estaba disponible en el servidor de origen cuando se
ejecutó pg_rewind y, por lo tanto, no pudo ser copiado por la
sesión de pg_rewind, debe estar disponible cuando se inicie el
servidor de destino. Esto se puede hacer creando un archivo recovery.signal
en el directorio de datos de destino y configurando un comando adecuado con
restore_command en postgresql.conf.
pg_rewind requiere que el servidor de destino tenga habilitada la
opción wal_log_hints en postgresql.conf o las sumas
de comprobación de datos (checksums) habilitadas cuando el clúster se inicializó con
initdb (el valor predeterminado). full_page_writes
también debe estar configurado en on, aunque está habilitado por defecto.
Si pg_rewind falla mientras se procesa, es probable que la carpeta de datos del destino no quede en un estado que se pueda recuperar. En tal caso, se recomienda realizar una nueva copia de seguridad desde cero.
Dado que pg_rewind copia los archivos de configuración en su totalidad desde el origen, puede ser necesario corregir la configuración utilizada para la recuperación antes de reiniciar el servidor de destino, especialmente si el destino se reintroduce como un servidor en espera del origen. Si reinicias el servidor después de que la operación de rebobinado haya finalizado pero sin configurar la recuperación, el destino podría bifurcarse nuevamente del primario.
pg_rewind fallará inmediatamente si encuentra archivos en los que no puede escribir directamente. Esto puede suceder, por ejemplo, cuando el servidor de origen y el de destino utilizan la misma ruta de archivo para claves SSL y certificados de solo lectura. Si tales archivos están presentes en el servidor de destino, se recomienda eliminarlos antes de ejecutar pg_rewind. Después de hacer el rebobinado, algunos de esos archivos pueden haber sido copiados desde el origen, en cuyo caso puede ser necesario eliminar los datos copiados y restaurar el conjunto de enlaces utilizados antes del rebobinado.
pg_rewind acepta los siguientes argumentos de línea de comandos:
-D directory--target-pgdata=directoryEsta opción especifica el directorio de datos de destino que se sincroniza con el origen. El servidor de destino debe apagarse de forma limpia antes de ejecutar pg_rewind.
--source-pgdata=directoryEspecifica la ruta del sistema de archivos al directorio de datos del servidor de origen con el que se sincronizará el destino. Esta opción requiere que el servidor de origen se apague de forma limpia.
--source-server=connstrEspecifica una cadena de conexión libpq para conectarse al servidor PostgreSQL de origen con el que se sincronizará el destino. La conexión debe ser una conexión normal (no de replicación) con un rol que tenga suficientes permisos para ejecutar las funciones utilizadas por pg_rewind en el servidor de origen (véase la sección Notas para más detalles) o un rol de superusuario. Esta opción requiere que el servidor de origen esté ejecutándose y aceptando conexiones.
-R--write-recovery-conf
Crea standby.signal y añade la configuración de conexión a
postgresql.auto.conf en el directorio de salida. El parámetro dbname se
registrará solo si se especificó explícitamente en la cadena de conexión o en la variable de entorno. --source-server es obligatorio
con esta opción.
-n--dry-runRealiza todos los pasos excepto modificar realmente el directorio de destino.
-N--no-sync
Por defecto, pg_rewind esperará a que todos los archivos se escriban de forma
segura en el disco. Esta opción hace que pg_rewind retorne sin esperar, lo cual
es más rápido, pero significa que una posterior caída del sistema operativo puede dejar el
directorio de datos corrupto. Por lo general, esta opción es útil para pruebas, pero no debe
utilizarse en una instalación de producción.
-P--progressHabilita el reporte de progreso. Al activar esto, se entregará un informe de progreso aproximado mientras se copian los datos del clúster de origen.
-c--restore-target-wal
Utiliza el restore_command definido en la configuración del clúster de destino
para recuperar archivos WAL desde el archivo WAL si estos archivos ya no están disponibles en el
directorio pg_wal.
--config-file=filename
Utiliza el archivo de configuración del servidor principal especificado para el clúster de destino.
Esto afecta a pg_rewind cuando utiliza internamente el comando
postgres para la operación de rebobinado en este clúster (al recuperar
restore_command con la opción -c/--restore-target-wal y al forzar
la finalización de la recuperación de caídas).
--debugMuestra una salida de depuración detallada que es útil principalmente para los desarrolladores que depuran pg_rewind.
--no-ensure-shutdownpg_rewind requiere que el servidor de destino se apague de forma limpia antes de rebobinar. Por defecto, si el servidor de destino no se apagó de forma limpia, pg_rewind inicia el servidor de destino en modo de usuario único para completar primero la recuperación de caídas y luego lo detiene. Al pasar esta opción, pg_rewind omite esto y genera un error inmediatamente si el servidor no se ha apagado de forma limpia. Se espera que los usuarios manejen la situación ellos mismos en ese caso.
--sync-method=method
Cuando se establece en fsync, que es el valor predeterminado,
pg_rewind abrirá y sincronizará recursivamente todos los archivos en el
directorio de datos. La búsqueda de archivos seguirá los enlaces simbólicos para el directorio WAL
y cada tablespace configurado.
En Linux, se puede utilizar syncfs en su lugar para pedir al sistema operativo
que sincronice todos los sistemas de archivos que contienen el directorio de datos, los archivos
WAL y cada tablespace. Véase recovery_init_sync_method para obtener
información sobre las advertencias a tener en cuenta al utilizar syncfs.
Esta opción no tiene efecto cuando se utiliza --no-sync.
-V--versionMuestra la información de versión y termina.
-?--helpMuestra la ayuda y termina.
Cuando se utiliza la opción --source-server,
pg_rewind también utiliza las variables de entorno admitidas por
libpq (véase Section 32.15).
La variable de entorno PG_COLOR especifica si se debe usar color en los mensajes de
diagnóstico. Los valores posibles son always, auto y
never.
Al ejecutar pg_rewind utilizando un clúster en línea como origen, se puede
utilizar un rol que tenga suficientes permisos para ejecutar las funciones utilizadas por
pg_rewind en el clúster de origen en lugar de un superusuario. Aquí se
muestra cómo crear dicho rol, llamado aquí rewind_user:
CREATE USER rewind_user LOGIN; GRANT EXECUTE ON function pg_catalog.pg_ls_dir(text, boolean, boolean) TO rewind_user; GRANT EXECUTE ON function pg_catalog.pg_stat_file(text, boolean) TO rewind_user; GRANT EXECUTE ON function pg_catalog.pg_read_binary_file(text) TO rewind_user; GRANT EXECUTE ON function pg_catalog.pg_read_binary_file(text, bigint, bigint, boolean) TO rewind_user;
La idea básica es copiar todos los cambios a nivel de sistema de archivos del clúster de origen al clúster de destino:
Escanea el registro WAL del clúster de destino, comenzando desde el último punto de control antes del
punto donde el historial de líneas de tiempo del clúster de origen se bifurcó del clúster de
destino. Para cada registro WAL, registra cada bloque de datos que fue tocado. Esto genera una lista
de todos los bloques de datos que se cambiaron en el clúster de destino, después de que el clúster
de origen se bifurcara. Si algunos de los archivos WAL ya no están disponibles, intenta volver a
ejecutar pg_rewind con la opción -c para buscar los
archivos faltantes en el archivo WAL.
Copia todos esos bloques cambiados desde el clúster de origen al clúster de destino, ya sea utilizando
el acceso directo al sistema de archivos (--source-pgdata) o SQL
(--source-server). Los archivos de relación están ahora en un estado equivalente al
momento del último punto de control completado antes del punto en el que las líneas de tiempo WAL
del origen y del destino se bifurcaron, más el estado actual en el origen de cualquier bloque
cambiado en el destino después de esa bifurcación.
Copia todos los demás archivos, incluidos los nuevos archivos de relación, segmentos WAL,
pg_xact y archivos de configuración desde el clúster de origen al clúster de
destino. De manera similar a las copias de seguridad base, el contenido de los directorios
pg_dynshmem/, pg_notify/,
pg_replslot/, pg_serial/,
pg_snapshots/, pg_stat_tmp/ y
pg_subtrans/ se omiten de los datos copiados del clúster de origen. Se omiten
los archivos backup_label, tablespace_map,
pg_internal.init, postmaster.opts,
postmaster.pid y .DS_Store, así como cualquier archivo o
directorio que comience con pgsql_tmp.
Crea un archivo backup_label para comenzar la reproducción de WAL en el punto de
control creado en la conmutación por error y configura el archivo pg_control
con un LSN de consistencia mínima definido como el resultado de
pg_current_wal_insert_lsn() cuando se rebobina desde un origen activo o el LSN
del último punto de control cuando se rebobina desde un origen detenido.
Al iniciar el destino, PostgreSQL reproduce todo el WAL requerido, lo que da como resultado un directorio de datos en un estado consistente.