sql >> Base de Datos >  >> RDS >> Mysql

Una descripción general de la replicación cruzada de PostgreSQL y MySQL

Este blog tiene como objetivo explicar una descripción general de la replicación cruzada entre PostgreSQL y MySQL, y discutir más a fondo los métodos para configurar la replicación cruzada entre los dos servidores de bases de datos. Tradicionalmente, las bases de datos involucradas en una configuración de replicación cruzada se denominan bases de datos heterogéneas, que es un buen enfoque para pasar de un servidor RDBMS a otro.

Tanto las bases de datos PostgreSQL como MySQL son bases de datos RDBMS convencionales, pero también ofrecen capacidad NoSQL con extensiones adicionales para tener lo mejor de ambos mundos. Este artículo se centra en la discusión de la replicación entre PostgreSQL y MySQL desde una perspectiva RDBMS.

Una explicación exhaustiva sobre los aspectos internos de la replicación no está dentro del alcance de este blog, sin embargo, se discutirán algunos elementos fundamentales para que la audiencia comprenda cómo se configura la replicación entre servidores de bases de datos, ventajas, limitaciones y quizás algunos casos de uso conocidos.

En general, la replicación entre dos servidores de bases de datos idénticos se logra en modo binario o en modo de consulta entre un nodo maestro (también llamado publicador, primario o activo) y un nodo esclavo (suscriptor, en espera o pasivo). El objetivo de la replicación es proporcionar una copia en tiempo real de la base de datos maestra en el lado esclavo, donde los datos se transfieren de maestro a esclavo, formando así una configuración activa-pasiva porque la replicación solo está configurada para ocurrir de una manera. Por otro lado, la replicación entre dos bases de datos se puede configurar en ambos sentidos para que los datos también se puedan transferir de esclavo a maestro, estableciendo una configuración activo-activo. Todo esto se puede configurar entre dos o más servidores de bases de datos idénticos que también pueden incluir una replicación en cascada. La configuración de activo-activo o activo-pasivo realmente depende de la necesidad empresarial, la disponibilidad de dichas funciones dentro de la configuración nativa o el uso de soluciones externas para configurar y las compensaciones aplicables.

La configuración mencionada anteriormente se puede lograr con diversos servidores de bases de datos, en los que un servidor de bases de datos se puede configurar para aceptar datos replicados de otro servidor de bases de datos completamente diferente y aún así mantener una instantánea en tiempo real de los datos que se replican. Los servidores de bases de datos MySQL y PostgreSQL ofrecen la mayoría de las configuraciones discutidas anteriormente, ya sea en su propio origen o con la ayuda de extensiones de terceros, incluido el método de registro binario, método de bloqueo de disco, métodos basados ​​en declaraciones y basados ​​en filas.

El requisito de configurar una replicación cruzada entre MySQL y PostgreSQL realmente surge como resultado de un esfuerzo de migración único para pasar de un servidor de base de datos a otro. Como ambas bases de datos usan protocolos diferentes, no pueden comunicarse directamente entre sí. Para lograr ese flujo de comunicación, existe una herramienta externa de código abierto como pg_chameleon.

Fondo de pg_chameleon

pg_chameleon es un sistema de replicación de MySQL a PostgreSQL desarrollado en Python 3. Utiliza una biblioteca de código abierto llamada mysql-replication que también se desarrolla con Python. La funcionalidad consiste en extraer imágenes de fila de tablas MySQL y almacenarlas como objetos JSONB en una base de datos PostgreSQL, que se descodifica aún más mediante una función pl/pgsql y reproduce esos cambios en la base de datos PostgreSQL.

Características de pg_chameleon

  • Se pueden replicar varios esquemas de MySQL del mismo clúster en una única base de datos PostgreSQL de destino, formando una configuración de replicación de muchos a uno
  • Los nombres del esquema de origen y de destino pueden no ser idénticos
  • Los datos de replicación se pueden extraer de la réplica en cascada de MySQL
  • Se excluyen las tablas que no se replican o generan errores
  • Cada funcionalidad de replicación se administra con la ayuda de demonios
  • Controlado con la ayuda de parámetros y archivos de configuración basados ​​en la construcción YAML

Demostración

