Replicación cruzada entre PostgreSQL y MySQL

A grandes rasgos, hablaré sobre la replicación cruzada entre PostgreSQL y MySQL, así como sobre los métodos para configurar la replicación cruzada entre estos dos servidores de bases de datos. Por lo general, las bases de datos en replicación cruzada se consideran homogéneas, y este es un método conveniente para pasar de un servidor RDBMS a otro.

Se considera que las bases de datos PostgreSQL y MySQL son relacionales, pero con extensiones adicionales ofrecen capacidades NoSQL. Aquí discutiremos la replicación entre PostgreSQL y MySQL desde el punto de vista de las bases de datos relacionales.

No vamos a describir toda la mecánica interna, solo los principios básicos para que tenga una idea de la configuración de la replicación entre servidores de bases de datos, sus ventajas, limitaciones y escenarios de uso.

Generalmente, la replicación entre dos servidores de bases de datos idénticos se realiza en modo binario o mediante consultas entre el nodo principal (también conocido como publicador, maestro o activo) y el secundario (suscriptor, en espera o pasivo). El objetivo de la replicación es proporcionar en tiempo real una copia de la base de datos principal en el lado secundario. En este proceso, los datos se transmiten del nodo principal al secundario, es decir, de activo a pasivo, ya que la replicación se realiza en una sola dirección. Sin embargo, es posible configurar la replicación entre dos bases de datos en ambas direcciones, de modo que los datos se transmitan del secundario al principal en una configuración de 'activo-activo'. Todo esto, incluida la replicación en cascada, es posible entre dos o más servidores de bases de datos idénticos. La configuración 'activo-activo' o 'activo-pasivo' depende de la necesidad, la disponibilidad de tales opciones en la configuración de origen o el uso de soluciones externas para la configuración y compromisos existentes.

La configuración descrita es posible entre diferentes servidores de bases de datos. Un servidor puede configurarse para recibir datos replicados de otro servidor de bases de datos, manteniendo al mismo tiempo instantáneas de los datos replicados en tiempo real. MySQL y PostgreSQL ofrecen la mayoría de estas configuraciones por sí mismos o mediante extensiones de terceros, incluyendo métodos de log binario, bloqueo de disco y métodos basados en operadores y filas.

La replicación cruzada entre MySQL y PostgreSQL es necesaria para migrar una base de datos de un servidor a otro. Estas bases de datos utilizan diferentes protocolos, por lo que no se pueden conectar directamente. Para establecer el intercambio de datos, se puede utilizar una herramienta externa de código abierto, como pg_chameleon.

Qué es pg_chameleon

pg_chameleon es un sistema de replicación de MySQL a PostgreSQL en Python 3. Utiliza la biblioteca de código abierto mysql-replication, también en Python. Las imágenes de las filas se extraen de las tablas de MySQL y se guardan como objetos JSONB en la base de datos PostgreSQL, luego se descifran con la función pl/pgsql y se reproducen en la base de datos PostgreSQL.

Funciones de pg_chameleon

Varios esquemas de MySQL de un clúster se pueden replicar en una única base de datos de PostgreSQL con una configuración de "uno a muchos".
Los nombres de los esquemas de origen y destino no pueden coincidir.
Los datos de replicación se pueden extraer de una réplica en cascada de MySQL.
Las tablas que no se pueden replicar o que generan errores se excluyen.
Cada función de replicación es controlada por demonios.
Control a través de parámetros y archivos de configuración basados en YAML.

Ejemplo

Host
vm1
vm2

Versión del sistema operativo
CentOS Linux 7.6 x86_64
CentOS Linux 7.5 x86_64

Versión del servidor de base de datos
MySQL 5.7.26
PostgreSQL 10.5

Puerto de la base de datos
3306
5433

Dirección IP
192.168.56.102
192.168.56.106

Primero, prepare todos los componentes necesarios para instalar pg_chameleon. En este ejemplo, se instala Python 3.6.8, que crea un entorno virtual y lo activa.

