Postgres viene con características de replicación física y lógica. Siga leyendo para obtener más información sobre varios aspectos de la replicación física.
Replicación Física
Los métodos de replicación física se utilizan para mantener una copia completa de todos los datos de un solo clúster (en Postgres, un clúster es un conjunto de bases de datos administradas por un único proceso de servidor principal de Postgres llamado postmaster ), normalmente en otra máquina. La máquina fuente se llama principal en la jerga de Postgres, y el destino se denomina espera .
Modos de espera caliente, tibio y "frío"
Un servidor en espera que se mantiene lo más actualizado posible con el principal en tiempo real y permite a los clientes ejecutar transacciones de solo lectura se denomina caliente. en espera, o más popularmente una réplica de lectura . Se agregaron esperas calientes a Postgres en la versión 9, antes de lo cual solo había tibio en espera Un modo de espera cálido es similar a un modo de espera activo, excepto que no permite que los clientes se conecten a él.
(Aparte:Hot standbys no pueden ejecutar consultas que creen tablas temporales. Esta es una limitación de Postgres).
Un modo de espera "frío" (no es un término oficial) suele ser un servidor en espera que no se inicia hasta que se produce una conmutación por error. Dado que el modo de espera en frío no está en funcionamiento, es posible que al iniciarse primero tenga que aplicar los cambios pendientes antes de que pueda comenzar a aceptar conexiones de clientes.
Archivos WAL
En el curso normal de las operaciones, un servidor PostgreSQL genera una serie ordenada de registros WAL (registro de escritura anticipada). Estos son básicamente un registro de cambios, similar al AOF de Redis o al binlog de MySQL. En esencia, la replicación física es el transporte de estos registros a otra máquina y lograr que el otro administrador de correo que se está ejecutando allí acepte y aplique estos registros en su base de datos local.
Los registros WAL se dividen en archivos de igual tamaño (generalmente 16 MB) llamados segmentos WAL o simplemente archivos WAL . Estos archivos se crean en un directorio llamado pg_wal en el directorio de datos del clúster (pg_wal se llamaba pg_xlog en versiones de Postgres anteriores a la 10). Los archivos WAL antiguos se descartan cuando ya no se necesitan (y también en función de un par de parámetros de configuración).
Modo de recuperación
El postmaster se puede iniciar en un modo llamado modo de recuperación , colocando un archivo de configuración válido llamado recovery.conf en el directorio de datos del clúster. En el modo de recuperación, Postgres solo importará y aplicará archivos WAL generados por un servidor principal y, por sí mismo, no generará ningún archivo WAL. Los servidores tibio y en espera activa se ejecutan en modo de recuperación.
Cuando se inicia en el modo de recuperación, Postgres primero intentará importar todos los archivos WAL disponibles en un archivo (más de esto abajo). Cuando el archivo no tiene más archivos WAL para ofrecer, intenta importar cualquier archivo que se encuentre en pg_wal directorio. Cuando eso también haya terminado, si una conexión principal está configurada y standby_modeestablecido en on en recovery.conf, Postgres se conectará al principal y extraerá y aplicará nuevos registros WAL a medida que se creen en el principal.
Envío de registros
Imagine tener un activador que se invocará en el servidor principal cada vez que se cree un nuevo archivo WAL. Este activador puede luego copiar el nuevo archivo WAL a otra máquina usando, por ejemplo, rsync y colóquelo en el pg_wal directorio de un postmaster ejecutándose en modo de recuperación. ¿Puedes hacer un standby como este?
La respuesta es sí y, de hecho, esta era la práctica estándar antes de que se agregara la replicación de transmisión en Postgres v9. Esta práctica se llama envío de registros .
El activador es un script de shell, que se puede configurar mediante archive_command. El nombre y la ruta del archivo WAL se pueden pasar al script.
Archivo WAL
En lugar de hacer rsync sobre el archivo WAL, digamos que lo copiamos en un depósito S3 o en un directorio montado en NFS al que también se puede acceder desde la máquina en espera. Esta ubicación compartida ahora contendrá todos los archivos WAL generados por el principal. Esto ahora se convierte en un archivo , y el proceso de almacenamiento de archivos WAL en el archivo se llama archivo continuo o simplemente archivo WAL .
La inversa de esta operación, obtener archivos WAL del archivo en Postgres en modo de recuperación, se puede configurar usandorestore_command. Similar a archive_command , esta también es la ruta a un script de shell. El administrador de correo que se ejecuta en modo de recuperación sabe qué archivo WAL quiere. El nombre del archivo se puede pasar al script.
Como ejemplo, estos son los comandos de archivo y restauración para almacenar y obtener archivos WAL hacia y desde un depósito S3:
archive_command = 's3cmd put %p s3://BUCKET/path/%f' # in postgresql.conf
restore_command = 's3cmd get s3://BUCKET/path/%f %p' # in recovery.conf
Al iniciar en modo de recuperación, si restore_command está configurado, Postgres intentará primero obtener archivos WAL del archivo.
pg_espera
En el modo de recuperación, Postgres no sabe ni puede saber de antemano cuántos archivos WAL se han generado hasta el momento. Si se configura el comando restaurar, Postgres lo invocará repetidamente con nombres de archivos WAL progresivos (los nombres están en una secuencia predecible) hasta que el comando devuelva un error.
Por ejemplo, el comando de restauración pudo satisfacer las solicitudes de archivos WAL000000010000000000000001 a través de 00000001000000000000001A pero falla para 00000001000000000000001B ya que no se encontró en la ubicación del archivo. En ausencia de archivos WAL de otras fuentes, Postgres supondrá que el archivo WAL 00000001000000000000001B aún no ha sido generado por el principal y finalizará la recuperación después de aplicar 00000001000000000000001A .
Considere lo que sucede si el comando de restauración esperara el archivo 00000001000000000000001B estar disponible, en lugar de salir con un error ya que no se encontró. Postgres continuará esperando el comando de restauración y, por lo tanto, continuará en modo de recuperación.
Esta es una configuración válida y una forma válida de configurar un modo de espera cálido.
Postgres incluye un comando llamado pg_standby, que puede usarse para configurar un modo de espera en caliente de esta manera, siempre que el archivo sea un directorio.pg_standby esperará a que un archivo esté disponible, si no se puede encontrar.
Los comandos de archivo y restauración usando pg_standby se verán así:
archive_command = 'cp %p /some/path/%f' # in postgresql.conf
restore_command = 'pg_standby /some/path %f %p' # in recovery.confReplicación de transmisión
Después de procesar archivos WAL archivados, así como archivos en pg_wal directorio, Postgres puede conectarse a un servidor primario a través de la red y buscar y aplicar repetidamente nuevos archivos WAL a medida que se crean. Esta característica, agregada en Postgres 9, se llama replicación de transmisión .
El servidor principal al que conectarse se puede especificar en el archivo recovery.conf:
# recovery.conf
standby_mode = on
primary_conninfo = 'host=10.0.1.10 user=repl password=p@ssw0rd'Modo de espera activo
De forma predeterminada, cuando está en modo de recuperación, Postgres no aceptará conexiones de clientes, rechazándolas con mensajes de error "el sistema de base de datos está en modo de recuperación". Agregando la línea hot_standby = on en recovery.conf, puede hacer que Postgres acepte conexiones de clientes y permitirles ejecutar transacciones de solo lectura:
# recovery.conf
hot_standby = onPor lo general, no hay motivo para desactivar hot_standby.
Los documentos de PostgreSQL tienen más información sobre cómo configurar y ejecutar un modo de espera en el modo de espera activa.
Ranuras de replicación
Las ranuras de replicación se introdujeron en Postgres 9.4. Son un mecanismo para realizar un seguimiento preciso y duradero de cuánto se está retrasando un dispositivo de reserva con respecto al primario. Esto permite que el primario se asegure de que los archivos WAL que todavía se necesitan para que el standby se ponga al día no se eliminen.
Antes de las ranuras de replicación, el primario no podía determinar esto, y terminaría en situaciones en las que un recurso en espera se quedaba varado porque el primario había eliminado un archivo WAL que necesitaba. Por supuesto, los archivos WAL pueden solucionar este problema. Sin embargo, sin un archivo WAL, la única opción era reconstruir el archivo de reserva a partir de una copia de seguridad nueva.
Puede leer más sobre las ranuras de replicación aquí.
Pasos para configurar un Hot Standby
Echemos un vistazo a los pasos necesarios para configurar un modo de espera en caliente para un primario existente.
Primero, necesitamos un usuario para que el standby se conecte como:
$ psql -p 6000
psql (11.2 (Debian 11.2-1.pgdg90+1))
Type "help" for help.
postgres=# CREATE USER repluser REPLICATION PASSWORD 'p@ssw0rd';
CREATE USER
Y los cambios correspondientes en pg_hba.conf :
# TYPE DATABASE USER ADDRESS METHOD
host replication repluser standby-ip/32 md5
# (replace standby-ip)Por supuesto, puede utilizar cualquier mecanismo de autenticación estándar de PostgreSQL. El usuario debe tener privilegios de replicación e inicio de sesión y no requiere acceso a ninguna base de datos específica.
Asegúrese de volver a cargar el servidor principal para que los cambios en pg_hba.conf surtan efecto.
El modo de espera debe comenzar a partir de una copia de seguridad del principal. Puede y debe hacer esto usando pg_basebackup con una nueva ranura de replicación:
pg_basebackup -h primary-ip -p 6000 -U repluser -C -S slot_standby1 -R -D standby
Esto se conecta al primario en primary-ip:6000 con el usuario que acabamos de crear y realiza una copia de seguridad del mismo en el directorio standby . Una nueva ranura de replicaciónslot_standby1 se crea.
Usaremos esta ranura como nuestra ranura de replicación en espera, para que haya continuidad desde la copia de seguridad.
Le habíamos pedido a pg_basebackup para crear un recovery.conf para nosotros arriba (opción "-R"). Echemos un vistazo a eso:
$ cat standby/recovery.conf
standby_mode = 'on'
primary_conninfo = 'user=repluser password=''p@ssw0rd'' host=primary-ip port=6000 sslmode=prefer sslcompression=0 krbsrvname=postgres target_session_attrs=any'
primary_slot_name = 'slot_standby1'Eso es realmente bastante bueno, y no necesitamos modificarlo más. Ahora simplemente activemos el modo de espera:
o$ pg_ctl -D standby -l log_standby -o --port=6001 start
waiting for server to start.... done
server started
postgres@stg1:/tmp/demo$ cat log_standby
2019-06-19 09:17:50.032 UTC [21733] LOG: listening on IPv4 address "127.0.0.1", port 6001
2019-06-19 09:17:50.034 UTC [21733] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.6001"
2019-06-19 09:17:50.067 UTC [21734] LOG: database system was interrupted; last known up at 2019-06-19 09:12:05 UTC
2019-06-19 09:17:50.111 UTC [21734] LOG: entering standby mode
2019-06-19 09:17:50.119 UTC [21734] LOG: redo starts at 0/2000028
2019-06-19 09:17:50.120 UTC [21734] LOG: consistent recovery state reached at 0/20000F8
2019-06-19 09:17:50.120 UTC [21733] LOG: database system is ready to accept read only connections
2019-06-19 09:17:50.138 UTC [21739] LOG: started streaming WAL from primary at 0/3000000 on timeline 1¡Y eso es! El archivo de registro indica que la replicación de transmisión está activa y en ejecución. Ahora debería poder conectarse al standby en el puerto 6001, ejecutar consultas de solo lectura y ver cómo se replican los cambios desde el principal más o menos en tiempo real.
Pasos siguientes
Los documentos de PostgreSQL son un excelente lugar para comenzar a profundizar en todas las funciones de Postgres relacionadas con la replicación. Querrá analizar temas como la replicación retrasada, la replicación en cascada, los modos de espera sincrónicos y más.
Aunque Postgres viene con un impresionante conjunto de funciones, todavía hay casos de uso que no son compatibles. Esta página wiki de Postgres tiene una lista de herramientas de terceros que brindan funciones adicionales relacionadas con la replicación.