Host vm1 vm2
Versión del sistema operativo Versión CentOS Linux 7.6 x86_64 Versión CentOS Linux 7.5 x86_64
Servidor de base de datos con versión MySQL 5.7.26 PostgreSQL 10.5
Puerto de base de datos 3306 5433
dirección IP 192.168.56.102 192.168.56.106

Para empezar, prepare la configuración con todos los requisitos previos necesarios para instalar pg_chameleon. En esta demo se instala Python 3.6.8, creando un entorno virtual y activándolo para su uso.

$> 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 una instalación exitosa de Python3.6, se cumplen otros requisitos adicionales, como la creación y activación de un entorno virtual. Además de ese módulo pip actualizado a la última versión y se usa para instalar pg_chameleon. En los comandos a continuación, pg_chameleon 2.0.9 se instaló deliberadamente, mientras que la última versión es 2.0.10. Esto se hace para evitar nuevos errores introducidos 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

El siguiente paso es invocar pg_chameleon (chameleon es el comando) con el argumento set_configuration_files para permitir que pg_chameleon cree directorios y archivos de configuración predeterminados.

(venv) $> chameleon set_configuration_files
creating directory /root/.pg_chameleon
creating directory /root/.pg_chameleon/configuration/
creating directory /root/.pg_chameleon/logs/
creating directory /root/.pg_chameleon/pid/
copying configuration  example in /root/.pg_chameleon/configuration//config-example.yml

Ahora, cree una copia de config-example.yml como default.yml para convertirlo en el archivo de configuración predeterminado. A continuación se proporciona un archivo de configuración de muestra utilizado para esta demostración.

$> cat default.yml
---
#global settings
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 allows the user to override the default type conversion into a different one.
type_override:
  "tinyint(1)":
    override_to: boolean
    override_tables:
      - "*"

#postgres  destination connection
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 #skips inserts on the table delphis_mediterranea.foo
      delete:
        - delphis_mediterranea #skips deletes on schema delphis_mediterranea
      update:

El archivo de configuración utilizado en esta demostración es el archivo de muestra que viene con pg_chameleon con ediciones menores para adaptarse a los entornos de origen y destino, y a continuación se incluye un resumen de las diferentes secciones del archivo de configuración.

El archivo de configuración predeterminado.yml tiene una sección de "configuración global" que controla detalles como la ubicación del archivo de bloqueo, las ubicaciones de registro y el período de retención, etc. La sección que sigue a continuación es la sección de "anulación de tipo", que es un conjunto de reglas para anular tipos durante la replicación. Se utiliza una regla de anulación de tipo de muestra de forma predeterminada que convierte un valor tinyint(1) en un valor booleano. La siguiente sección es la sección de detalles de conexión de la base de datos de destino que, en nuestro caso, es una base de datos PostgreSQL, indicada por "pg_conn". La sección final es la sección de origen que tiene todos los detalles de la configuración de la conexión de la base de datos de origen, la asignación de esquemas entre el origen y el destino, las tablas que se deben omitir, incluido el tiempo de espera, la memoria y la configuración del tamaño del lote. Observe las "fuentes" que indican que puede haber varias fuentes en un solo destino para formar una configuración de replicación de muchos a uno.

En esta demostración se usa una base de datos "world_x", que es una base de datos de muestra con 4 tablas que contienen filas de muestra, que la comunidad MySQL ofrece para fines de demostración, y se puede descargar desde aquí. La base de datos de muestra viene como un archivo tar y comprimido junto con instrucciones para crearla e importar filas en ella.

Se crea un usuario dedicado en las bases de datos MySQL y PostgreSQL con el mismo nombre que usr_replica al que se le otorgan privilegios adicionales en MySQL para tener acceso de lectura a todas las tablas que se replican.

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;

Se crea una base de datos en el lado de PostgreSQL que aceptará cambios de la base de datos MySQL, que se denomina "db_replica". El usuario "usr_replica" en PostgreSQL se configura automáticamente como propietario de dos esquemas como "pgworld_x" y "sch_chameleon" que contienen las tablas replicadas reales y las tablas de catálogo de replicación, respectivamente. Esta configuración automática se realiza mediante el argumento create_replica_schema, indicado más abajo.

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 está configurada con algunos cambios de parámetros para prepararla para la replicación, como se muestra a continuación, y requiere reiniciar el servidor de la base 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

En este punto, es importante probar la conectividad con ambos servidores de bases de datos para asegurarse de que no haya problemas cuando se ejecutan los 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 MySQL:

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

