Existen diferentes enfoques para actualizar PostgreSQL, pero algunos conducen al tiempo de inactividad. Si desea evitar el tiempo de inactividad, use la replicación para actualizar: lógica o física (transmisión), según el escenario. En este artículo, veremos la diferencia entre la replicación lógica y física en PostgreSQL. Luego, hablaremos en detalle sobre cómo actualizar la versión mediante la replicación lógica y evitar el tiempo de inactividad de la aplicación. El próximo artículo discutirá la replicación física.
En artículos anteriores, ya hablamos sobre los métodos para actualizar PostgreSQL ( Actualización de PostgreSQL usando pg_dumpall y Actualización de PostgreSQL usando pg_dump / pg_restore ) como parte de la serie Actualización o Migración de versiones antiguas de PostgreSQL . Pero ambos métodos no excluyen el tiempo de inactividad.
Tipos de replicación lógica
Aquí discutimos 2 tipos de replicación:
- Replicación entre PostgreSQL 10 y 11 usando replicación lógica incorporada.
- Replicación entre PostgreSQL 9.4 (o anterior a PG 11) y PostgreSQL 11 usando la extensión pglogical .
Para minimizar el tiempo de inactividad, puede actualizar mediante la replicación. Cuando todos los datos relevantes se replican en otro servidor PostgreSQL más reciente, simplemente transfiere la aplicación al nuevo servidor con un tiempo de inactividad mínimo, aunque, por supuesto, todo depende de la complejidad de la pila de aplicaciones.
La replicación lógica en PostgreSQL permite a los usuarios replicar tablas selectivamente y abrir un servidor de respaldo para operaciones de escritura. La replicación física en PostgreSQL se realiza en bloques. En este caso, cada base de datos en el asistente se replica en el servidor de respaldo, inaccesible para escribir operaciones. A continuación, llamaremos transmisión de replicación física.
Al usar la replicación lógica en un servidor en espera, puede habilitar la replicación desde múltiples maestros. Esto es útil en situaciones en las que necesita replicar datos de múltiples bases de datos PostgreSQL (OLTP) en un solo servidor PostgreSQL para informes y almacenamiento de datos.
La principal ventaja de la replicación lógica sobre la transmisión es que con la replicación lógica, puede replicar los cambios de la versión anterior de PostgreSQL a la nueva. La replicación de flujo solo funciona cuando el servidor maestro y el servidor de respaldo tienen la misma versión principal. Idealmente, las versiones adicionales también deberían coincidir.
Replicación entre PostgreSQL 10 y 11
A partir de PostgreSQL 10, la replicación lógica está disponible de forma predeterminada. Por lo tanto, puede replicar fácilmente la base de datos PostgreSQL 10 en PostgreSQL 11. La replicación lógica utiliza el modelo de publicación y suscripción. El nodo que envía los cambios se convierte en el editor. Y el nodo que se suscribe a estos cambios se convierte en suscriptor. Puede haber varias suscripciones por publicación.
Publicar
Una publicación es una matriz de cambios creados por un grupo de tablas. Se llama conjunto de cambios o conjunto de replicación . Las publicaciones solo pueden contener tablas, pero no otros objetos. DML en estas tablas se puede replicar, pero DDL no.
En la publicación, puede elegir qué tipo de DML replicar: INSERTAR, ELIMINAR, ACTUALIZAR o TODOS. Por defecto, TODO está seleccionado. La tabla debe tener un identificador de réplica para replicar las operaciones UPDATE y DELETE al suscriptor. Los identificadores de réplica lo ayudan a encontrar filas que se actualizan o eliminan.
La clave principal de la tabla es el identificador de réplica predeterminado. O puede hacer que el identificador sea un índice único con valores NOT NULL. Si no tiene una clave principal o un índice único con valores NO NULL, establezca replica_identity en FULL. En este caso, Postgres usa la cadena completa como clave. Pero esto no es muy racional.
Si una tabla sin una clave principal y un identificador de réplica se agrega a la publicación de forma predeterminada después de una operación ACTUALIZAR o ELIMINAR, pueden producirse errores.
Suscripción
Un suscriptor puede suscribirse a una o más publicaciones. Antes de agregar una suscripción, asegúrese de que las tablas replicadas se creen en el nodo del suscriptor. Para hacer esto, volcar solo los esquemas del editor al suscriptor.
Ejemplo de replicación lógica
El siguiente ejemplo describe la replicación lógica solo entre las versiones 10 y 11 de PostgreSQL.
Cree una publicación en el sitio del editor. Agregue todas o solo algunas tablas a la publicación.
-- For adding ALL Tables in Database CREATE PUBLICATION percpub FOR ALL TABLES; -- For adding Selected Tables in Database CREATE PUBLICATION percpub FOR TABLE scott.employee scott.departments;
En el sitio del suscriptor, cree una suscripción a esta publicación. Realice un volcado DDL de las tablas al suscriptor antes de crear la suscripción, como se mencionó anteriormente.
$ pg_dump -h publisher_server_ip -p 5432 -d percona -Fc -s -U postgres | pg_restore -d percona -h subscriber_node_ip -p 5432 -U postgres CREATE SUBSCRIPTION percsub CONNECTION 'host=publisher_server_ip dbname=percona user=postgres password=secret port=5432' PUBLICATION percpub;
Este comando también copia datos existentes en las tablas. Si desea deshabilitar la copia de datos existentes, use el siguiente comando y solo se copiarán los cambios al editor.
CREATE SUBSCRIPTION percsub CONNECTION 'host=publisher_server_ip dbname=percona user=postgres password=oracle port=5432' PUBLICATION percpub WITH (copy_data = false);
Rastree la replicación utilizando el siguiente comando en el nodo del editor:
$ psql \x select * from pg_stat_replication;
Replicación entre PostgreSQL 9.4 y PostgreSQL 11
¿Qué hacer con versiones anteriores a PostgreSQL 10? Para las versiones 9.4 a 11 hay una extensión especial: pglogical . Con pglogical, puede replicar PostgreSQL 9.4 en PostgreSQL 11 de dos maneras.
Las siguientes son instrucciones generales para configurar la replicación entre PG 9.4 y PG 11 utilizando la extensión pglogical .
Paso 1. Considere pgserver_94 como el servidor de origen con la base de datos percona_94 en PostgreSQL 9.4. Crea la siguiente extensión.
codigo
[pgserver_94:] $psql -d percona_94 -c "CREATE EXTENSION pglogical_origin" CREATE EXTENSION [pgserver_94:] $psql -d percona_94 -c "CREATE EXTENSION pglogical" CREATE EXTENSION
Paso 2. Ahora agregue todas o algunas de las tablas al esquema o varios esquemas para la replicación. En el siguiente ejemplo, ve un error porque una de las tablas no tiene una clave primaria.
[pgserver_94:] $psql -d percona_94 psql (9.4.21) Type "help" for help. percona_94=# SELECT pglogical.create_node(node_name := 'provider1',dsn := 'host=192.168.0.24 port=5432 dbname=percona_94'); create_node ------------- 2976894835 (1 row) percona_94=# SELECT pglogical.replication_set_add_all_tables('default', ARRAY['public']); ERROR: table pgbench_history cannot be added to replication set default DETAIL: table does not have PRIMARY KEY and given replication set is configured to replicate UPDATEs and/or DELETEs HINT: Add a PRIMARY KEY to the table percona_94=# ALTER TABLE pgbench_history ADD PRIMARY KEY (tid,aid,delta); ALTER TABLE percona_94=# SELECT pglogical.replication_set_add_all_tables('default', ARRAY['public']); replication_set_add_all_tables -------------------------------- t (1 row)
Paso 3. En el nodo del suscriptor, es decir, en la base de datos PostgreSQL 11, ejecute los siguientes comandos.
[pgserver_11:] $psql -d percona_11 psql (11.2) Type "help" for help. percona_11=# SELECT pglogical.create_node(node_name := 'subscriber1',dsn := 'host=127.0.0.1 port=5432 dbname=percona_11 password=secret'); create_node ------------- 330520249 (1 row) percona_11=# SELECT pglogical.create_subscription(subscription_name := 'subscription1',provider_dsn := 'host=192.168.0.24 port=5432 dbname=percona_94 password=secret'); create_subscription --------------------- 1763399739 (1 row)
Paso 4. Luego verifique el estado de replicación enviando una solicitud a varias tablas, que pglogical siempre actualiza:
percona_11=# select * from pglogical.local_sync_status; sync_kind | sync_subid | sync_nspname | sync_relname | sync_status | sync_statuslsn -----------+------------+--------------+------------------+-------------+---------------- f | 1763399739 | public | pgbench_accounts | r | 0/2EB7D48 f | 1763399739 | public | pgbench_history | r | 0/2EB7D48 f | 1763399739 | public | pgbench_tellers | r | 0/2EB7D48 f | 1763399739 | public | pgbench_branches | r | 0/2EB7D48 d | 1763399739 | | | r | 0/0 (5 rows) percona_11=# select * from pglogical.subscription; sub_id | sub_name | sub_origin | sub_target | sub_origin_if | sub_target_if | sub_enabled | sub_slot_name | sub_rep lication_sets | sub_forward_origins | sub_apply_delay ------------+---------------+------------+------------+---------------+---------------+-------------+----------------------------------------+---------------- -----------------------+---------------------+----------------- 1763399739 | subscription1 | 2976894835 | 330520249 | 2402836775 | 2049915666 | t | pgl_percona_11_provider1_subscription1 | {default,defaul t_insert_only,ddl_sql} | {all} | 00:00:00 (1 row)
Selección de clave primaria
En el segundo paso, vio cómo todas las tablas en el esquema público se agregaron al conjunto de replicación al crear una clave primaria para una tabla que no tenía una. Es posible que haya elegido la clave primaria incorrecta para esta tabla, pero esto es solo para demostración. Al elegir una clave principal, asegúrese de que sea correcta. Debe ser único y usar columnas que no contengan valores NULL. Si no encuentra la clave primaria correcta, esto puede provocar el tiempo de inactividad de la aplicación. Aquí hay un ejemplo de un error que puede ocurrir:
[pgserver_94:] $pgbench -c 10 -T 300 -n percona_94 Client 7 aborted in state 12: ERROR: duplicate key value violates unique constraint "pgbench_history_pkey" DETAIL: Key (tid, aid, delta)=(7, 63268, 2491) already exists.
Aquí se explica cómo usar pglogical para crear una replicación entre las versiones antigua y nueva de PostgreSQL. Después de configurar la replicación, simplemente cambie las aplicaciones a la última versión para que el tiempo de inactividad sea mínimo.