$> wget https://www.python.org/ftp/python/3.6.8/Python-3.6.8.tar.xz
$> tar -xJf Python-3.6.8.tar.xz
$> cd Python-3.6.8
$> ./configure --enable-optimizations
$> make altinstall

Después de instalar Python 3.6 con éxito, debe cumplir con los otros requisitos, como crear y activar un entorno virtual. Además, el módulo pip se actualiza a la última versión y se usa para instalar pg_chameleon. En los comandos a continuación, se establece deliberadamente pg_chameleon en 2.0.9, aunque la última versión es 2.0.10. Esto se hace para evitar nuevos errores en la versión actualizada.

$> python3.6 -m venv venv
$> source venv/bin/activate
(venv) $> pip install pip --upgrade
(venv) $> pip install pg_chameleon==2.0.9

Luego llamamos a pg_chameleon (chameleon es el comando) con el argumento set_configuration_files para habilitar pg_chameleon y crear directorios y archivos de configuración predeterminados.

(venv) $> chameleon set_configuration_files
creando directorio /root/.pg_chameleon
creando directorio /root/.pg_chameleon/configuration/
creando directorio /root/.pg_chameleon/logs/
creando directorio /root/.pg_chameleon/pid/
copiando configuración de ejemplo en /root/.pg_chameleon/configuration//config-example.yml

Ahora creamos una copia de config-example.yml como default.yml para que se convierta en el archivo de configuración predeterminado. A continuación se muestra un ejemplo de archivo de configuración para este caso.

$> cat default.yml
---
#ajustes globales
pid_dir: '~/.pg_chameleon/pid/'
log_dir: '~/.pg_chameleon/logs/'
log_dest: file
log_level: info
log_days_keep: 10
rollbar_key: ''
rollbar_env: ''

# type_override permite al usuario anular la conversión de tipo predeterminada a una diferente.
type_override:
  "tinyint(1)":
    override_to: boolean
    override_tables:
      - "*"

#conexión de destino de postgres
pg_conn:
  host: "192.168.56.106"
  port: "5433"
  user: "usr_replica"
  password: "pass123"
  database: "db_replica"
  charset: "utf8"

sources:
  mysql:
    db_conn:
      host: "192.168.56.102"
      port: "3306"
      user: "usr_replica"
      password: "pass123"
      charset: 'utf8'
      connect_timeout: 10
    schema_mappings:
      world_x: pgworld_x
    limit_tables:
#      - delphis_mediterranea.foo
    skip_tables:
#      - delphis_mediterranea.bar
    grant_select_to:
      - usr_readonly
    lock_timeout: "120s"
    my_server_id: 100
    replica_batch_size: 10000
    replay_max_rows: 10000
    batch_retention: '1 day'
    copy_max_memory: "300M"
    copy_mode: 'file'
    out_dir: /tmp
    sleep_loop: 1
    on_error_replay: continue
    on_error_read: continue
    auto_maintenance: "disabled"
    gtid_enable: No
    type: mysql
    skip_events:
      insert:
        - delphis_mediterranea.foo #omitir inserciones en la tabla delphis_mediterranea.foo
      delete:
        - delphis_mediterranea #omitir eliminaciones en el esquema delphis_mediterranea
      update:

El archivo de configuración en este caso es un ejemplo del archivo de pg_chameleon con ligeras modificaciones de acuerdo a los entornos de origen y destino, y a continuación se ofrece un resumen de las diferentes secciones del archivo de configuración.

En el archivo de configuración default.yml hay una sección de parámetros globales (global settings), donde se pueden gestionar configuraciones como la ubicación del archivo de bloqueo, la ubicación de los logs, el período de retención de los logs, etc. A continuación, hay una sección de sobrescritura de tipos (type override), donde se especifica un conjunto de reglas para anular tipos durante la replicación. En el ejemplo por defecto se utiliza una regla de sobrescritura de tipo que convierte tinyint(1) en un valor booleano. En la siguiente sección, se indican los detalles de la conexión a la base de datos de destino. En nuestro caso, se trata de una base de datos PostgreSQL, denominada pg_conn. En la última sección, especificamos los datos de las fuentes, es decir, los parámetros de conexión de la base de datos de origen, el mapeo de esquemas entre las bases de datos de origen y destino, las tablas a omitir, los tiempos de espera, la memoria, el tamaño del paquete. Tenga en cuenta que "sources" está en plural, lo que significa que podemos añadir varias bases de datos de origen para una sola base de datos de destino, configurando una relación de "muchos a uno".