Los siguientes tres comandos de pg_chameleon (chameleon) es donde configura el entorno, agrega una fuente e inicializa una réplica. El argumento "create_replica_schema" de pg_chameleon crea el esquema predeterminado (sch_chameleon) y el esquema de replicación (pgworld_x) en la base de datos de PostgreSQL, como ya se ha comentado. El argumento "add_source" agrega la base de datos de origen a la configuración mediante la lectura del archivo de configuración (default.yml), que en este caso es "mysql", mientras que "init_replica" inicializa la configuración en función de la configuración 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

La salida de los tres comandos anteriores se explica por sí misma e indica el éxito de cada comando con un mensaje de salida evidente. Cualquier falla o error de sintaxis se menciona claramente en mensajes simples y claros, lo que sugiere y solicita acciones correctivas.

El paso final es iniciar la replicación con "start_replica", cuyo éxito se indica mediante una sugerencia de salida como se muestra a continuación.

$> chameleon start_replica --config default --source mysql 
output: Starting the replica process for source mysql

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

$> chameleon show_status --source mysql  
OUTPUT: 
  Source id  Source name    Type    Status    Consistent    Read lag    Last read    Replay lag    Last replay
-----------  -------------  ------  --------  ------------  ----------  -----------  ------------  -------------
          1  mysql          mysql   running   No            N/A                      N/A

== Schema mappings ==
Origin schema    Destination schema
---------------  --------------------
world_x          pgworld_x

== Replica status ==
---------------------  ---
Tables not replicated  0
Tables replicated      4
All tables             4
Last maintenance       N/A
Next maintenance       N/A
Replayed rows
Replayed DDL
Skipped rows
---------------------  ---
$> chameleon show_errors --config default 
output: There are no errors in the log

Como se discutió anteriormente, cada una de las funciones de replicación se administra con la ayuda de demonios, que se pueden ver consultando la tabla de procesos con el comando "ps" de Linux, que se muestra a continuación.

$>  ps -ef|grep chameleon
root       763     1  0 19:20 ?        00:00:00 /u01/media/mysql_samp_dbs/world_x-db/venv/bin/python3.6 /u01/media/mysq l_samp_dbs/world_x-db/venv/bin/chameleon start_replica --config default --source mysql
root       764   763  0 19:20 ?        00:00:01 /u01/media/mysql_samp_dbs/world_x-db/venv/bin/python3.6 /u01/media/mysq l_samp_dbs/world_x-db/venv/bin/chameleon start_replica --config default --source mysql
root       765   763  0 19:20 ?        00:00:00 /u01/media/mysql_samp_dbs/world_x-db/venv/bin/python3.6 /u01/media/mysq l_samp_dbs/world_x-db/venv/bin/chameleon start_replica --config default --source mysql

Ninguna configuración de replicación está completa hasta que se somete a la prueba de "aplicación en tiempo real", que se ha simulado como se muestra a continuación. Implica crear una tabla e insertar un par de registros en la base de datos MySQL, posteriormente, se invoca el argumento "sync_tables" de pg_chameleon para actualizar los demonios para replicar la tabla junto con sus registros en la base de datos PostgreSQL.

mysql> create table t1 (n1 int primary key, n2 varchar(10));
Query OK, 0 rows affected (0.01 sec)
mysql> insert into t1 values (1,'one');
Query OK, 1 row affected (0.00 sec)
mysql> insert into t1 values (2,'two');
Query OK, 1 row affected (0.00 sec)
$> chameleon sync_tables --tables world_x.t1 --config default --source mysql
Sync tables process for source mysql started.

La prueba se confirma consultando la tabla de la base de datos PostgreSQL para reflejar las filas.

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

Si se trata de un proyecto de migración, los siguientes comandos pg_chameleon marcarán el final del esfuerzo de migración. Los comandos deben ejecutarse después de confirmar que las filas de todas las tablas de destino se han replicado y el resultado será una base de datos PostgreSQL migrada limpiamente sin ninguna referencia a la base de datos de origen 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 eliminarán la configuración de origen 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 usar pg_chameleon

  • Fácil de instalar y configuración menos complicada
  • Resolución de problemas y detección de anomalías sin problemas con resultados de error fáciles de entender
  • Se pueden agregar tablas ad hoc adicionales a la replicación después de la inicialización, sin alterar ninguna otra configuración
  • Se pueden configurar varias fuentes para una única base de datos de destino, lo que resulta útil en proyectos de consolidación para fusionar datos de una o más bases de datos MySQL en una única base de datos PostgreSQL
  • Las tablas seleccionadas se pueden omitir para que no se repliquen

