Hablaré brevemente 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. Las bases de datos con replicaciones cruzadas se denominan comúnmente bases de datos homogéneas y este es un método conveniente para migrar de un servidor RDBMS a otro.
Las bases de datos PostgreSQL y MySQL se consideran tradicionalmente relacionales, pero con extensiones adicionales ofrecen capacidades NoSQL. Aquí discutiremos la replicación entre PostgreSQL y MySQL desde una perspectiva de administración de bases de datos relacionales.
No describiremos todos los aspectos internos, solo los principios básicos, para que tenga una idea de cómo configurar la replicación entre servidores de bases de datos, sus ventajas, limitaciones y casos de uso.
Normalmente, la replicación entre dos servidores de bases de datos idénticos se realiza en modo binario o mediante consultas entre un maestro (también conocido como editor, maestro o activo) y un esclavo (suscriptor, en espera o pasivo). El propósito de la replicación es proporcionar una copia en tiempo real de la base de datos maestra en el lado de espera. En este caso, los datos se transfieren del maestro al esclavo, es decir, del activo al pasivo, porque la replicación se realiza solo en una dirección. Pero puede configurar la replicación entre las dos bases de datos en ambas direcciones, de modo que los datos se transfieran del esclavo al maestro en una configuración 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, de la disponibilidad de dichas capacidades en la configuración inicial o del uso de soluciones de ajuste externas y del comercio existente. -offs.
La configuración descrita es posible entre diferentes servidores de bases de datos. El servidor se puede configurar para recibir datos replicados de otro servidor de base de datos y aún conservar instantáneas en tiempo real de los datos replicados. MySQL y PostgreSQL ofrecen la mayoría de estas configuraciones de forma nativa o mediante extensiones de terceros, incluidos métodos de registro binario, bloqueos de disco y métodos basados en declaraciones y filas.
Se necesita replicación cruzada entre MySQL y PostgreSQL para una migración única de un servidor de base de datos a otro. Estas bases de datos utilizan protocolos diferentes, por lo que no puede vincularlas directamente. Para facilitar el intercambio de datos, 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 filas se recuperan de tablas MySQL y se almacenan como objetos JSONB en la base de datos PostgreSQL, y luego se decodifican mediante la función pl/pgsql y se reproducen en la base de datos PostgreSQL.
Características de pg_chameleon
Se pueden replicar múltiples esquemas MySQL del mismo clúster en una única base de datos de destino PostgreSQL con una configuración de uno a muchos.
Los nombres de los esquemas de origen y de destino no pueden ser los mismos.
Los datos de replicación se pueden recuperar desde una réplica en cascada de MySQL.
Se excluyen las tablas que no pueden replicarse o generar errores.
Cada función de replicación está controlada por demonios.
Control con parámetros y archivos de configuración basados en YAML.
ejemplo
Anfitrión
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 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. Este ejemplo tiene instalado 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 altinstallUna vez que Python3.6 se haya instalado correctamente, se deben completar el resto de los requisitos, como la creación y activación de un entorno virtual. Además, el módulo pip se actualiza a la última versión y se utiliza para instalar pg_chameleon. Los siguientes comandos instalan intencionalmente pg_chameleon 2.0.9, aunque la última versión es 2.0.10. Esto es necesario 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.9Luego llamamos a pg_chameleon (chameleon es un comando) con el argumento set_configuration_files para habilitar pg_chameleon y crear los 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.ymlAhora hacemos una copia de config-example.yml como default.yml para que se convierta en el archivo de configuración predeterminado. A continuación se proporciona un archivo de configuración de muestra para este ejemplo.
$> 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 en este ejemplo es un archivo pg_chameleon de muestra con modificaciones menores para que coincida con los entornos de origen y de destino, y a continuación se muestra una descripción general de las distintas secciones del archivo de configuración.
El archivo de configuración default.yml tiene una sección de configuración global (configuración global) donde puede controlar configuraciones como la ubicación del archivo de bloqueo, la ubicación de los registros, el período de almacenamiento de los registros, etc. Luego viene la anulación de tipo. sección, donde se establecen las reglas para anular tipos durante la replicación. El ejemplo predeterminado utiliza una regla de anulación de tipo que convierte tinyint(1) en booleano. En la siguiente sección, especificamos los detalles de 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 origen, es decir, los parámetros de conexión de la base de datos de origen, el esquema de mapeo de las bases de datos de origen y de destino, las tablas que se omitirán, el tiempo de espera, la memoria y el tamaño del paquete. Tenga en cuenta que "fuentes" es plural, lo que significa que podemos agregar varias bases de datos de origen al mismo destino para configurar una configuración de muchos a uno.
La base de datos world_x del ejemplo contiene 4 tablas con filas que la comunidad MySQL sugiere para el ejemplo. Se puede descargar . La base de datos de muestra viene como un archivo comprimido y tar con instrucciones para crear e importar cadenas.
Se crea un usuario especial con el mismo nombre usr_replica en las bases de datos MySQL y PostgreSQL. MySQL le otorga acceso de lectura adicional a 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;Del lado de PostgreSQL, se crea una 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 del catálogo de replicación, respectivamente. El argumento create_replica_schema es responsable de la configuración automática, como verá a continuación.
postgres=# CREATE USER usr_replica WITH PASSWORD 'pass123';
CREATE ROLE
postgres=# CREATE DATABASE db_replica WITH OWNER usr_replica;
CREATE DATABASELa base de datos MySQL está configurada con algunos cambios para que esté lista para la replicación, como se muestra a continuación. Deberá 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 = 1Ahora es importante verificar la conexión a ambos servidores de base de datos para que no haya problemas al ejecutar los comandos pg_chameleon.
En el nodo PostgreSQL:
$> mysql -u usr_replica -Ap'admin123' -h 192.168.56.102 -D world_xEn el nodo MySQL:
$> psql -p 5433 -U usr_replica -h 192.168.56.106 db_replicaLos siguientes tres comandos pg_chameleon (camaleón) preparan el entorno, agregan el origen e inicializan la réplica. El argumento create_replica_schema de pg_chameleon crea un esquema predeterminado (sch_chameleon) y un esquema de replicación (pgworld_x) en la base de datos PostgreSQL, como dijimos. El argumento add_source agrega una base de datos de origen a la configuración leyendo el archivo de configuración (default.yml), que en nuestro caso es mysql, e init_replica inicializa la configuración según 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 --debugEl resultado de estos tres comandos indica claramente su éxito. Todas las fallas o errores de sintaxis se indican en mensajes simples y comprensibles con sugerencias sobre cómo solucionar problemas.
Finalmente, iniciamos la replicación con start_replica y recibimos un mensaje de éxito.
$> chameleon start_replica --config default --source mysql
output: Starting the replica process for source mysqlEl estado de la replicación se puede consultar con el argumento show_status y los errores se pueden ver con el argumento show_errors.
Como ya hemos dicho, los demonios gestionan todas las funciones de replicación. Para verlos, consulte la tabla de procesos con el comando ps de Linux, como se muestra a continuación.
La replicación no se considera configurada hasta que la probamos 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 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));
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.Para validar los resultados de la prueba, consultamos la tabla desde la base de datos PostgreSQL y generamos las filas.
$> psql -p 5433 -U usr_replica -d db_replica -c "select * from pgworld_x.t1";
n1 | n2
----+-------
1 | one
2 | twoSi estamos migrando, los siguientes comandos pg_chameleon serán el final de la migración. Los comandos deben ejecutarse después de haber verificado que las filas de todas las tablas de destino se han replicado, lo que da como resultado una base de datos PostgreSQL perfectamente migrada sin referencias a la base de datos de origen ni al esquema de replicación (sch_chameleon).
$> chameleon stop_replica --config default --source mysql
$> chameleon detach_replica --config default --source mysql --debugOpcionalmente, puede eliminar la configuración original y el esquema de replicación con los siguientes comandos.
$> chameleon drop_source --config default --source mysql --debug
$> chameleon drop_replica_schema --config default --source mysql --debugBeneficios de pg_chameleon
Fácil instalación y configuración.
Cómoda solución de problemas y detección de 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.
Es posible configurar múltiples bases de datos de origen para una base de datos de destino, y esto es muy útil si está fusionando datos de una o más bases de datos MySQL en una base de datos PostgreSQL.
Puede optar por no replicar las tablas seleccionadas.
Desventajas de pg_chameleon
Solo se admite con MySQL 5.5 y superior como base de datos de origen y PostgreSQL 9.5 y superior como base de datos de destino.
Cada tabla debe tener una clave principal o única; de lo contrario, las tablas se inicializan en el proceso init_replica pero no se replican.
Replicación unidireccional: solo de MySQL a PostgreSQL. Por lo tanto, sólo es adecuado para el esquema activo-pasivo.
La fuente solo puede ser una base de datos MySQL, y la compatibilidad con una base de datos PostgreSQL como fuente es solo experimental y limitada (obtenga más información )
Totales para pg_chameleon
El método de replicación en pg_chameleon es excelente para migrar una base de datos de MySQL a PostgreSQL. La gran desventaja es que la replicación es sólo unidireccional, por lo que es poco probable que los profesionales de bases de datos quieran utilizarla para otra cosa que no sea la migración. Pero el problema de la replicación unidireccional se puede resolver con otra herramienta de código abierto: SymmetricDS.
Leer más en la documentación oficial. . Se puede encontrar ayuda en la línea de comando .
Descripción general 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 otras instancias de bases de datos en la nube, por ejemplo Redshift. y Azure, etc. Funciones disponibles: sincronización de bases de datos y archivos, replicación de bases de datos multimaestro, sincronización filtrada, transformación y otras. Esta es una herramienta Java y requiere la versión estándar JRE o JDK (versión 8.0 o superior). Aquí puede registrar cambios de datos en activadores en la base de datos de origen y enviarlos a la base de datos de destino correspondiente como lotes.
Capacidades de SymmetricDS
La herramienta es independiente de la plataforma, lo que significa que dos o más bases de datos diferentes pueden intercambiar datos.
Las bases de datos relacionales se sincronizan registrando cambios de datos y las bases de datos basadas en sistemas de archivos utilizan la sincronización de archivos.
Replicación bidireccional mediante métodos push y pull basados en un conjunto de reglas.
La transmisión de datos es posible a través de redes seguras y redes con poco ancho de banda.
Recuperación automática al reanudar la operación de los nodos después de una falla y resolución automática de conflictos.
API de extensión eficientes y compatibles con la nube.
ejemplo
SymmetricDS se puede configurar de dos maneras:
Un nodo maestro (padre) que coordina centralmente la replicación de datos entre dos nodos esclavos (secundarios), y el intercambio de datos entre nodos secundarios se lleva a cabo únicamente a través del padre.
Un nodo activo (nodo 1) puede comunicarse para replicación con otro nodo activo (nodo 2) sin intermediario.
En ambas opciones, el intercambio de datos se produce mediante Push and Pull. En este ejemplo, consideraremos la configuración activo-activo. Es demasiado largo para describir toda la arquitectura, así que estudie para obtener más información sobre el dispositivo SymmetricDS.
Instalar SymmetricDS es fácil: descargue el archivo zip de código abierto y extráelo donde quieras. La siguiente tabla enumera la ubicación de instalación y la versión de SymmetricDS en este ejemplo, así como las versiones de la base de datos, las versiones de Linux, las direcciones IP y los puertos para ambos nodos.
Anfitrión
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 base de datos
3306
5832
Dirección IP
192.168.1.107
192.168.1.112
Versión simétrica DS
SimétricoDS 3.9
SimétricoDS 3.9
Ruta de instalación de SymmetricDS
/usr/local/servidor-simétrico-3.9.20
/usr/local/servidor-simétrico-3.9.20
Nombre de host de SymmetricDS
corp-000
tienda-001
Aquí instalamos SymmetricDS en /usr/local/metric-server-3.9.20 y allí se almacenarán varios subdirectorios y archivos. Estamos interesados en los subdirectorios samples y motores. El directorio de muestras contiene archivos de configuración de muestra con propiedades de nodo, así como scripts SQL de muestra para iniciar rápidamente la demostración.
En el directorio de muestras, vemos tres archivos de configuración con propiedades de nodo: el nombre muestra la naturaleza del nodo en un esquema particular.
corp-000.properties
store-001.properties
store-002.propertiesSymmetricDS tiene todos los archivos de configuración necesarios para un esquema básico de 3 nodos (opción 1) y los mismos archivos se pueden usar para un esquema de 2 nodos (opción 2). Copie el archivo de configuración requerido del directorio de muestras a los motores en el host vm1. Resulta 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=000Este nodo se llama corp-000 en la configuración de SymmetricDS y la conexión de la base de datos es manejada por el controlador mysql jdbc que utiliza la cadena de conexión anterior y las credenciales de inicio de sesión. Nos estamos conectando a la base de datos replica_db y se crearán tablas durante la creación del esquema. sync.url muestra el enlace al nodo a sincronizar.
El nodo 2 en el host vm2 está configurado como store-001 y el resto se especifica en el archivo node.properties a continuación. El nodo store-001 ejecuta la base de datos PostgreSQL y pgdb_replica es la base de datos a replicar. Registration.url permite que vm2 host se comunique con vm1 host y obtenga detalles de configuración del mismo.
$> 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=001El ejemplo completo de SymmetricDS contiene opciones para configurar la replicación bidireccional entre dos servidores de bases de datos (dos nodos). Los pasos siguientes se realizan en el host vm1 (corp-000), que creará un esquema de muestra con 4 tablas. Luego, ejecutar create-sym-tables con el comando symadmin crea tablas de directorio donde se almacenarán las reglas y la dirección de replicación entre nodos. Finalmente, los datos de muestra se cargan 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.sqlEn el ejemplo, las tablas item y item_selling_price se configuran automáticamente para replicarse desde corp-000 a store-001, y las tablas de venta (sale_transaction y sale_return_line_item) se configuran automáticamente para replicarse desde store-001 a corp-000. Ahora creamos un esquema en la base de datos 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.xmlAsegúrese de verificar que la base de datos MySQL en vm1 tenga tablas de muestra y una tabla de catálogo SymmetricDS. Tenga en cuenta que las tablas del sistema SymmetricDS (con el prefijo sym_) actualmente solo están disponibles en el nodo corp-000, porque ahí es donde ejecutamos el comando create-sym-tables y administraremos la replicación. Y en la base de datos del nodo store-001 solo habrá 4 tablas de ejemplo sin datos.
Todo. El entorno está listo para ejecutar 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 al archivo de registro en segundo plano (simétrico.log) en la carpeta de registro 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 ejecuta el proceso del servidor sym en el host vm2, también creará las tablas del catálogo SymmetricDS en la base de datos PostgreSQL. Si ejecuta el proceso del servidor sym en ambos nodos, se coordinarán entre sí para replicar los datos de corp-000 a store-001. Si después de unos segundos consultamos las 4 tablas de ambos lados, veremos que la replicación fue exitosa. O puede enviar el bootstrap a store-001 desde corp-000 con el siguiente comando.
vm1$> ./symadmin --engine corp-000 reload-node 001En este punto, se inserta un nuevo registro en la tabla de elementos 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 una operación Pull para mover 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 una operación de inserción para mover datos de store-001 a corp-000, insertamos un registro en la tabla sale_transaction y verificamos que se haya completado la replicación.
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 usuarios, realice los siguientes pasos. Creamos la tabla t1, por ejemplo, y configuramos sus reglas de replicación de la siguiente manera. Entonces configuramos solo 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)Luego se notifica a la configuración del cambio de esquema, es decir, la adición de una nueva tabla, mediante el uso del comando symadmin con el argumento sync-triggers, que recrea los activadores para que coincidan con las definiciones de la tabla. Se ejecuta Send-schema para enviar cambios de esquema a store-001 y se replica la tabla t1.
vm1$> ./symadmin -e corp-000 --node=001 sync-triggers
vm1$> ./symadmin send-schema -e corp-000 --node=001 t1Beneficios de SymmetricDS
Fácil instalación y configuración, incluido un conjunto de archivos listos para usar con parámetros para crear un esquema con tres o dos nodos.
Bases de datos multiplataforma e independencia de plataforma, incluidos servidores, computadoras portátiles y dispositivos móviles.
Replica cualquier base de datos a cualquier otra base de datos localmente, en la WAN o en la nube.
Capacidad para trabajar de manera óptima con un par de bases de datos o varios miles para una fácil replicación.
Versión paga con GUI y excelente soporte.
Desventajas de SymmetricDS
Debe definir manualmente las reglas y la dirección de replicación en la línea de comando mediante declaraciones SQL para cargar las tablas del catálogo, lo que puede resultar inconveniente.
Configurar muchas tablas para la replicación puede resultar tedioso a menos que utilice scripts para crear declaraciones SQL que definan las reglas y la dirección de la replicación.
Hay demasiada información en los registros y, a veces, es necesario limpiar el archivo de registro para que no ocupe demasiado espacio.
Resumen de SymmetricDS
SymmetricDS le permite configurar la replicación bidireccional entre dos, tres o incluso varios miles de nodos para replicar y sincronizar archivos. Es una herramienta única que realiza muchas tareas por sí sola, como la recuperación automática de datos después de un largo tiempo de inactividad en un nodo, comunicación segura y eficiente entre nodos a través de HTTPS, gestión automática de conflictos basada en un conjunto de reglas, etc. SymmetricDS replica entre cualquier base de datos, por lo tanto, se puede utilizar para una amplia variedad de escenarios, incluida la migración, actualización, distribución, filtrado y transformación de datos entre plataformas.
El ejemplo está basado en el oficial. por SymmetricDS. EN Describe en detalle los diversos conceptos involucrados en la configuración de la replicación con SymmetricDS.
Fuente: habr.com