La base de datos world_x en el ejemplo contiene 4 tablas con filas que la comunidad de MySQL ofrece como ejemplo. Se puede cargar aquí. El ejemplo de la base de datos se proporciona en forma de un archivo tar y un archivo comprimido con instrucciones sobre cómo crear e importar filas.

En las bases de datos MySQL y PostgreSQL se crea un usuario especial con el mismo nombre usr_replica. En MySQL se le otorgan derechos adicionales para leer todas las tablas replicadas.

mysql> CREATE USER usr_replica ;
mysql> SET PASSWORD FOR usr_replica='pass123';
mysql> GRANT ALL ON world_x.* TO 'usr_replica';
mysql> GRANT RELOAD ON *.* to 'usr_replica';
mysql> GRANT REPLICATION CLIENT ON *.* to 'usr_replica';
mysql> GRANT REPLICATION SLAVE ON *.* to 'usr_replica';
mysql> FLUSH PRIVILEGES;

En el lado de PostgreSQL se crea la base de datos db_replica, que aceptará cambios de la base de datos MySQL. El usuario usr_replica en PostgreSQL se configura automáticamente como propietario de los dos esquemas pgworld_x y sch_chameleon, que contienen las tablas replicadas reales y las tablas con catálogos de replicación, respectivamente. La configuración automática se controla mediante el argumento create_replica_schema, como verás a continuación.

postgres=# CREATE USER usr_replica WITH PASSWORD 'pass123';
CREATE ROLE
postgres=# CREATE DATABASE db_replica WITH OWNER usr_replica;
CREATE DATABASE

La base de datos MySQL se configura con cambios en algunos parámetros para prepararla para la replicación, como se muestra a continuación. Será necesario reiniciar el servidor de bases de datos para que los cambios surtan efecto.

$> vi /etc/my.cnf
binlog_format= ROW
binlog_row_image=FULL
log-bin = mysql-bin
server-id = 1

Ahora es importante verificar la conexión a ambos servidores de bases de datos para que no surjan problemas al ejecutar comandos pg_chameleon.

En el nodo de PostgreSQL:

$> mysql -u usr_replica -Ap'admin123' -h 192.168.56.102 -D world_x

En el nodo de MySQL:

$> psql -p 5433 -U usr_replica -h 192.168.56.106 db_replica

Los siguientes tres comandos pg_chameleon (chameleon) preparan el entorno, añaden la fuente e inicializan la réplica. El argumento create_replica_schema en pg_chameleon crea el esquema por defecto (sch_chameleon) y el esquema de replicación (pgworld_x) en la base de datos PostgreSQL, como ya mencionamos. El argumento add_source añade la base de datos de origen a la configuración, leyendo el archivo de configuración (default.yml), y en nuestro caso se trata de mysql, y init_replica inicializa la configuración basada en los parámetros del archivo de configuración.

$> chameleon create_replica_schema --debug
$> chameleon add_source --config default --source mysql --debug
$> chameleon init_replica --config default --source mysql --debug

Los resultados de estos tres comandos indican claramente su ejecución exitosa. Todos los fallos o errores de sintaxis se indican en mensajes simples y comprensibles, con sugerencias para solucionar los problemas.

Finalmente, iniciemos la replicación con start_replica y obtengamos un mensaje de ejecución exitosa.

$> chameleon start_replica --config default --source mysql 
output: Iniciando el proceso de replicación para la fuente mysql

El estado de la replicación se puede consultar con el argumento show_status, y los errores se pueden ver con el argumento show_errors.

Resultado.