Desventajas de usar pg_chameleon

  • Solo compatible desde MySQL 5.5 en adelante como base de datos de origen y PostgreSQL 9.5 en adelante como base de datos de destino
  • Requiere que cada tabla tenga una clave primaria o única, de lo contrario, las tablas se inicializan durante el proceso init_replica pero no se replicarán
  • Replicación unidireccional, es decir, MySQL a PostgreSQL. Limitando así su uso a solo una configuración activa-pasiva
  • La base de datos fuente solo puede ser una base de datos MySQL, mientras que la compatibilidad con la base de datos PostgreSQL como fuente es experimental con más limitaciones (haga clic aquí para obtener más información)

Resumen de pg_chameleon

El enfoque de replicación que ofrece pg_chameleon es favorable para una migración de base de datos de MySQL a PostgreSQL. Sin embargo, una de las limitaciones significativas de la replicación unidireccional puede desanimar a los profesionales de bases de datos a adoptarla para cualquier otra cosa que no sea la migración. Este inconveniente de la replicación unidireccional se puede solucionar con otra herramienta de código abierto llamada SymmetricDS.

Para estudiar la utilidad con más detalle, consulte la documentación oficial aquí. La referencia de la línea de comando se puede obtener desde aquí.

Descargue el documento técnico hoy Administración y automatización de PostgreSQL con ClusterControlObtenga información sobre lo que necesita saber para implementar, monitorear, administrar y escalar PostgreSQLDescargar el documento técnico

Una descripción general de SymmetricDS

SymmetricDS es una herramienta de código abierto que es capaz de replicar cualquier base de datos a cualquier otra base de datos, de la popular lista de servidores de bases de datos como Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird y otras instancias de bases de datos basadas en la nube, como Redshift y Azure, etc. Algunas de las ofertas incluyen sincronización de bases de datos y archivos, replicación multimaestro, sincronización filtrada y transformación. La herramienta se desarrolla utilizando Java, lo que requiere una edición estándar (versión 8.0 o superior) de JRE o JDK. La funcionalidad implica que los desencadenantes capturen los cambios de datos en la base de datos de origen y los dirijan a una base de datos de destino participante como lotes salientes

Características de SymmetricDS

  • Independiente de la plataforma, lo que significa que dos o más bases de datos diferentes pueden comunicarse entre sí, cualquier base de datos con cualquier otra base de datos
  • Las bases de datos relacionales logran la sincronización mediante la captura de datos modificados, mientras que los sistemas basados ​​en sistemas de archivos utilizan la sincronización de archivos
  • Replicación bidireccional usando el método Push and Pull, que se logra en base a reglas establecidas
  • La transferencia de datos también puede ocurrir a través de redes seguras y de bajo ancho de banda
  • Recuperación automática durante la reanudación de un nodo bloqueado y resolución automática de conflictos
  • Listo para la nube y contiene potentes API de extensión

Demostración

SymmetricDS se puede configurar en una de las dos opciones:

  • Un nodo principal (principal) que actúa como un intermediario centralizado que coordina la replicación de datos entre dos nodos secundarios (secundarios), en el que la comunicación entre los dos nodos secundarios solo puede ocurrir a través del principal.
  • Un nodo activo (nodo1) puede replicarse hacia y desde otro nodo activo (nodo2) sin ningún intermediario.

En ambas opciones, la comunicación entre los nodos ocurre a través de eventos "Push" y "Pull". En esta demostración, se explicará una configuración activo-activo entre dos nodos. La arquitectura completa puede ser exhaustiva, por lo que se recomienda a los lectores que consulten la guía del usuario disponible aquí para obtener más información sobre las funciones internas de SymmetricDS.

Instalar SymmetricDS es tan simple como descargar la versión de código abierto del archivo zip desde aquí y extraerlo en una ubicación conveniente. Los detalles de la ubicación de instalación y la versión de SymmetricDS en esta demostración se encuentran en la tabla a continuación, junto con otros detalles relacionados con las versiones de la base de datos, las versiones de Linux, las direcciones IP y el puerto de comunicación para ambos nodos participantes.

