# Uso de pgactive para admitir la replicación activa-activa
La extensión `pgactive` utiliza la replicación activa-activa para admitir y coordinar las operaciones de escritura en varias bases de datos de RDS para PostgreSQL. Amazon RDS para PostgreSQL admite la extensión `pgactive` en las siguientes versiones:
+ RDS para PostgreSQL, versiones 17.0 y todas las posteriores
+ RDS para PostgreSQL 16.1 y versiones 16 posteriores
+ RDS para PostgreSQL 15.2-R2 y versiones 15 posteriores
+ RDS para PostgreSQL 14.10 y versiones 14 posteriores
+ RDS para PostgreSQL 13.13 y versiones 13 posteriores
+ RDS para PostgreSQL 12.17 y versiones 12 posteriores
+ RDS para PostgreSQL 11.22
**nota**
Cuando hay operaciones de escritura en más de una base de datos en una configuración de replicación, es posible que surjan conflictos. Para obtener más información, consulte [Gestión de conflictos en la replicación activa-activa](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-conflicts.md)
**Topics**
+ [Limitaciones de la extensión pgactive](#Appendix.PostgreSQL.CommonDBATasks.pgactive.requirements-limitations)
+ [Inicialización de la capacidad de la extensión pgactive](Appendix.PostgreSQL.CommonDBATasks.pgactive.basic-setup.md)
+ [Configuración de la replicación activa-activa para las instancias de base de datos de RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.pgactive.setup-replication.md)
+ [Medición del retraso de réplica entre miembros de pgactive](Appendix.PostgreSQL.CommonDBATasks.pgactive.replicationlag.md)
+ [Configuración de los ajustes de parámetros para la extensión pgactive](Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.md)
+ [Comprensión de conflictos activo-activo](Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.replication.md)
+ [Descripción del esquema de pgactive](Appendix.PostgreSQL.CommonDBATasks.pgactive.schema.md)
+ [Referencia de funciones de pgactive](pgactive-functions-reference.md)
+ [Gestión de conflictos en la replicación activa-activa](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-conflicts.md)
+ [Gestión de secuencias en la replicación activa-activa](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-sequences.md)
## Limitaciones de la extensión pgactive
+ Todas las tablas requieren una clave principal; de lo contrario, no se permiten operaciones para actualizar ni eliminar. Los valores de la columna de clave principal no deberían actualizarse.
+ Las secuencias pueden tener huecos y, a veces, es posible que no sigan un orden. Las secuencias no se replican. Para obtener más información, consulte [Gestión de secuencias en la replicación activa-activa](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-sequences.md).
+ Los DDL y los objetos grandes no se replican.
+ Los índices únicos secundarios pueden provocar divergencias en los datos.
+ La intercalación debe ser idéntica en todos los nodos del grupo.
+ El equilibrador de carga entre los nodos es un antipatrón.
+ Las transacciones grandes pueden provocar retardos en la replicación.
# Inicialización de la capacidad de la extensión pgactive
Para inicializar la capacidad de la extensión `pgactive` en la instancia de base de datos de RDS para PostgreSQL, defina el valor del parámetro `rds.enable_pgactive` en `1` y, a continuación, cree la extensión en la base de datos. Al hacerlo, se activan automáticamente los parámetros `rds.logical_replication` `track_commit_timestamp` y se establece el valor de `wal_level` en `logical`.
Debe tener permisos como el rol `rds_superuser` para realizar estas tareas.
Puede usar la Consola de administración de AWS o la AWS CLI para crear las instancias de base de datos de RDS para PostgreSQL necesarias. En los pasos siguientes, se supone que la instancia de base de datos de RDS para PostgreSQL está asociada a un grupo de parámetros de base de datos personalizado. Para obtener información sobre la creación de un grupo de parámetros de base de datos personalizado, consulte [Grupos de parámetros para Amazon RDS](USER_WorkingWithParamGroups.md).
## Consola
**Para inicializar la capacidad de la extensión pgactive**
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. En el panel de navegación, elija su instancia de base de datos de RDS para PostgreSQL.
1. Abra la pestaña **Configuración** para su instancia de base de datos de RDS para PostgreSQL. En los detalles de la instancia, busque el enlace **Grupo de parámetros de instancia de base de datos**.
1. Elija el enlace para abrir los parámetros personalizados asociados a la instancia de base de datos de RDS para PostgreSQL.
1. Busque el parámetro `rds.enable_pgactive` y configúrelo en `1` para inicializar la capacidad `pgactive`.
1. Seleccione **Save changes (Guardar cambios)**.
1. En el panel de navegación de la consola de Amazon RDS, elija **Bases de datos**.
1. Seleccione su instancia de base de datos de RDS para PostgreSQL y, a continuación, seleccione **Reinicio** en el menú **Acciones**.
1. Confirme el reinicio de la instancia de base de datos para que sus cambios se apliquen.
1. Cuando la instancia de base de datos esté disponible, podrá utilizar `psql` o cualquier otro cliente de PostgreSQL para conectarse a la instancia de base de datos de RDS para PostgreSQL.
En el siguiente ejemplo, se asume que su instancia de base de datos de RDS para PostgreSQL tiene una base de datos predeterminada llamada *postgres*.
```
psql --host=mydb.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password=PASSWORD --dbname=postgres
```
1. Para comprobar que pgactive esté inicializado, ejecute el siguiente comando.
```
postgres=>SELECT setting ~ 'pgactive'
FROM pg_catalog.pg_settings
WHERE name = 'shared_preload_libraries';
```
Si `pgactive` está en `shared_preload_libraries`, el comando anterior devolverá lo siguiente:
```
?column?
----------
t
```
## AWS CLI
**Para inicializar la capacidad de la extensión pgactive**
Para inicializar `pgactive` utilizando la AWS CLI, llame a la operación [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) para modificar determinados parámetros de su grupo de parámetros personalizado, tal como se muestra en el siguiente procedimiento.
1. Utilice el siguiente comando de la AWS CLI para configurar `rds.enable_pgactive` en `1` para inicializar la capacidad `pgactive` de la instancia de base de datos de RDS para PostgreSQL.
```
postgres=>aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=rds.enable_pgactive,ParameterValue=1,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Utilice el siguiente comando de la AWS CLI para reiniciar la instancia de base de datos de RDS para PostgreSQL para que se inicialice la biblioteca de `pgactive`.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Cuando la instancia esté disponible, use `psql` para conectarse a la instancia de base de datos de RDS para PostgreSQL.
```
psql --host=mydb.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=master user --password=PASSWORD --dbname=postgres
```
1. Para comprobar que pgactive esté inicializado, ejecute el siguiente comando.
```
postgres=>SELECT setting ~ 'pgactive'
FROM pg_catalog.pg_settings
WHERE name = 'shared_preload_libraries';
```
Si `pgactive` está en `shared_preload_libraries`, el comando anterior devolverá lo siguiente:
```
?column?
----------
t
```
# Configuración de la replicación activa-activa para las instancias de base de datos de RDS para PostgreSQL
En el siguiente procedimiento, se muestra cómo iniciar la replicación activo-activo entre dos instancias de base de datos de RDS para PostgreSQL donde `pgactive` esté disponible. Para ejecutar el ejemplo de alta disponibilidad multirregión, debe implementar instancias de Amazon RDS para PostgreSQL en dos regiones diferentes y configurar la interconexión de VPC. Para obtener más información, consulte [Interconexión de VPC](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html).
**nota**
El envío de tráfico entre varias regiones puede conllevar costes adicionales.
En estos pasos, se asume que la instancia de base de datos de RDS para PostgreSQL se ha habilitado con la extensión `pgactive`. Para obtener más información, consulte [Inicialización de la capacidad de la extensión pgactive](Appendix.PostgreSQL.CommonDBATasks.pgactive.basic-setup.md).
**Para configurar la primera instancia de base de datos de RDS para PostgreSQL con la extensión `pgactive`**
En el siguiente ejemplo, se ilustra cómo se crea el grupo `pgactive`, junto con otros pasos necesarios para crear la extensión `pgactive` en la instancia de base de datos de RDS para PostgreSQL.
1. Utilice `psql` u otra herramienta de cliente para conectarse a su primera instancia de base de datos de RDS para PostgreSQL.
```
psql --host=firstinstance.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password=PASSWORD --dbname=postgres
```
1. Cree una base de datos en la instancia de RDS para PostgreSQL mediante el siguiente comando:
```
postgres=> CREATE DATABASE app;
```
1. Cambie la conexión a la nueva base de datos mediante el siguiente comando:
```
\c app
```
1. Cree y rellene una tabla de ejemplo utilizando las siguientes instrucciones SQL:
1. Cree una tabla de ejemplo con la siguiente instrucción SQL.
```
app=> CREATE SCHEMA inventory;
CREATE TABLE inventory.products (
id int PRIMARY KEY, product_name text NOT NULL,
created_at timestamptz NOT NULL DEFAULT CURRENT_TIMESTAMP);
```
1. Rellene la tabla con algunos datos de ejemplo mediante la siguiente instrucción SQL.
```
app=> INSERT INTO inventory.products (id, product_name)
VALUES (1, 'soap'), (2, 'shampoo'), (3, 'conditioner');
```
1. Compruebe que los datos existen en la tabla mediante la siguiente instrucción SQL.
```
app=>SELECT count(*) FROM inventory.products;
count
-------
3
```
1. Cree la extensión `pgactive` en la base de datos existente.
```
app=> CREATE EXTENSION pgactive;
```
1. Para crear e inicializar el grupo pgactive use los siguientes comandos:
```
app=>
-- connection info for endpoint1
CREATE SERVER pgactive_server_endpoint1
FOREIGN DATA WRAPPER pgactive_fdw
OPTIONS (host '', dbname 'app');
CREATE USER MAPPING FOR postgres
SERVER pgactive_server_endpoint1
OPTIONS (user 'postgres', password '');
-- connection info for endpoint2
CREATE SERVER pgactive_server_endpoint2
FOREIGN DATA WRAPPER pgactive_fdw
OPTIONS (host '', dbname 'app');
CREATE USER MAPPING FOR postgres
SERVER pgactive_server_endpoint2
OPTIONS (user 'postgres', password '');
```
Ahora puede inicializar el grupo de replicación y agregar esta primera instancia:
```
SELECT pgactive.pgactive_create_group(
node_name := 'endpoint1-app',
node_dsn := 'user_mapping=postgres pgactive_foreign_server=pgactive_server_endpoint1'
);
```
Utilice los siguientes comandos como método alternativo, aunque menos seguro, para crear e inicializar el grupo pgactive:
```
app=> SELECT pgactive.pgactive_create_group(
node_name := 'node1-app',
node_dsn := 'dbname=app host=firstinstance.111122223333.aws-region.rds.amazonaws.com user=postgres password=PASSWORD');
```
node1-app es el nombre que se asigna para identificar de forma exclusiva un nodo del grupo `pgactive`.
**nota**
Para realizar este paso correctamente en una instancia de base de datos de acceso público, debe activar el parámetro `rds.custom_dns_resolution` configurándolo en `1`.
1. Para comprobar si la instancia de base de datos está lista, utilice el siguiente comando:
```
app=> SELECT pgactive.pgactive_wait_for_node_ready();
```
Si el comando se ejecuta correctamente, verá el siguiente resultado:
```
pgactive_wait_for_node_ready
------------------------------
(1 row)
```
**Para configurar la segunda instancia de RDS para PostgreSQL y unirla al grupo `pgactive`**
En el siguiente ejemplo, se ilustra cómo puede unir una instancia de base de datos de RDS para PostgreSQL al grupo `pgactive`, junto con otros pasos necesarios para crear la extensión `pgactive` en la instancia de base de datos.
En estos pasos se asume que otras instancias de base de datos de RDS para PostgreSQL se han configurado con la extensión `pgactive`. Para obtener más información, consulte [Inicialización de la capacidad de la extensión pgactive](Appendix.PostgreSQL.CommonDBATasks.pgactive.basic-setup.md).
1. Utilice `psql` para conectarse a la instancia en la que desea recibir actualizaciones del publicador.
```
psql --host=secondinstance.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password=PASSWORD --dbname=postgres
```
1. Cree una base de datos en la segunda instancia de base de datos de RDS para PostgreSQL mediante el siguiente comando:
```
postgres=> CREATE DATABASE app;
```
1. Cambie la conexión a la nueva base de datos mediante el siguiente comando:
```
\c app
```
1. Cree la extensión `pgactive` en la base de datos existente.
```
app=> CREATE EXTENSION pgactive;
```
1. Una la segunda instancia de base de datos de RDS para PostgreSQL al grupo `pgactive` de una forma más segura mediante los siguientes comandos:
```
-- connection info for endpoint1
CREATE SERVER pgactive_server_endpoint1
FOREIGN DATA WRAPPER pgactive_fdw
OPTIONS (host '', dbname 'app');
CREATE USER MAPPING FOR postgres
SERVER pgactive_server_endpoint1
OPTIONS (user 'postgres', password '');
-- connection info for endpoint2
CREATE SERVER pgactive_server_endpoint2
FOREIGN DATA WRAPPER pgactive_fdw
OPTIONS (host '', dbname 'app');
CREATE USER MAPPING FOR postgres
SERVER pgactive_server_endpoint2
OPTIONS (user 'postgres', password '');
```
```
SELECT pgactive.pgactive_join_group(
node_name := 'endpoint2-app',
node_dsn := 'user_mapping=postgres pgactive_foreign_server=pgactive_server_endpoint2',
join_using_dsn := 'user_mapping=postgres pgactive_foreign_server=pgactive_server_endpoint1'
);
```
Utilice los siguientes comandos como método alternativo, aunque menos seguro, para unir la segunda instancia de base de datos de RDS para PostgreSQL al grupo `pgactive`
```
app=> SELECT pgactive.pgactive_join_group(
node_name := 'node2-app',
node_dsn := 'dbname=app host=secondinstance.111122223333.aws-region.rds.amazonaws.com user=postgres password=PASSWORD',
join_using_dsn := 'dbname=app host=firstinstance.111122223333.aws-region.rds.amazonaws.com user=postgres password=PASSWORD');
```
node2-app es el nombre que se asigna para identificar de forma exclusiva un nodo del grupo `pgactive`.
1. Para comprobar si la instancia de base de datos está lista, utilice el siguiente comando:
```
app=> SELECT pgactive.pgactive_wait_for_node_ready();
```
Si el comando se ejecuta correctamente, verá el siguiente resultado:
```
pgactive_wait_for_node_ready
------------------------------
(1 row)
```
Si la primera base de datos de RDS para PostgreSQL es relativamente grande, puede ver que `pgactive.pgactive_wait_for_node_ready()`emite el informe de progreso de la operación de restauración. El resultado tiene un aspecto similar al siguiente:
```
NOTICE: restoring database 'app', 6% of 7483 MB complete
NOTICE: restoring database 'app', 42% of 7483 MB complete
NOTICE: restoring database 'app', 77% of 7483 MB complete
NOTICE: restoring database 'app', 98% of 7483 MB complete
NOTICE: successfully restored database 'app' from node node1-app in 00:04:12.274956
pgactive_wait_for_node_ready
------------------------------
(1 row)
```
A partir de este momento, `pgactive` sincroniza los datos entre las dos instancias de base de datos.
1. Puede utilizar el siguiente comando para comprobar si la base de datos de la segunda instancia de base de datos contiene los datos:
```
app=> SELECT count(*) FROM inventory.products;
```
Si los datos se sincronizan correctamente, verá el siguiente resultado:
```
count
-------
3
```
1. Ejecute el siguiente comando para insertar nuevos valores:
```
app=> INSERT INTO inventory.products (id, product_name) VALUES (4, 'lotion');
```
1. Conéctese a la base de datos de la primera instancia de base de datos y ejecute la siguiente consulta:
```
app=> SELECT count(*) FROM inventory.products;
```
Si se inicializa la replicación activa-activa, el resultado es similar al siguiente:
```
count
-------
4
```
**Para separar y eliminar una instancia de base de datos del grupo `pgactive`**
Para separar y eliminar una instancia de base de datos del grupo `pgactive`, siga estos pasos:
1. Puede separar la segunda instancia de base de datos de la primera instancia de base de datos mediante el siguiente comando:
```
app=> SELECT * FROM pgactive.pgactive_detach_nodes(ARRAY[‘node2-app']);
```
1. Elimine la extensión `pgactive` de la segunda instancia de base de datos mediante el siguiente comando:
```
app=> SELECT * FROM pgactive.pgactive_remove();
```
Para eliminar la extensión a la fuerza:
```
app=> SELECT * FROM pgactive.pgactive_remove(true);
```
1. Suelte la extensión con el siguiente comando:
```
app=> DROP EXTENSION pgactive;
```
# Medición del retraso de réplica entre miembros de pgactive
Puede utilizar la siguiente consulta para ver el retraso de réplica entre los miembros de `pgactive`. Ejecute esta consulta en todos los nodos de `pgactive` para obtener una idea completa.
```
app=> SELECT * FROM pgactive.pgactive_get_replication_lag_info();
│-[ RECORD 1 ]--------+---------------------------------------------
│node_name | node2-app
│node_sysid | 7481018224801653637
│application_name | pgactive:7481018224801653637:send
│slot_name | pgactive_16385_7481018224801653637_0_16385__
│active | t
│active_pid | 783486
│pending_wal_decoding | 0
│pending_wal_to_apply | 0
│restart_lsn | 0/2108150
│confirmed_flush_lsn | 0/2154690
│sent_lsn | 0/2154690
│write_lsn | 0/2154690
│flush_lsn | 0/2154690
│replay_lsn | 0/2154690
│-[ RECORD 2 ]--------+---------------------------------------------
│node_name | node1-app
│node_sysid | 7481018033434600853
│application_name | pgactive:7481018033434600853:send
│slot_name | pgactive_16385_7481018033434600853_0_16385__
│active | t
│active_pid | 783488
│pending_wal_decoding | 0
│pending_wal_to_apply | 0
│restart_lsn | 0/20F5AD0
│confirmed_flush_lsn | 0/214EF68
│sent_lsn | 0/214EF68
│write_lsn | 0/214EF68
│flush_lsn | 0/214EF68
│replay_lsn | 0/214EF68
```
Supervise los siguientes diagnósticos como mínimo:
active
Configure alertas cuando el valor activo sea falso, lo que indica que la ranura no está en uso actualmente (la instancia del suscriptor se ha desconectado del publicador).
pending\$1wal\$1decoding
En la replicación lógica de PostgreSQL, los archivos WAL se almacenan en formato binario. El publicador debe decodificar estos cambios de WAL y convertirlos en cambios lógicos (como operaciones de inserción, actualización o eliminación).
La métrica pending\$1wal\$1decoding muestra el número de archivos WAL que esperan que los descodifique el publicador.
Este número puede aumentar debido a estos factores:
+ Cuando el suscriptor no esté conectado, el estado activo será falso y pending\$1wal\$1decoding aumentará
+ La ranura está activa, pero el publicador no puede mantenerse al día con el volumen de cambios de WAL
pending\$1wal\$1to\$1apply
La métrica pending\$1wal\$1apply indica el número de archivos WAL que esperan aplicarse en el suscriptor.
Varios factores pueden impedir que el suscriptor aplique los cambios y potencialmente causar un escenario de disco lleno:
+ Diferencias de esquema: por ejemplo, cuando hay cambios en el flujo de WAL de una tabla llamada ejemplo, pero esa tabla no existe en el suscriptor
+ Se actualizaron los valores en las columnas de la clave principal
+ Los índices únicos secundarios pueden provocar divergencias en los datos
# Configuración de los ajustes de parámetros para la extensión pgactive
Puede utilizar la siguiente consulta para ver todos los parámetros asociados a la extensión `pgactive`.
```
app=> SELECT * FROM pg_settings WHERE name LIKE 'pgactive.%';
```
Puede configurar la extensión `pgactive` mediante varios parámetros. Estos parámetros se pueden configurar mediante Consola de administración de AWS o la interfaz de la CLI de AWS.
## Parámetros de extensión de pgactive principales
La siguiente tabla proporciona una referencia para los principales parámetros de la extensión `pgactive`:
| Parámetro | Unidad | Predeterminado | Descripción |
| --- | --- | --- | --- |
| pgactive.conflict\$1logging\$1include\$1tuples | `boolean` | – | Registra la información completa de la tupla de la extensión `pgactive`. Es necesario reiniciar el servidor para que se apliquen los cambios. |
| pgactive.log\$1conflicts\$1to\$1table | `boolean` | – | Determina si la extensión `pgactive` registra los conflictos detectados en la tabla `pgactive.pgactive_conflict_history`. Para obtener más información, consulte registro de conflictos. Es necesario reiniciar el servidor para que se apliquen los cambios. |
| pgactive.log\$1conflicts\$1to\$1logfile | `boolean` | – | Determina si la extensión `pgactive` registra los conflictos detectados en el archivo de registro de PostgreSQL. Para obtener más información, consulte registro de conflictos. Es necesario reiniciar el servidor para que se apliquen los cambios. |
| pgactive.synchronous\$1commit | `boolean` | apagar | Determina el comportamiento de confirmación de los trabajadores de aplicación de pgactive. Cuando está desactivado, los trabajadores de aplicación realizan confirmaciones asíncronas, lo que mejora el rendimiento de PostgreSQL durante las operaciones de aplicación, pero retrasa las confirmaciones de reproducción hacia el nodo ascendente. Establecerlo en `off` siempre es seguro y no provocará pérdidas ni omisiones de transacciones. Esta configuración solo afecta al momento de las descargas a disco en el nodo descendente y cuándo se envían las confirmaciones al nodo ascendente. El sistema retrasa el envío de las confirmaciones de vaciado de reproducción hasta que las confirmaciones se vuelcan al disco mediante operaciones no relacionadas, como puntos de control o trabajos periódicos. Sin embargo, si el nodo ascendente tiene el nodo descendente en `synchronous_standby_names`, establecerlo en `off` hace que las confirmaciones sincrónicas en el nodo ascendente tarden más en informar del éxito al cliente. En este caso, establezca el parámetro en `on`. Incluso cuando este parámetro se establece en `on` con nodos en `synchronous_standby_names`, pueden producirse conflictos de replicación en las configuraciones activo-activo. Esto se debe a que el sistema carece de bloqueo entre nodos y de gestión global de instantáneas, lo que permite que las transacciones concurrentes en distintos nodos modifiquen la misma tupla. Además, las transacciones solo comienzan a replicarse después de confirmarse en el nodo ascendente. La habilitación de la confirmación sincrónica no transforma la extensión pgactive en un sistema siempre coherente. |
| pgactive.temp\$1dump\$1directory | `string` | – | Define la ruta de almacenamiento temporal necesaria para las operaciones de clonación de bases de datos durante la configuración inicial. En este directorio debe poder escribir el usuario de postgres y debe tener suficiente espacio de almacenamiento para contener un volcado completo de la base de datos. El sistema utiliza esta ubicación solo durante la configuración inicial de la base de datos con operaciones de copia lógica. Este parámetro no lo usa `pgactive_init_copy command`. |
| pgactive.max\$1ddl\$1lock\$1delay | `milliseconds` | `-1` | Especifica el tiempo máximo de espera para el bloqueo de DDL antes de interrumpir por la fuerza las transacciones de escritura simultáneas. El valor predeterminado es `-1`, que adopta el valor establecido en `max_standby_streaming_delay`. Este parámetro acepta unidades de tiempo. Por ejemplo, puede configurarlo en 10 s para 10 segundos. Durante este periodo de espera, el sistema intenta adquirir bloqueos de DDL mientras espera a que las transacciones de escritura en curso se confirmen o se reviertan. Para obtener más información, consulte Bloqueos de DDL. |
| pgactive.ddl\$1lock\$1timeout | `milliseconds` | `-1` | Especifica cuánto tiempo espera un intento de bloqueo de DDL para obtener el bloqueo. El valor predeterminado es `-1`, que utiliza el valor especificado en lock\$1timeout. Puede configurar este parámetro mediante unidades de tiempo como 10 s para 10 segundos. Este temporizador solo controla el periodo de espera para obtener un bloqueo de DDL. Una vez que el sistema obtiene el bloqueo e inicia la operación de DDL, el temporizador se detiene. Este parámetro no limita la duración total que puede mantenerse un bloqueo de DDL ni el tiempo total de la operación de DDL. Para controlar la duración total de la operación, utilice `statement_timeout` en su lugar. Para obtener más información, consulte Bloqueos de DDL. |
| pgactive.debug\$1trace\$1ddl\$1locks\$1level | `boolean` | – | Invalida el nivel de registro de depuración predeterminado para las operaciones de bloqueo de DDL en la extensión `pgactive`. Cuando se configura, esta configuración hace que los mensajes relacionados con el bloqueo de DDL se emitan en el nivel de depuración LOG en lugar de en su nivel predeterminado. Utilice este parámetro para supervisar la actividad de bloqueo de DDL sin activar los niveles de registro detallados `DEBUG1` o `DEBUG2` en todo el servidor. Niveles de registro disponibles, en orden creciente de detalle: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Para obtener más información acerca de las opciones de supervisión, consulte Supervisión de bloqueos de DDL globales. Los cambios en esta configuración surten efecto al volver a cargar la configuración. No es necesario reiniciar el servidor. |
## Parámetros de extensión de pgactive adicionales
La siguiente tabla presenta las opciones de configuración interna y las que se utilizan con menos frecuencia disponibles para la extensión `pgactive`.
| Parámetro | Unidad | Predeterminado | Descripción |
| --- | --- | --- | --- |
| pgactive.debug\$1apply\$1delay | `integer` | – | Establece un retraso de aplicación (en milisegundos) para las conexiones configuradas que no tienen un retraso de aplicación explícito en su entrada `pgactive.pgactive_connections`. Este retraso se establece durante la creación o la unión del nodo, y pgactive no reproducirá una transacción en los nodos del mismo nivel hasta que hayan transcurrido al menos el número especificado de milisegundos desde que se confirmó. Se utiliza principalmente para simular redes de alta latencia en entornos de prueba para facilitar la creación de conflictos. Por ejemplo, con un retraso de 500 ms en los nodos A y B, dispone de al menos 500 ms para realizar una inserción conflictiva en el nodo B tras insertar un valor en el nodo A. Requiere una recarga del servidor o un reinicio de los trabajadores de aplicación para que surta efecto. |
| pgactive.connectability\$1check\$1duration | `integer` | – | Especifica la duración (en segundos) durante la cual un trabajador de base de datos intenta establecer conexiones durante los intentos erróneos. El trabajador realiza un intento de conexión por segundo hasta que tiene éxito o alcanza este valor de tiempo de espera. Esta configuración resulta útil cuando el motor de base de datos se inicia antes de que el trabajador esté preparado para establecer conexiones. |
| pgactive.skip\$1ddl\$1replication | `boolean` | `on` | Controla cómo se replican o gestionan los cambios de DDL en Amazon RDS con `pgactive` habilitado. Cuando se establece en `on`, el nodo procesa los cambios de DDL como un nodo no pgactive. Los siguientes requisitos se aplican al trabajar con este parámetro: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Puede modificar este parámetro de dos formas con privilegios de superusuario: de forma global o local (nivel de sesión). Si se cambia este parámetro de forma incorrecta, se pueden interrumpir las configuraciones de replicación. |
| pgactive.do\$1not\$1replicate | `boolean` | – | Este parámetro es solo para uso interno. Cuando se establece este parámetro en una transacción, los cambios no se replican en otros nodos del clúster de base de datos. Si se cambia este parámetro de forma incorrecta, se pueden interrumpir las configuraciones de replicación. |
| pgactive.discard\$1mismatched\$1row\$1attributes | `boolean` | – | Este parámetro está destinado solo a uso especializado. Recomendamos usar este parámetro solo para solucionar problemas de replicación específicos. Utilice este parámetro cuando: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Esta configuración invalida el siguiente mensaje de error y permite que surja una divergencia de datos para permitir que la replicación continúe: `cannot right-pad mismatched attributes; attno %u is missing in local table and remote row has non-null, non-dropped value for this attribute` Si se cambia este parámetro de forma incorrecta, se pueden interrumpir las configuraciones de replicación. |
| pgactive.debug\$1trace\$1replay | `boolean` | – | Cuando se establece en `on`, emite un mensaje de registro para cada acción remota que se aplique posteriormente al proceso de los trabajadores. Los registros incluyen: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Los registros también capturan los comandos de DDL en cola y las tablas descartadas.para> De forma predeterminada, los registros no incluyen el contenido de los campos de fila. Para incluir valores de fila en los registros, debe volver a compilarlos con los siguientes indicadores habilitados: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) La habilitación de esta configuración de registro puede afectar al rendimiento. Recomendamos habilitarla solo cuando sea necesario para solucionar problemas. Los cambios en esta configuración surten efecto al volver a cargar la configuración. No es necesario reiniciar el servidor. |
| pgactive.extra\$1apply\$1connection\$1options | | – | Puede configurar los parámetros de conexión para todas las conexiones de nodos del mismo nivel con los nodos de pgactive. Estos parámetros controlan ajustes como keepalive y los modos SSL. De forma predeterminada, pgactive utiliza los siguientes parámetros de conexión: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Para invalidar los parámetros predeterminados, utilice el siguiente comando similar: pgactive.extra\$1apply\$1connection\$1options = 'keepalives=0' Las cadenas de conexión de los nodos individuales tienen prioridad sobre estas configuraciones y sobre las opciones de conexión integradas de pgactive. Para obtener más información acerca de los formatos de cadenas de conexión, consulte [cadenas de conexión libpq](https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNSTRING). Recomendamos mantener habilitada la configuración predeterminada de keepalive. Desactive keepalive solo si tiene problemas al realizar grandes transacciones a través de redes poco fiables. Recomendamos mantener habilitada la configuración predeterminada de keepalive. Desactive keepalive solo si tiene problemas al realizar grandes transacciones a través de redes poco fiables. Los cambios en esta configuración surten efecto al volver a cargar la configuración. No es necesario reiniciar el servidor. |
| pgactive.init\$1node\$1parallel\$1jobs (int) | | – | Especifica el número de trabajos paralelos que `pg_dump` y `pg_restore` pueden utilizar durante las uniones de nodos lógicos con la función `pgactive.pgactive_join_group`. Los cambios en esta configuración surten efecto al volver a cargar la configuración. No es necesario reiniciar el servidor. |
| pgactive.max\$1nodes | `int` | 4 | Especifica el número máximo de nodos permitidos en un grupo de extensiones de pgactive. El valor predeterminado es 4 nodos. Debe tener en cuenta lo siguiente al configurar el valor de este parámetro: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Puede configurar este parámetro de dos maneras: en el archivo de configuración, mediante el comando `ALTER SYSTEM SET` El valor predeterminado de este parámetro es `4`, lo que significa que puede haber un máximo de 4 nodos permitidos en el grupo de extensiones de `pgactive` en cualquier momento. El cambio surtirá efecto después de reiniciar el servidor. |
| pgactive.permit\$1node\$1identifier\$1getter\$1function\$1creation | `boolean` | – | Este parámetro está destinado solo a uso interno. Cuando está habilitada, la extensión `pgactive` permite la creación de la función de obtención del identificador de nodo de pgactive. |
# Comprensión de conflictos activo-activo
Cuando se utiliza pgactive en el modo activo-activo, escribir en las mismas tablas desde varios nodos puede crear conflictos de datos. Aunque algunos sistemas de agrupación en clústeres utilizan bloqueos distribuidos para evitar el acceso simultáneo, pgactive adopta un enfoque optimista que se adapta mejor a las aplicaciones distribuidas geográficamente.
Algunos sistemas de agrupación en clústeres de bases de datos impiden el acceso simultáneo a los datos mediante el uso de bloqueos distribuidos. Aunque este enfoque funciona cuando los servidores están muy cerca, no admite aplicaciones distribuidas geográficamente porque requiere una latencia extremadamente baja para lograr un buen rendimiento. En lugar de utilizar bloqueos distribuidos (un enfoque pesimista), la extensión pgactive utiliza un enfoque optimista. Esto significa que:
+ Ayuda a evitar conflictos cuando es posible.
+ Permite que se produzcan determinados tipos de conflictos.
+ Proporciona resolución de conflictos cuando se producen conflictos.
Este enfoque le proporciona más flexibilidad a la hora de crear aplicaciones distribuidas.
## Cómo se producen los conflictos
Los conflictos entre nodos surgen de secuencias de eventos que no podrían ocurrir si todas las transacciones implicadas se produjeran simultáneamente en el mismo nodo. Como los nodos solo intercambian cambios una vez confirmadas las transacciones, cada transacción es válida individualmente en el nodo en el que se ha confirmado, pero no lo sería si se ejecutara en otro nodo que haya realizado otras tareas mientras tanto. Dado que la aplicación de pgactive básicamente reproduce la transacción en los demás nodos, la operación de reproducción puede producir un error si hay un conflicto entre una transacción que se está aplicando y una transacción que se ha confirmado en el nodo receptor.
La razón por la que la mayoría de los conflictos no se producen cuando todas las transacciones se ejecutan en un único nodo es que PostgreSQL cuenta con mecanismos de comunicación entre transacciones para evitarlos, entre los que se incluyen:
+ Índices UNIQUE
+ SEQUENCE
+ Bloqueo de filas y relaciones
+ Seguimiento de dependencias SERIALIZABLE
Todos estos mecanismos son formas de comunicarse entre transacciones para evitar problemas de concurrencia no deseados
pgactive logra una baja latencia y maneja bien las particiones de la red porque no utiliza un administrador de transacciones distribuido o un administrador de bloqueos. Sin embargo, esto significa que las transacciones en diferentes nodos se ejecutan completamente aisladas unas de otras. Aunque el aislamiento suele mejorar la coherencia de la base de datos, en este caso es necesario reducir el aislamiento para evitar conflictos.
## Tipos de conflictos
Los conflictos que se pueden producir son:
**Topics**
+ [Conflictos de PRIMARY KEY o UNIQUE](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict1)
+ [Conflictos INSERT/INSERT](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict2)
+ [INSERT que infringen múltiples restricciones UNIQUE](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict3)
+ [Conflictos UPDATE/UPDATE](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict4)
+ [Conflictos UPDATE en la PRIMARY KEY](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict5)
+ [UPDATE que infringen varias restricciones UNIQUE](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict6)
+ [Conflictos UPDATE/DELETE](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict7)
+ [Conflictos INSERT/UPDATE](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict8)
+ [Conflictos DELETE/DELETE](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict9)
+ [Conflictos de restricciones de clave externa](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict10)
+ [Conflictos de restricciones de exclusión](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict11)
+ [Conflictos de datos globales](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict12)
+ [Conflictos de bloqueo y anulaciones de bloqueo](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict13)
+ [Conflictos divergentes](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict14)
### Conflictos de PRIMARY KEY o UNIQUE
Los conflictos de filas se producen cuando varias operaciones intentan modificar la misma clave de fila de formas que no son posibles en un solo nodo. Estos conflictos representan el tipo más común de conflictos de datos.
pgactive resuelve los conflictos detectados mediante el manejo de last-update-wins o el gestor de conflictos personalizado.
Los conflictos de filas incluyen:
+ INSERT frente a INSERT
+ INSERT frente a UPDATE
+ UPDATE frente a DELETE
+ INSERT frente a DELETE
+ DELETE frente a DELETE
+ INSERT frente a DELETE
### Conflictos INSERT/INSERT
El conflicto más común se produce cuando los INSERT en dos nodos diferentes crean una tupla con los mismos valores de PRIMARY KEY (o valores de restricción UNIQUE idénticos cuando no existe ninguna PRIMARY KEY).
pgactivelink resuelve los conflictos de INSERT utilizando la marca temporal del host de origen para conservar la tupla más reciente. Puede invalidar este comportamiento predeterminado con el controlador de conflictos personalizado. Aunque este proceso no requiere ninguna acción especial del administrador, tenga en cuenta que pgactivelink descarta una de las operaciones INSERT en todos los nodos. No se produce una fusión automática de datos a menos que el controlador personalizado la implemente.
pgactivelink solo puede resolver conflictos que impliquen una única violación de restricción. Si un INSERT infringe varias restricciones UNIQUE, debe implementar estrategias adicionales de resolución de conflictos.
### INSERT que infringen múltiples restricciones UNIQUE
Un conflicto INSERT/INSERT puede infringir varias restricciones UNIQUE, incluida la PRIMARY KEY. pgactivelink solo puede gestionar conflictos que impliquen una única restricción UNIQUE. Cuando los conflictos infringen varias restricciones UNIQUE, el trabajador de aplicación produce un error y devuelve el siguiente error:
`multiple unique constraints violated by remotely INSERTed tuple.`
En versiones anteriores, esta situación generaba un error de "conflicto de unicidad divergente" en su lugar.
Para resolver estos conflictos, debe tomar medidas manuales. O bien DELETE las tuplas locales en conflicto o UPDATE las mismas para eliminar los conflictos con la nueva tupla remota. Tenga en cuenta que puede que tenga que abordar varias tuplas conflictivas. Actualmente, pgactivelink no proporciona ninguna funcionalidad integrada para ignorar, descartar o fusionar las tuplas que infringen múltiples restricciones únicas.
**nota**
Para obtener más información, consulte UPDATE que infringen varias restricciones UNIQUE.
### Conflictos UPDATE/UPDATE
Este conflicto se produce cuando dos nodos modifican simultáneamente la misma tupla sin cambiar su PRIMARY KEY. pgactivelink resuelve estos conflictos mediante la lógica last-update-wins o el controlador de conflictos personalizado, si está definido. Una PRIMARY KEY es esencial para la coincidencia de tuplas y la resolución de conflictos. En el caso de las tablas sin una PRIMARY KEY, pgactivelink rechaza las operaciones UPDATE con el siguiente error:
`Cannot run UPDATE or DELETE on table (tablename) because it does not have a primary key.`
### Conflictos UPDATE en la PRIMARY KEY
Pgactive tiene limitaciones a la hora de gestionar las actualizaciones de PRIMARY KEY. Aunque puede realizar la operación UPDATE en una PRIMARY KEY, pgactive no puede resolver automáticamente los conflictos utilizando la lógica last-update-wins para estas operaciones. Debe asegurarse de que las actualizaciones de la PRIMARY KEY no entren en conflicto con los valores existentes. Si se producen conflictos durante las actualizaciones de PRIMARY KEY, se convierten en conflictos divergentes que requieren su intervención manual. Para obtener más información acerca de cómo manejar estas situaciones, consulte [Conflictos divergentes](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict14).
### UPDATE que infringen varias restricciones UNIQUE
pgactivelink no puede aplicar la resolución de conflictos last-update-wins cuando una UPDATE entrante infringe varias restricciones UNIQUE o valores de PRIMARY KEY. Este comportamiento es similar a las operaciones INSERT con múltiples infracciones de restricciones. Estas situaciones crean conflictos divergentes que requieren su intervención manual. Para obtener más información, consulte [Conflictos divergentes](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict14).
### Conflictos UPDATE/DELETE
Estos conflictos se producen cuando un nodo realiza una UPDATE en una fila mientras que otro nodo la DELETE simultáneamente. En este caso, se produce un conflicto UPDATE/DELETE durante la reproducción. La solución consiste en descartar cualquier UPDATE que llegue después de una DELETE, a menos que el gestor de conflictos personalizado especifique lo contrario.
pgactivelink requiere una PRIMARY KEY para hacer coincidir las tuplas y resolver los conflictos. Para las tablas sin una PRIMARY KEY, rechaza las operaciones DELETE con el siguiente error:
`Cannot run UPDATE or DELETE on table (tablename) because it does not have a primary key.`
**nota**
pgactivelink no puede distinguir entre los conflictos de UPDATE/DELETE e INSERT/UPDATE. En ambos casos, una UPDATE afecta a una fila que no existe. Debido a la replicación asíncrona y a la falta de orden de reproducción entre los nodos, pgactivelink no puede determinar si la UPDATE es para una fila nueva (aún no se ha recibido INSERT) o para una fila eliminada. En ambos casos, pgactivelink descarta la UPDATE.
### Conflictos INSERT/UPDATE
Este conflicto se puede producir en entornos de varios nodos. Ocurre cuando un nodo INSERT una fila, un segundo nodo la UPDATE y un tercer nodo recibe la UPDATE antes que el INSERT original. De forma predeterminada, pgactivelink resuelve estos conflictos descartando la UPDATE, a menos que el desencadenador de conflictos personalizado especifique lo contrario. Tenga en cuenta que este método de resolución puede provocar incoherencias en los datos entre los nodos. Para obtener más información acerca de escenarios similares y su manejo, consulte [Conflictos UPDATE/DELETE](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict7).
### Conflictos DELETE/DELETE
Este conflicto se produce cuando dos nodos diferentes eliminan simultáneamente la misma tupla. pgactivelink considera que estos conflictos son inofensivos porque ambas operaciones DELETE tienen el mismo resultado final. En este escenario, pgactivelink ignora de forma segura una de las operaciones DELETE sin afectar a la coherencia de datos.
### Conflictos de restricciones de clave externa
Las restricciones de FOREIGN KEY pueden provocar conflictos al aplicar transacciones remotas a los datos locales existentes. Estos conflictos suelen producirse cuando las transacciones se aplican en una secuencia diferente a su orden lógico en los nodos de origen.
De forma predeterminada, pgactive aplica los cambios con session\$1replication\$1role como `replica`, lo que evita las comprobaciones de claves externas durante la replicación. En las configuraciones activo-activo, esto puede provocar infracciones de claves externas. La mayoría de las infracciones son temporales y se resuelven una vez que la replicación se pone al día. Sin embargo, pueden producirse claves externas huérfanas porque pgactive no admite el bloqueo de filas entre nodos.
Este comportamiento es inherente a los sistemas activo-activo asíncronos tolerantes a las particiones. Por ejemplo, el nodo A puede insertar una nueva fila secundaria mientras que el nodo B elimina simultáneamente su fila principal. El sistema no puede impedir este tipo de modificación concurrente entre nodos.
Para minimizar los conflictos de claves externas, recomendamos lo siguiente:
+ Limitar las relaciones de claves externas a entidades estrechamente relacionadas.
+ Modificar las entidades relacionadas desde un solo nodo cuando sea posible.
+ Elegir entidades que rara vez requieran modificación.
+ Implementar un control de concurrencia en el nivel de aplicación para las modificaciones.
### Conflictos de restricciones de exclusión
pgactive link no admite restricciones de exclusión y restringe su creación.
**nota**
Si convierte una base de datos independiente existente en una base de datos de pgactivelink, elimine manualmente todas las restricciones de exclusión.
En un sistema asíncrono distribuido, no es posible garantizar que ningún conjunto de filas infrinja la restricción. Esto se debe a que todas las transacciones en los distintos nodos están completamente aisladas. Las restricciones de exclusión pueden provocar bloqueos de reproducción, donde la reproducción no puede avanzar de un nodo a otro debido a infracciones de las restricciones de exclusión.
Si obliga a pgactive Link a crear una restricción de exclusión o si no elimina las existentes al convertir una base de datos independiente en pgactive Link, es probable que la replicación se interrumpa. Para restaurar el progreso de la replicación, elimine o modifique las tuplas locales que entren en conflicto con una tupla remota entrante para poder aplicar la transacción remota.
### Conflictos de datos globales
Cuando se utiliza pgactivelink, se pueden producir conflictos cuando los nodos tienen diferentes datos globales de todo el sistema PostgreSQL, como los roles. Estos conflictos pueden provocar que las operaciones (principalmente DDL) se ejecuten correctamente en un nodo, pero que no se apliquen a otros nodos.
Si un usuario existe en un nodo pero no en otro, pueden producirse problemas de replicación:
+ Node1 tiene un nombre de usuario `fred`, pero este usuario no existe en Node2
+ Cuando `fred` crea una tabla en Node1, la tabla se replica con `fred` como el propietario
+ Cuando este comando de DDL se aplica al Node2, se produce un error porque el usuario `fred` no existe
+ Este error genera un ERROR en los registros de PostgreSQL en Node2 e incrementa el contador `pgactive.pgactive_stats.nr_rollbacks`
**Solución:** cree el usuario `fred` en Node2. El usuario no necesita permisos idénticos, sino que debe existir en ambos nodos.
Si existe una tabla en un nodo pero no en otro, las operaciones de modificación de datos producirán un error:
+ Node1 tiene una tabla llamada `foo` que no existe en Node2
+ Cualquier operación de DML en la tabla `foo` en el Node1 producirá un error cuando se replique en Node2
**Solución:** cree la tabla `foo` en el Node2 con la misma estructura.
**nota**
Actualmente, pgactivelink no replica los comandos CREATE USER ni las operaciones de DDL. La replicación de DDL está prevista para una versión futura.
### Conflictos de bloqueo y anulaciones de bloqueo
Como los procesos de aplicación de pgactive funcionan como sesiones de usuario normales, siguen las reglas estándar de bloqueo de filas y tablas. Esto puede provocar que los procesos de aplicación de pgactivelink esperen por bloqueos mantenidos por transacciones de usuarios o por otros procesos de aplicación.
Los siguientes tipos de bloqueos pueden afectar a los procesos de aplicación:
+ Bloqueo explícito en el nivel de tabla (LOCK TABLE...) por sesiones de usuario
+ Bloqueo explícito en el nivel de fila (SELECT ... FOR UPDATE/FOR SHARE) por sesiones de usuario
+ Bloqueo desde claves foráneas
+ Bloqueo implícito debido a UPDATE, INSERT o DELETE de filas, ya sea por actividad local o aplicación desde otros servidores
Los bloqueos pueden ocurrir entre:
+ Un proceso de aplicación de pgactivelink y una transacción de usuario
+ Dos procesos de aplicación
Cuando se producen bloqueos, el detector de bloqueos de PostgreSQL finaliza una de las transacciones problemáticas. Si se termina el proceso del trabajador de aplicación de pgactivelink, este reintenta automáticamente y normalmente tiene éxito.
**nota**
Estos problemas son temporales y generalmente no requieren la intervención del administrador. Si un proceso de aplicación está bloqueado durante un periodo prolongado por un bloqueo en una sesión de usuario inactiva, puede terminar la sesión de usuario para reanudar la replicación. Esta situación es similar a cuando un usuario mantiene un bloqueo prolongado que afecta a la sesión de otro usuario.
Para identificar los retrasos en la reproducción relacionados con el bloqueo, habilite la instalación `log_lock_waits` en PostgreSQL.
### Conflictos divergentes
Los conflictos divergentes se producen cuando los datos que deberían ser idénticos en todos los nodos difieren inesperadamente. Aunque estos conflictos no se deberían producir, no todos se pueden prevenir de forma fiable con la implementación actual.
**nota**
La modificación de PRIMARY KEY de una fila puede provocar conflictos divergentes si otro nodo cambia la clave de la misma fila antes de que todos los nodos procesen el cambio. Evite cambiar las claves principales o restrinja los cambios a un nodo designado. Para obtener más información, consulte [Conflictos UPDATE en la PRIMARY KEY](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict5).
Los conflictos divergentes relacionados con los datos de las filas suelen requerir la intervención del administrador. Para resolver estos conflictos, debe ajustar manualmente los datos de un nodo para que coincidan con otro mientras desactiva temporalmente la replicación mediante `pgactive.pgactive_do_not_replicate`. Estos conflictos no se deberían producir cuando se utiliza pgactive tal como se ha documentado y se evitan las configuraciones o funciones marcadas como inseguras.
Como administrador, debe resolver estos conflictos manualmente. En función del tipo de conflicto, necesitará utilizar opciones avanzadas como `pgactive.pgactive_do_not_replicate`. Use estas opciones con precaución, ya que un uso incorrecto puede empeorar la situación. Debido a la variedad de posibles conflictos, no podemos proporcionar instrucciones de resolución universales.
Los conflictos divergentes se producen cuando los datos que deberían ser idénticos en diferentes nodos difieren inesperadamente. Aunque estos conflictos no deberían producirse, no todos se pueden prevenir de forma fiable con la implementación actual.
## Evitar o tolerar los conflictos
En la mayoría de los casos, puede utilizar un diseño de aplicación adecuado para evitar conflictos o hacer que la aplicación tolere los conflictos.
Los conflictos solo se producen cuando se realizan operaciones simultáneas en varios nodos. Para evitar conflictos:
+ Escriba solo en un nodo
+ Escriba en subconjuntos de bases de datos independientes en cada nodo (por ejemplo, asigne a cada nodo un esquema independiente)
Para conflictos entre INSERT e INSERT, utilice secuencias globales para evitar conflictos por completo.
Si los conflictos no son aceptables para su caso de uso, considere implementar el bloqueo distribuido a nivel de aplicación. A menudo, el mejor enfoque es diseñar la aplicación para que funcione con los mecanismos de resolución de conflictos de pgactive en lugar de intentar prevenir todos los conflictos. Para obtener más información, consulte [Tipos de conflictos](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflicttypes).
## Registro de conflictos
pgactivelink registra los incidentes de conflicto en la tabla `pgactive.pgactive_conflict_history` para ayudarle a diagnosticar y gestionar los conflictos activo-activo. El registro de conflictos en esta tabla solo se produce cuando se establece `pgactive.log_conflicts_to_table` en verdadero. La extensión pgactive también registra los conflictos en el archivo de registro de PostgreSQL cuando log\$1min\$1messages se establece en `LOG` o `lower`, independientemente de la configuración de `pgactive.log_conflicts_to_table`.
Utilice la tabla del historial de conflictos para:
+ Medir la frecuencia con la que la aplicación crea conflictos
+ Identificar dónde se producen los conflictos
+ Mejorar la aplicación para reducir las tasas de conflictos
+ Detectar casos en los que las resoluciones de conflictos no producen los resultados deseados
+ Determinar dónde necesita desencadenantes de conflictos definidos por el usuario o cambios en el diseño de la aplicación
Para los conflictos de filas, puede registrar opcionalmente los valores de las filas. Esto se controla mediante la configuración de `pgactive.log_conflicts_to_table`. Tenga en cuenta que:
+ Esta es una opción global para toda la base de datos
+ No hay ningún control por tabla sobre el registro de valores de fila
+ No se aplican límites a los números de campo, los elementos de matriz o las longitudes de los campos
+ Puede que no sea recomendable activar esta característica si trabaja con filas de varios megabytes que podrían desencadenar conflictos
Como la tabla del historial de conflictos contiene datos de todas las tablas de la base de datos (cada una con posibles esquemas diferentes), los valores de las filas registradas se almacenan como campos JSON. El JSON se crea mediante `row_to_json`, de forma similar a llamarlo directamente desde SQL. PostgreSQL no proporciona una función `json_to_row`, por lo que necesitará código específico de tabla (en PL/pgSQL, PL/Python, PL/Perl, etc.) para reconstruir una tupla de tipo compuesto a partir del JSON registrado.
**nota**
La compatibilidad para conflictos definidos por el usuario está planificada como una característica de extensión futura.
# Descripción del esquema de pgactive
El esquema de pgactive administra la replicación activo-activo en RDS para PostgreSQL. Este esquema contiene tablas que almacenan información sobre la configuración y el estado de la replicación.
**nota**
El esquema de pgactive está en evolución y está sujeto a cambios. No modifique los datos de estas tablas directamente.
Las tablas de claves del esquema de pgactive incluyen:
+ `pgactive_nodes`: almacena información sobre los nodos del grupo de replicación activo-activo.
+ `pgactive_connections`: almacena los detalles de conexión de cada nodo.
## pgactive\$1nodes
pgactive\$1nodes almacena información sobre los nodos que participan en el grupo de replicación activo-activo.
| Columna | Tipo | Collation (Intercalación) | Nullable | Predeterminado |
| --- | --- | --- | --- | --- |
| node\$1sysid | text | – | not null | – |
| node\$1timeline | oid | – | not null | – |
| node\$1dboid | oid | – | not null | – |
| node\$1status | char | – | not null | – |
| node\$1name | text | – | not null | – |
| node\$1dsn | text | – | not null | – |
| node\$1init\$1from\$1dsn | text | – | not null | – |
| node\$1read\$1only | valor booleano | – | – | false |
| node\$1seq\$1id | smallint | – | not null | – |
**node\$1sysid**
ID único para un nodo, generado durante `pgactive_create_group` o `pgactive_join_group`
**node\$1status**
Preparación del nodo:
+ **b**: configuración inicial
+ **i**: inicio
+ **c**: recuperación
+ **o**: creación de ranuras de salida
+ **r**: listo
+ **k**: interrumpido
Esta columna no indica si un nodo está conectado o desconectado.
**node\$1name**
Nombre de nodo único proporcionado por el usuario.
**node\$1dsn**
Cadena de conexión o nombre de mapeo de usuario
**node\$1init\$1from\$1dsn**
DSN a partir del cual se creó este nodo.
## pgactive\$1connection
pgactive\$1connections almacena los detalles de conexión de cada nodo.
| Columna | Tipo | Collation (Intercalación) | Nullable | Predeterminado |
| --- | --- | --- | --- | --- |
| conn\$1sysid | text | none | not null | none |
| conn\$1timeline | oid | none | not null | none |
| conn\$1dboid | oid | none | not null | none |
| conn\$1dsn | text | none | not null | none |
| conn\$1apply\$1delay | entero | none | none | none |
| conn\$1replication\$1sets | text | none | none | none |
conn\$1sysid
Identificador de nodo del nodo al que hace referencia esta entrada.
conn\$1dsn
Igual que pgactive.pgactive\$1nodes `node_dsn`.
conn\$1apply\$1delay
Si se establece, milisegundos que hay que esperar antes de aplicar cada transacción desde el nodo remoto. Principalmente para depurar. Si es nulo, se aplica el valor predeterminado global.
## Uso de conjuntos de replicación
Los conjuntos de replicación determinan qué tablas incluir o excluir de las operaciones de replicación. De forma predeterminada, todas las tablas se replican a menos que especifique lo contrario mediante las siguientes funciones:
+ `pgactive_exclude_table_replication_set()`: excluye las tablas especificadas de la replicación
+ `pgactive_include_table_replication_set()`: incluye las tablas especificadas en la replicación
**nota**
Antes de configurar los conjuntos de replicación, tenga en cuenta lo siguiente:
Puede configurar la inclusión o exclusión de tablas solo después de ejecutar `pgactive_create_group()` pero antes de `pgactive_join_group()`.
Después de usar `pgactive_exclude_table_replication_set()`, no puede usar `pgactive_include_table_replication_set()`.
Después de usar `pgactive_include_table_replication_set()`, no puede usar `pgactive_exclude_table_replication_set()`.
El sistema gestiona las tablas recién creadas de forma diferente en función de la configuración inicial:
+ Si excluyó las tablas: todas las tablas nuevas que se creen después de `pgactive_join_group()` se incluyen automáticamente en la replicación
+ Si incluyó las tablas: todas las tablas nuevas que se creen después de `pgactive_join_group()` se excluyen automáticamente de la replicación.
Para ver la configuración del conjunto de réplicas de una tabla específica, utilice la función `pgactive.pgactive_get_table_replication_sets()`.
# Referencia de funciones de pgactive
A continuación, puede encontrar una lista de funciones de pgactive con sus parámetros, valores de devolución y notas prácticas de uso para ayudarle a utilizarlas de forma eficaz:
## get\$1last\$1applied\$1xact\$1info
Recupera la información de la última transacción aplicada a un nodo específico.
**Arguments**
+ sysid (texto): OID de línea temporal
+ dboid (OID)
**Tipo de devolución**
Hace lo siguiente:
+ last\$1applied\$1xact\$1id (OID)
+ last\$1applied\$1xact\$1committs (marca temporal con zona horaria)
+ last\$1applied\$1xact\$1at (marca temporal con zona horaria)
**Notas de uso**
Use esta función para recuperar la información de la última transacción aplicada a un nodo específico.
## pgactive\$1apply\$1pause
Pausa el proceso de aplicación de la replicación.
**Arguments**
Ninguno
**Tipo de devolución**
booleano
**Notas de uso**
Llame a esta función para pausar el proceso de aplicación de la replicación.
## pgactive\$1apply\$1resume
Reanuda el proceso de aplicación de la replicación.
**Arguments**
Ninguno
**Tipo de devolución**
void
**Notas de uso**
Llame a esta función para reanudar el proceso de aplicación de la replicación.
## pgactive\$1is\$1apply\$1paused
Comprueba si la aplicación de la replicación está actualmente en pausa.
**Arguments**
Ninguno
**Tipo de devolución**
booleano
**Notas de uso**
Use esta función para comprobar si la aplicación de la replicación está actualmente en pausa.
## pgactive\$1create\$1group
Crea un grupo pgactive convirtiendo una base de datos independiente en el nodo inicial.
**Arguments**
+ node\$1name (texto)
+ node\$1dsn (texto)
+ apply\$1delay integer DEFAULT NULL::integer - replication\$1sets text[] DEFAULT ARRAY[‘default’::text]
**Tipo de devolución**
void
**Notas de uso**
Crea un grupo pgactive convirtiendo una base de datos independiente en el nodo inicial. La función realiza comprobaciones de integridad antes de transformar el nodo en un nodo de pgactive. Antes de usar esta función, asegúrese de que el clúster de PostgreSQL tenga suficientes `max_worker_processes` disponibles para admitir los trabajadores en segundo plano de pgactive.
## pgactive\$1detach\$1nodes
Elimina los nodos especificados del grupo pgactive.
**Arguments**
+ p\$1nodes (text[])
**Tipo de devolución**
void
**Notas de uso**
Use esta función para eliminar los nodos especificados del grupo pgactive.
## pgactive\$1exclude\$1table\$1replication\$1set
Excluye una tabla específica de la replicación.
**Arguments**
+ p\$1relation (regclass)
**Tipo de devolución**
void
**Notas de uso**
Utilice esta función para excluir una tabla específica de la replicación.
## pgactive\$1get\$1replication\$1lag\$1info
Recupera información detallada sobre el retraso de la replicación, incluidos los detalles del nodo, el estado de WAL y los valores de LSN.
**Arguments**
Ninguno
**Tipo de devolución**
SETOF record - node\$1name text - node\$1sysid text - application\$1name text - slot\$1name text - active boolean - active\$1pid integer - pending\$1wal\$1decoding bigint - Tamaño aproximado de WAL en bytes que se decodificará en el nodo emisor - pending\$1wal\$1to\$1apply bigint - Tamaño aproximado del WAL en bytes que se aplicará en el nodo receptor - restart\$1lsn pg\$1lsn - confirmed\$1flush\$1lsn pg\$1lsn - sent\$1lsn pg\$1lsn - write\$1lsn pg\$1lsn - flush\$1lsn pg\$1lsn - replay\$1lsn pg\$1lsn
**Notas de uso**
Llame a esta función para recuperar información sobre el retraso de la replicación, incluidos los detalles del nodo, el estado de WAL y los valores de LSN.
## pgactive\$1get\$1stats
Recupera las estadísticas de replicación de pgactive.
**Arguments**
Ninguno
**Tipo de devolución**
SETOF record - rep\$1node\$1id oid - rilocalid oid - riremoteid text - nr\$1commit bigint - nr\$1rollback bigint - nr\$1insert bigint - nr\$1insert\$1conflict bigint - nr\$1update bigint - nr\$1update\$1conflict bigint - nr\$1delete bigint - nr\$1delete\$1conflict bigint - nr\$1disconnect bigint
**Notas de uso**
Utilice esta función para recuperar las estadísticas de replicación de pgactive.
## pgactive\$1get\$1table\$1replication\$1sets
Obtiene la configuración del conjunto de replicación de una relación específica.
**Arguments**
+ relación (regclass)
**Tipo de devolución**
Registro SETOF
**Notas de uso**
Llame a esta función para obtener la configuración del conjunto de replicación de una relación específica.
## pgactive\$1include\$1table\$1replication\$1set
Incluye una tabla específica en la replicación.
**Arguments**
+ p\$1relation (regclass)
**Tipo de devolución**
void
**Notas de uso**
Utilice esta función para incluir una tabla específica en la replicación.
## pgactive\$1join\$1group
Agrega un nodo a un grupo pgactive existente.
**Arguments**
+ node\$1name (texto)
+ node\$1dsn (texto)
+ join\$1using\$1dsn (texto)
+ apply\$1delay (entero, opcional)
+ replication\$1sets (text[], predeterminado: ['default'])
+ bypass\$1collation\$1check (booleano, predeterminado: falso)
+ bypass\$1node\$1identifier\$1creation (booleano, predeterminado: falso)
+ bypass\$1user\$1tables\$1check (booleano, predeterminado: falso)
**Tipo de devolución**
void
**Notas de uso**
Llame a esta función para agregar un nodo a un grupo pgactive existente. Asegúrese de que el clúster de PostgreSQL tenga suficientes max\$1worker\$1processes para los trabajadores en segundo plano de pgactive.
## pgactive\$1remove
Elimina todos los componentes de pgactive del nodo local.
**Arguments**
+ force (booleano, predeterminado: falso)
**Tipo de devolución**
void
**Notas de uso**
Llame a esta función para eliminar todos los componentes de pgactive del nodo local.
## pgactive\$1snowflake\$1id\$1nextval
Genera valores de secuencia únicos específicos del nodo.
**Arguments**
+ regclass
**Tipo de devolución**
bigint
**Notas de uso**
Utilice esta función para generar valores de secuencia únicos específicos del nodo.
## pgactive\$1update\$1node\$1conninfo
Actualiza la información de conexión de un nodo de pgactive.
**Arguments**
+ node\$1name\$1to\$1update (texto)
+ node\$1dsn\$1to\$1update (texto)
**Tipo de devolución**
void
**Notas de uso**
Use esta función para actualizar la información de conexión de un nodo de pgactive.
## pgactive\$1wait\$1for\$1node\$1ready
Supervisa el progreso de las operaciones de creación o unión de grupos.
**Arguments**
+ timeout (entero, predeterminado: 0)
+ progress\$1interval (entero, predeterminado: 60)
**Tipo de devolución**
void
**Notas de uso**
Llame a esta función para supervisar el progreso de las operaciones de creación o unión de grupos.
# Gestión de conflictos en la replicación activa-activa
La extensión `pgactive` funciona por base de datos y no por clúster. Cada instancia de base de datos que utiliza `pgactive` es una instancia independiente y puede aceptar cambios de datos de cualquier fuente. Cuando se envía un cambio a una instancia de base de datos, PostgreSQL lo confirma localmente y, a continuación, utiliza `pgactive` para replicar el cambio de forma asíncrona en otras instancias de base de datos. Cuando dos instancias de base de datos de PostgreSQL actualizan el mismo registro prácticamente al mismo tiempo, puede producirse un conflicto.
La extensión `pgactive` proporciona mecanismos para la detección y la resolución automática de conflictos. Realiza un seguimiento de la marca de tiempo en que se confirmó la transacción en ambas instancias de base de datos y aplica automáticamente el cambio con la última marca de tiempo. La extensión `pgactive` también registra cuando se produce un conflicto en la tabla `pgactive.pgactive_conflict_history`.
El `pgactive.pgactive_conflict_history` seguirá creciendo. Puede definir una política de depuración. Esto se puede hacer borrando algunos registros de forma regular o definiendo un esquema de partición para esta relación (y, luego, separando, descartando o truncando las particiones de interés). Para implementar la política de depuración de forma regular, una opción es usar la extensión `pg_cron` Consulte la siguiente información con un ejemplo para la tabla de historial de `pg_cron` [Programación de mantenimiento con la extensión pg\$1cron de PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL_pg_cron.html).
# Gestión de secuencias en la replicación activa-activa
Una instancia de base de datos de RDS para PostgreSQL con la extensión `pgactive` utiliza dos mecanismos de secuencia diferentes para generar valores únicos.
**Secuencias globales**
Para usar una secuencia global, cree una secuencia local con la instrucción `CREATE SEQUENCE`. Utilice `pgactive.pgactive_snowflake_id_nextval(seqname)` en lugar de `usingnextval(seqname)` para obtener el siguiente valor único de la secuencia.
En el siguiente ejemplo se crea una secuencia global.
```
app=> CREATE TABLE gstest (
id bigint primary key,
parrot text
);
```
```
app=>CREATE SEQUENCE gstest_id_seq OWNED BY gstest.id;
```
```
app=> ALTER TABLE gstest \
ALTER COLUMN id SET DEFAULT \
pgactive.pgactive_snowflake_id_nextval('gstest_id_seq');
```
**Secuencias particionadas**
En las secuencias divididas o particionadas, se utiliza una secuencia PostgreSQL normal en cada nodo. Cada secuencia se incrementa en la misma cantidad y comienza con diferentes desplazamientos. Por ejemplo, con el paso 100, el nodo 1 genera una secuencia como 101, 201, 301, etc., y el nodo 2 genera una secuencia como 102, 202, 302, etc. Este esquema funciona bien incluso si los nodos no pueden comunicarse durante períodos prolongados, pero requiere que el diseñador especifique un número máximo de nodos al establecer el esquema y requiere una configuración por nodo. Los errores pueden provocar fácilmente la superposición de secuencias.
Es relativamente sencillo configurar este enfoque con `pgactive` creando la secuencia deseada en un nodo de la siguiente manera:
```
CREATE TABLE some_table (generated_value bigint primary key);
```
```
app=> CREATE SEQUENCE some_seq INCREMENT 100 OWNED BY some_table.generated_value;
```
```
app=> ALTER TABLE some_table ALTER COLUMN generated_value SET DEFAULT nextval('some_seq');
```
A continuación, llame a `setval` en cada nodo para dar un valor inicial de desplazamiento diferente, de la siguiente manera.
```
app=>
-- On node 1
SELECT setval('some_seq', 1);
-- On node 2
SELECT setval('some_seq', 2);
```