Como ya hemos mencionado, cada función de replicación es gestionada por demonios. Para verlos, consultemos la tabla de procesos con el comando Linux ps, como se muestra a continuación.

Resultado.

La replicación no se considera configurada hasta que la probemos en tiempo real, como se muestra a continuación. Creamos una tabla, insertamos un par de registros en la base de datos MySQL y llamamos al argumento sync_tables en pg_chameleon para actualizar a los demonios y replicar la tabla con los registros en la base de datos PostgreSQL.

mysql> create table t1 (n1 int primary key, n2 varchar(10));
Consulta OK, 0 filas afectadas (0.01 seg)
mysql> insert into t1 values (1,'one');
Consulta OK, 1 fila afectada (0.00 seg)
mysql> insert into t1 values (2,'two');
Consulta OK, 1 fila afectada (0.00 seg)

$> chameleon sync_tables --tables world_x.t1 --config default --source mysql
Proceso de sincronización de tablas para la fuente mysql iniciado.

Para confirmar los resultados de la prueba, consultamos la tabla de la base de datos PostgreSQL y mostramos las filas.

$> psql -p 5433 -U usr_replica -d db_replica -c "select * from pgworld_x.t1";
 n1 |  n2
----+-------
  1 | one
  2 | two

Si estamos realizando una migración, los siguientes comandos de pg_chameleon completarán el proceso. Estos comandos deben ejecutarse después de que nos aseguremos de que las filas de todas las tablas destino han sido replicadas, y el resultado será una base de datos PostgreSQL transferida ordenadamente sin referencias a la base de datos original o al esquema de replicación (sch_chameleon).

$> chameleon stop_replica --config default --source mysql 
$> chameleon detach_replica --config default --source mysql --debug

Opcionalmente, los siguientes comandos pueden eliminar la configuración original y el esquema de replicación.

$> chameleon drop_source --config default --source mysql --debug
$> chameleon drop_replica_schema --config default --source mysql --debug

Ventajas de pg_chameleon

Configuración y configuración sencillas.
Facilidad para solucionar problemas y detectar anomalías con mensajes de error claros.
Se pueden agregar tablas especiales adicionales a la replicación después de la inicialización, sin cambiar el resto de la configuración.
Se pueden configurar varias bases de datos de origen para un único destino, lo cual es muy conveniente si estás combinando datos de una o varias bases de datos MySQL en una sola base de datos PostgreSQL.
No es necesario replicar las tablas seleccionadas.

Desventajas de pg_chameleon

Solo es compatible con MySQL 5.5 y versiones posteriores como fuente y PostgreSQL 9.5 y versiones posteriores como base de datos de destino.
Cada tabla debe tener una clave primaria o única, de lo contrario, las tablas se inicializan en el proceso init_replica, pero no se replican.
La replicación unidireccional es solo de MySQL a PostgreSQL. Por lo tanto, solo es adecuada para el esquema "activo-pasivo".
La base de datos de origen solo puede ser MySQL, y el soporte para la base de datos PostgreSQL como origen es solo experimental y limitado (para más información aquí)

Resumen de pg_chameleon

El método de replicación en pg_chameleon es excelente para la migración de bases de datos de MySQL a PostgreSQL. Un inconveniente significativo es que la replicación es unidireccional, por lo que los especialistas en bases de datos probablemente no querrán usarlo para algo más que migración. Pero el problema de la replicación unidireccional se puede resolver con otra herramienta de código abierto: SymmetricDS.

Lea más en la documentación oficial aquí. La ayuda para la línea de comandos se puede encontrar aquí.

Resumen de SymmetricDS

SymmetricDS es una herramienta de código abierto que replica cualquier base de datos en cualquier otra base de datos común: Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird y otros ejemplos de bases de datos en la nube, como Redshift y Azure, etc. Las funciones disponibles incluyen: sincronización de bases de datos y archivos, replicación de múltiples bases de datos principales, sincronización filtrada, transformación y más. Es una herramienta basada en Java, y se requiere la versión estándar de JRE o JDK (versión 8.0 o superior). Aquí se pueden registrar los cambios de datos mediante triggers en la base de datos de origen y enviarlos a la base de datos de destino correspondiente en forma de paquetes.