Host vm1 vm2
Versión del sistema operativo Versión CentOS Linux 7.6 x86_64 Versión CentOS Linux 7.6 x86_64
Versión del servidor de la base de datos MySQL 5.7.26 PostgreSQL 10.5
Puerto de base de datos 3306 5832
dirección IP 192.168.1.107 192.168.1.112
Versión de SymmetricDS Simétrico DS 3.9 Simétrico DS 3.9
Ubicación de instalación de SymmetricDS /usr/local/simétrico-servidor-3.9.20 /usr/local/simétrico-servidor-3.9.20
Nombre de nodo de SymmetricDS corp-000 tienda-001

El inicio de instalación en este caso es "/usr/local/symmetric-server-3.9.20", que será el directorio de inicio de SymmetricDS, que contiene varios otros subdirectorios y archivos. Dos de los subdirectorios que son importantes ahora son "muestras" y "motores". El directorio de ejemplos contiene ejemplos de archivos de configuración de propiedades de nodo además de scripts SQL de ejemplo para iniciar una demostración rápida.

Los siguientes tres archivos de configuración de propiedades de nodo se pueden ver en el directorio "muestras" con nombres que indican la naturaleza del nodo en una configuración determinada.

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

Como SymmetricDS viene con todos los archivos de configuración necesarios para admitir una configuración básica de 3 nodos (opción 1), también es conveniente usar los mismos archivos de configuración para configurar una configuración de 2 nodos (opción 2). El archivo de configuración previsto se copia del directorio "muestras" a los "motores" en el host vm1, y se ve como se muestra a continuación.

$> 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

El nombre de este nodo en la configuración de SymmetricDS es "corp-000" con la conexión de la base de datos manejada con el controlador mysql jdbc usando la cadena de conexión como se indicó anteriormente junto con las credenciales de inicio de sesión. La base de datos para conectarse es "replica_db" y las tablas se crearán durante la creación del esquema de muestra. El "sync.url" indica la ubicación para contactar al nodo para la sincronización.

El nodo 2 en el host vm2 está configurado como "store-001" con el resto de los detalles configurados en el archivo node.properties, que se muestra a continuación. El nodo "store-001" ejecuta una base de datos PostgreSQL, con "pgdb_replica" como base de datos para la replicación. El "registration.url" permite que el host "vm2" se comunique con el host "vm1" para obtener detalles de 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

La demostración predeterminada preconfigurada de SymmetricDS contiene configuraciones para configurar una replicación bidireccional entre dos servidores de bases de datos (dos nodos). Los pasos a continuación se ejecutan en el host vm1 (corp-000), que creará un esquema de muestra con 4 tablas. Además, la ejecución de "create-sym-tables" con el comando "symadmin" creará las tablas de catálogo que almacenan y controlan las reglas y la dirección de replicación entre nodos. Finalmente, las tablas de demostración se cargan con datos de muestra.

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

Las tablas de demostración "item" y "item_selling_price" se configuran automáticamente para replicar desde corp-000 a store-001, mientras que las tablas de venta (sale_transaction y sale_return_line_item) se configuran automáticamente para replicar desde store-001 a corp-000. El siguiente paso es crear el esquema de muestra en la base de datos de PostgreSQL en el host vm2 (store-001), para prepararlo 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

Es importante verificar la existencia de tablas de demostración y tablas de catálogo de SymmetricDS en la base de datos MySQL en vm1 en esta etapa. Tenga en cuenta que las tablas del sistema SymmetricDS (tablas con el prefijo "sym_") solo están disponibles en el nodo corp-000 en este momento, porque ahí es donde se ejecutó el comando "create-sym-tables", que será el lugar para controlar y gestionar la replicación. Además de eso, la base de datos del nodo store-001 solo tendrá 4 tablas de demostración sin datos.

El entorno ahora está listo para iniciar 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 &

Las entradas de registro se envían a un archivo de registro en segundo plano (simétrico.log) en un directorio de registros en la ubicación de instalación de 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 &

El inicio del proceso del servidor "sym" en el host vm2 también creará las tablas de catálogo de SymmetricDS en la base de datos de PostgreSQL. El inicio del proceso del servidor "sym" en ambos nodos hará que se coordinen entre sí para replicar datos de corp-000 a store-001. Después de unos segundos, consultar las cuatro tablas de cada lado mostrará los resultados de la replicación exitosa. Alternativamente, también se puede enviar una 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 "elemento" en la base de datos MySQL en el nodo corp-000 (host:vm1) y se puede verificar que se haya replicado correctamente en la base de datos PostgreSQL en el nodo store-001 (host:vm2 ). Esto muestra el evento "Pull" de 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)