Características de SymmetricDS

La herramienta es independiente de la plataforma, es decir, dos o más bases de datos diferentes pueden intercambiar datos.
Las bases de datos relacionales se sincronizan mediante el registro de cambios de datos, mientras que las bases de datos basadas en sistemas de archivos utilizan la sincronización de archivos.
Replicación bidireccional utilizando métodos Push y Pull basados en un conjunto de reglas.
La transferencia de datos es posible a través de redes seguras y redes con baja capacidad de ancho de banda.
Recuperación automática al reanudar la operación de nodos tras una falla y resolución automática de conflictos.
Compatibilidad con la nube y eficientes API de extensiones.

Ejemplo

SymmetricDS se puede configurar de dos maneras:
Un nodo principal (padre) que coordina centralmente la replicación de datos entre dos nodos secundarios (hijos), y el intercambio de datos entre los nodos secundarios se realiza únicamente a través del nodo principal.
Un nodo activo (nodo 1) puede intercambiar datos para replicación con otro nodo activo (nodo 2) sin intermediarios.

En ambas configuraciones, el intercambio de datos se realiza mediante Push y Pull. En este ejemplo, examinaremos la configuración 'activo-activo'. Describir toda la arquitectura llevaría demasiado tiempo, así que consulte la guía, para obtener más información sobre SymmetricDS.

Instalar SymmetricDS es muy sencillo: descargue la versión de código abierto en un archivo zip desde aquí y extráigala donde desee. En la tabla a continuación se incluyen detalles sobre la ubicación de instalación y la versión de SymmetricDS en este ejemplo, así como las versiones de bases de datos, versiones de Linux, direcciones IP y puertos para ambos nodos.

Host
vm1
vm2

Versión del sistema operativo
CentOS Linux 7.6 x86_64
CentOS Linux 7.6 x86_64

Versión del servidor de base de datos
MySQL 5.7.26
PostgreSQL 10.5

Puerto de la base de datos
3306
5832

Dirección IP
192.168.1.107
192.168.1.112

Versión de SymmetricDS
SymmetricDS 3.9
SymmetricDS 3.9

Ruta de instalación de SymmetricDS
/usr/local/symmetric-server-3.9.20
/usr/local/symmetric-server-3.9.20

Nombre del nodo SymmetricDS
corp-000
store-001

Aquí estamos instalando SymmetricDS en /usr/local/symmetric-server-3.9.20, donde se almacenarán varios directorios y archivos anidados. Nos interesan los directorios anidados samples y engines. En el directorio samples se encuentran ejemplos de archivos de configuración con propiedades del nodo, así como ejemplos de scripts SQL para un inicio rápido de la demostración.

En el directorio samples vemos tres archivos de configuración con propiedades del nodo: el nombre muestra la naturaleza del nodo en un esquema determinado.

corp-000.properties
store-001.properties
store-002.properties

SymmetricDS incluye todos los archivos necesarios de configuración para un esquema básico de 3 nodos (opción 1), y esos mismos archivos se pueden utilizar para un esquema de 2 nodos (opción 2). Copiamos el archivo de configuración necesario del directorio samples al directorio engines en el host vm1. Queda así:

$> cat engines/corp-000.properties
engine.name=corp-000
db.driver=com.mysql.jdbc.Driver
db.url=jdbc:mysql://192.168.1.107:3306/replica_db?autoReconnect=true&useSSL=false
db.user=root
db.password=admin123
registration.url=
sync.url=http://192.168.1.107:31415/sync/corp-000
group.id=corp
external.id=000

Este nodo en la configuración de SymmetricDS se llama corp-000, y la conexión a la base de datos es manejada por el controlador mysql jdbc, que utiliza la cadena de conexión que se mencionó anteriormente y las credenciales de inicio de sesión. Nos conectamos a la base de datos replica_db, y durante la creación del esquema se crearán las tablas. sync.url muestra el lugar de conexión con el nodo para la sincronización.

El nodo 2 en el host vm2 se configura como store-001, y el resto se detalla en el archivo node.properties que se presenta a continuación. El nodo store-001 ejecuta una base de datos PostgreSQL, y pgdb_replica es la base de datos para la replicación. registration.url permite que el host vm2 se comunique con el host vm1 y obtenga de él los detalles de la configuración.

$> cat engines/store-001.properties
engine.name=store-001
db.driver=org.postgresql.Driver
db.url=jdbc:postgresql://192.168.1.112:5832/pgdb_replica
db.user=postgres
db.password=admin123
registration.url=http://192.168.1.107:31415/sync/corp-000
group.id=store
external.id=001

El ejemplo completo de SymmetricDS contiene parámetros para configurar la replicación bidireccional entre dos servidores de bases de datos (dos nodos). Los pasos a continuación se realizan en el host vm1 (corp-000), que creará un ejemplo de esquema con 4 tablas. Luego, la ejecución de create-sym-tables mediante el comando symadmin crea las tablas de catálogos, donde se almacenarán las reglas y la dirección de la replicación entre los nodos. Por último, se cargan datos de ejemplo en las tablas.

vm1$> cd /usr/local/symmetric-server-3.9.20/bin
vm1$> ./dbimport --engine corp-000 --format XML create_sample.xml
vm1$> ./symadmin --engine corp-000 create-sym-tables
vm1$> ./dbimport --engine corp-000 insert_sample.sql

En el ejemplo, las tablas item e item_selling_price están configuradas automáticamente para replicarse desde corp-000 a store-001, mientras que las tablas sale (sale_transaction y sale_return_line_item) están configuradas automáticamente para replicarse desde store-001 a corp-000. Ahora creamos el esquema en la base de datos PostgreSQL en el host vm2 (store-001) para prepararla para recibir datos de corp-000.

vm2$> cd /usr/local/symmetric-server-3.9.20/bin
vm2$> ./dbimport --engine store-001 --format XML create_sample.xml

Debemos asegurarnos de que en la base de datos MySQL en vm1 haya ejemplos de tablas y las tablas de catalogación de SymmetricDS. Tenga en cuenta que las tablas del sistema de SymmetricDS (con el prefijo sym_) ahora están disponibles solo en el nodo corp-000, porque allí ejecutamos el comando create-sym-tables y gestionaremos la replicación. Además, en la base de datos del nodo store-001 habrá solo 4 tablas de ejemplo sin datos.

Todo. El entorno está listo para ejecutar los procesos del servidor sym en ambos nodos, como se muestra a continuación.

vm1$> cd /usr/local/symmetric-server-3.9.20/bin
vm1$> sym 2>&1 &

Los registros de logs se envían al archivo de log en segundo plano (symmetric.log) en la carpeta de logs en el directorio donde está instalado SymmetricDS, así como a la salida estándar. El servidor sym ahora se puede iniciar en el nodo store-001.

vm2$> cd /usr/local/symmetric-server-3.9.20/bin
vm2$> sym 2>&1 &

Si ejecutas el proceso del servidor sym en el host vm2, creará las tablas del directorio SymmetricDS también en la base de datos PostgreSQL. Si ejecutas el proceso del servidor sym en ambos nodos, se coordinarán entre sí para replicar datos desde corp-000 a store-001. Si después de unos segundos solicitamos las 4 tablas de ambos lados, veremos que la replicación se ha realizado con éxito. O se puede enviar la carga inicial al nodo store-001 desde corp-000 con el siguiente comando.

vm1$> ./symadmin --engine corp-000 reload-node 001

En este punto, se inserta un nuevo registro en la tabla item en la base de datos MySQL en el nodo corp-000 (host: vm1), y se puede verificar su replicación en la base de datos PostgreSQL en el nodo store-001 (host: vm2). Vemos la operación Pull para mover los datos de corp-000 a store-001.

mysql> insert into item values ('22000002','Jelly Bean');
Query OK, 1 row affected (0.00 sec)