El evento "Push" de datos de store-001 a corp-000 se puede lograr insertando un registro en la tabla "sale_transaction" y confirmándolo para que se replique.

pgdb_replica=# insert into "sale_transaction" ("tran_id", "store_id", "workstation", "day", "seq") values (1000, '001', '3', '2007-11-01', 100);
vm1$> [[email protected] ~]#  mysql -uroot -p'admin123' -D replica_db -e "select * from sale_transaction";
+---------+----------+-------------+------------+-----+
| tran_id | store_id | workstation | day        | seq |
+---------+----------+-------------+------------+-----+
|     900 | 001      | 3           | 2012-12-01 |  90 |
|    1000 | 001      | 3           | 2007-11-01 | 100 |
|    2000 | 002      | 2           | 2007-11-01 | 200 |
+---------+----------+-------------+------------+-----+

Esto marca la configuración exitosa de la replicación bidireccional de tablas de demostración entre una base de datos MySQL y PostgreSQL. Considerando que, la configuración de la replicación para las tablas de usuario recién creadas se puede lograr mediante los siguientes pasos. Se crea una tabla de ejemplo "t1" para la demostración y las reglas de su replicación se configuran según el procedimiento a continuación. Los pasos solo configuran la replicación 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)

Después de esto, se notifica a la configuración sobre el cambio de esquema de agregar una nueva tabla invocando el comando symadmin con el argumento "sync-triggers" que recreará los disparadores para que coincidan con las definiciones de la tabla. Posteriormente, ejecute "send-schema" para enviar los cambios de esquema al nodo store-001, luego de lo cual la replicación de la tabla "t1" se configurará correctamente.

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

Ventajas de usar SymmetricDS

  • Instalación y configuración sin esfuerzo, incluido un conjunto preconfigurado de archivos de parámetros para crear una configuración de 3 o 2 nodos
  • Base de datos multiplataforma habilitada e independiente de la plataforma, incluidos servidores, portátiles y dispositivos móviles
  • Reproduzca cualquier base de datos a cualquier otra base de datos, ya sea local, WAN o en la nube
  • Capaz de manejar de manera óptima desde un par de bases de datos hasta varios miles de bases de datos para replicar datos sin problemas
  • Una versión comercial del software ofrece una consola de administración impulsada por GUI con un excelente paquete de soporte

Desventajas de usar SymmetricDS

  • La configuración manual de la línea de comandos puede implicar la definición de reglas y la dirección de la replicación a través de declaraciones SQL para cargar tablas de catálogo, lo que puede ser un inconveniente de administrar
  • Configurar una gran cantidad de tablas para la replicación será un esfuerzo exhaustivo, a menos que se utilice alguna forma de secuencias de comandos para generar las instrucciones SQL que definen las reglas y la dirección de la replicación
  • Mucha información de registro que satura el archivo de registro, lo que requiere un mantenimiento periódico del archivo de registro para evitar que el archivo de registro llene el disco

Resumen de SymmetricDS

Recursos relacionados ClusterControl for MySQL Replication ClusterControl for PostgreSQL Comparación de almacenes de datos para PostgreSQL - MVCC vs InnoDB

SymmetricDS ofrece la capacidad de configurar la replicación bidireccional entre 2 nodos, 3 nodos, etc. para varios miles de nodos para replicar datos y lograr la sincronización de archivos. Es una herramienta única que realiza muchas de las tareas de mantenimiento de recuperación automática, como la recuperación automática de datos después de períodos prolongados de inactividad en un nodo, comunicación segura y eficiente entre nodos con la ayuda de HTTPS y gestión automática de conflictos basada en reglas establecidas. , etc. The essential feature of replicating any database to any other database makes SymmetricDS ready to be deployed for a number of use cases including migration, version and patch upgrade, distribution, filtering and transformation of data across diverse platforms.

The demo was created by referring to the official quick-start tutorial of SymmetricDS which can be accessed from here. The user guide can be found here, which provides a detailed account of various concepts involved in a SymmetricDS replication setup.