vm2$> psql -p 5832 -U postgres pgdb_replica -c "select * from item"
 item_id  |   name
----------+-----------
 11000001 | Yummy Gum
 22000002 | Jelly Bean
(2 rows)

Para realizar la operación Push y mover datos de store-001 a corp-000, insertamos un registro en la tabla sale_transaction y verificamos que la replicación se ha realizado.

Resultado.

Vemos una configuración exitosa de replicación bidireccional de las tablas de ejemplo entre las bases de datos MySQL y PostgreSQL. Para configurar la replicación para nuevas tablas de usuario, realizamos las siguientes acciones. Creamos la tabla t1 como ejemplo y configuramos las reglas de su replicación de la siguiente manera. Así configuramos la replicación solo de corp-000 a store-001.

mysql> create table  t1 (no integer);
Query OK, 0 rows affected (0.01 sec)

mysql> insert into sym_channel (channel_id,create_time,last_update_time) 
values ('t1',current_timestamp,current_timestamp);
Query OK, 1 row affected (0.01 sec)

mysql> insert into sym_trigger (trigger_id, source_table_name,channel_id,
last_update_time, create_time) values ('t1', 't1', 't1', current_timestamp,
current_timestamp);
Query OK, 1 row affected (0.01 sec)

mysql> insert into sym_trigger_router (trigger_id, router_id,
Initial_load_order, create_time,last_update_time) values ('t1',
'corp-2-store-1', 1, current_timestamp,current_timestamp);
Query OK, 1 row affected (0.01 sec)

Luego, la configuración recibe una notificación sobre el cambio en el esquema, es decir, la adición de una nueva tabla, utilizando el comando symadmin con el argumento sync-triggers, que recrea los disparadores para hacer coincidir las definiciones de las tablas. Se ejecuta send-schema para enviar los cambios del esquema al nodo store-001, y la replicación de la tabla t1 está configurada.

vm1$> ./symadmin -e corp-000 --node=001 sync-triggers    
vm1$> ./symadmin send-schema -e corp-000 --node=001 t1

Ventajas de SymmetricDS

Instalación y configuración sencillas, incluyendo un conjunto listo de archivos con parámetros para crear un esquema con tres o dos nodos.
Interoperabilidad de bases de datos e independencia de la plataforma, incluyendo servidores, laptops y dispositivos móviles.
Replicación de cualquier base de datos a otra, localmente, en WAN o en la nube.
Capacidad para funcionar de manera óptima con un par de bases de datos o con miles de ellas para facilitar la replicación.
Versión de pago con interfaz gráfica y excelente soporte.

Desventajas de SymmetricDS

Es necesario definir manualmente en la línea de comandos las reglas y la dirección de la replicación mediante operadores SQL para cargar las tablas de catálogos, lo que puede resultar incómodo.
Configurar muchas tablas para la replicación puede ser tedioso si no se utilizan scripts para crear operadores SQL que definan las reglas y la dirección de la replicación.
Se registra demasiada información en los logs, y a veces es necesario organizar el archivo de logs para que no ocupe demasiado espacio.

Conclusiones sobre SymmetricDS

SymmetricDS permite configurar la replicación bidireccional entre dos, tres e incluso varios miles de nodos, para realizar replicación y sincronizar archivos. Esta es una herramienta única que lleva a cabo muchas tareas de manera autónoma, como la recuperación automática de datos después de largos periodos de inactividad en un nodo, intercambio de datos seguro y eficiente entre nodos a través de HTTPS, gestión automática de conflictos basada en un conjunto de reglas, etc. SymmetricDS realiza replicación entre cualquier base de datos, por lo que se puede usar para una variedad de escenarios, incluyendo migración, actualización a una nueva versión, distribución, filtración y transformación de datos en diferentes plataformas.

Ejemplo creado basado en la oficial guía rápida de SymmetricDS. En la guía del usuario se describen detalladamente diversos conceptos relacionados con la configuración de la replicación utilizando SymmetricDS.

Fuente: habr.com