Replicación cruzada entre PostgreSQL e MySQL

Describirei a replicación cruzada entre PostgreSQL e MySQL, así como os métodos para configurar a replicación cruzada entre os dous servidores de bases de datos. Normalmente, as bases de datos replicadas cruzadas chámanse homoxéneas e é un método conveniente para pasar dun servidor RDBMS a outro.

As bases de datos PostgreSQL e MySQL considéranse xeralmente relacionais, pero con extensións adicionais ofrecen capacidades NoSQL. Aquí discutiremos a replicación entre PostgreSQL e MySQL desde unha perspectiva de DBMS relacional.

Non imos describir todo o funcionamento interno, só os principios básicos para que se faga unha idea de configurar a replicación entre servidores de bases de datos, vantaxes, limitacións e casos de uso.

Normalmente, a replicación entre dous servidores de bases de datos idénticos realízase en modo binario ou mediante consultas entre un mestre (tamén coñecido como editor, mestre ou activo) e un escravo (abonado, en espera ou pasivo). O propósito da replicación é proporcionar unha copia en tempo real da base de datos mestra no lado escravo. Neste caso, os datos transfírense de mestre a escravo, é dicir, de activo a pasivo, porque a replicación realízase só nunha dirección. Pero pode configurar a replicación entre dúas bases de datos en ambas direccións, para que os datos se transfiran do escravo ao mestre nunha configuración activo-activo. Todo isto, incluída a replicación en cascada, é posible entre dous ou máis servidores de bases de datos idénticos. A configuración activo-activo ou activo-pasivo depende da necesidade, a dispoñibilidade de tales capacidades na configuración inicial ou o uso de solucións de configuración externas e os compromisos existentes.

A configuración descrita é posible entre distintos servidores de bases de datos. O servidor pódese configurar para aceptar datos replicados doutro servidor de bases de datos e aínda manter instantáneas en tempo real dos datos replicados. MySQL e PostgreSQL ofrecen a maioría destas configuracións internamente ou a través de extensións de terceiros, incluíndo métodos de rexistro binario, bloqueo de disco e métodos baseados en instrucións e filas.

A replicación cruzada entre MySQL e PostgreSQL é necesaria para unha migración única dun servidor de bases de datos a outro. Estas bases de datos utilizan protocolos diferentes, polo que non é posible vinculalas directamente. Para establecer o intercambio de datos, pode usar unha ferramenta externa de código aberto, por exemplo pg_chameleon.

Que é pg_chameleon

pg_chameleon é un sistema de replicación de MySQL a PostgreSQL en Python 3. Usa a biblioteca mysql-replication de código aberto, tamén en Python. As imaxes de fila extráense das táboas MySQL e gárdanse como obxectos JSONB na base de datos PostgreSQL, e despois descifran a función pl/pgsql e reprodúcense na base de datos PostgreSQL.

Características de pg_chameleon

Múltiples esquemas de MySQL do mesmo clúster pódense replicar nunha única base de datos PostgreSQL de destino nunha configuración de un a varios.
Os nomes dos esquemas de orixe e destino non poden ser iguais.
Os datos de replicación pódense recuperar dunha réplica de MySQL en cascada.
Exclúense as táboas que non poden reproducir nin producir erros.
Cada función de replicación está controlada por daemons.
Control mediante parámetros baseados en YAML e ficheiros de configuración.

Exemplo

Anfitrión
vm1
vm2

versión do SO
CentOS Linux 7.6 x86_64
CentOS Linux 7.5 x86_64

Versión do servidor DB
MySQL 5.7.26
PostgreSQL 10.5

Porto DB
3306
5433

Enderezo IP
192.168.56.102
192.168.56.106

Para comezar, prepare todos os compoñentes necesarios para instalar pg_chameleon. Este exemplo instala Python 3.6.8, que crea e activa o ambiente virtual.

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

Despois de instalar correctamente Python3.6, cómpre completar os requisitos restantes, como crear e activar un ambiente virtual. Ademais, o módulo pip actualízase á última versión e úsase para instalar pg_chameleon. Os seguintes comandos instalan intencionadamente pg_chameleon 2.0.9, aínda que a última versión é a 2.0.10. Isto é necesario para evitar novos erros na 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

Despois chamamos pg_chameleon (chameleon é un comando) co argumento set_configuration_files para activar pg_chameleon e crear directorios e ficheiros 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

Agora creamos unha copia de config-example.yml como default.yml para que se converta no ficheiro de configuración predeterminado. A continuación ofrécese un ficheiro de configuración de exemplo para este exemplo.

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

O ficheiro de configuración deste exemplo é un ficheiro pg_chameleon de mostra con pequenas modificacións para adaptarse aos ambientes de orixe e destino, e a continuación móstrase unha visión xeral das diferentes seccións do ficheiro de configuración.

No ficheiro de configuración predeterminado.yml hai unha sección de configuración global, onde podes xestionar axustes como a localización do ficheiro de bloqueo, a localización dos rexistros, o período de almacenamento dos rexistros, etc. A continuación vén a sección de anulación do tipo, onde un conxunto de regras para anular tipos durante a replicación. O exemplo ten por defecto unha regra de substitución de tipo que converte tinyint(1) nun valor booleano. Na seguinte sección, especificamos os detalles da conexión coa base de datos de destino. No noso caso, esta é unha base de datos PostgreSQL, designada pg_conn. No último apartado, indicamos os datos de orixe, é dicir, os parámetros de conexión da base de datos de orixe, o esquema de mapeo entre as bases de datos orixe e destino, táboas que se deben omitir, tempo de espera, memoria, tamaño do paquete. Teña en conta que "fontes" é plural, o que significa que podemos engadir varias bases de datos de orixe a unha única base de datos de destino para configurar unha configuración de varios a un.

A base de datos de exemplo world_x contén 4 táboas con filas que a comunidade MySQL ofrece como exemplos. Pódese descargar aquí. A base de datos de mostra vén como un arquivo alquitrán e comprimido con instrucións para crear e importar filas.

Nas bases de datos MySQL e PostgreSQL, créase un usuario especial co mesmo nome usr_replica. En MySQL, dáselle dereitos de lectura adicionais a todas as táboas 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;

No lado de PostgreSQL, créase unha base de datos db_replica que aceptará cambios da base de datos MySQL. O usuario usr_replica en PostgreSQL configúrase automaticamente como propietario de dous esquemas, pgworld_x e sch_chameleon, que conteñen as táboas replicadas reais e as táboas de directorios de replicación, respectivamente. O argumento create_replica_schema é responsable da configuración automática, 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

A base de datos MySQL está configurada con algúns cambios de parámetros para preparala para a replicación como se mostra a continuación. Deberá reiniciar o servidor de base de datos para que os cambios teñan efecto.

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

Agora é importante comprobar a conexión a ambos os servidores de bases de datos para que non haxa problemas ao executar os comandos pg_chameleon.

No nodo PostgreSQL:

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

No nodo MySQL:

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

Os tres seguintes comandos pg_chameleon (camaleón) preparan o ambiente, engaden a fonte e inicializan a réplica. O argumento create_replica_schema para pg_chameleon crea un esquema predeterminado (sch_chameleon) e un esquema de replicación (pgworld_x) na base de datos PostgreSQL, como xa comentamos. O argumento add_source engade unha base de datos fonte á configuración lendo o ficheiro de configuración (default.yml), e no noso caso é mysql, e init_replica inicializa a configuración en función dos parámetros do ficheiro de configuración.

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

A saída destes tres comandos indica claramente que se executaron correctamente. Calquera fallo ou erro de sintaxe infórmase en mensaxes sinxelas e claras con consellos sobre como solucionar o problema.

Finalmente, comezamos a replicación usando start_replica e recibimos unha mensaxe de éxito.

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

Pódese consultar o estado da replicación mediante o argumento show_status e os erros pódense ver mediante o argumento show_errors.

O resultado.

Como xa dixemos, cada función de replicación está controlada por daemons. Para velos, consultamos a táboa de procesos co comando Linux ps, como se mostra a continuación.

O resultado.

A replicación non se considera configurada ata que a probamos en tempo real, como se mostra a continuación. Creamos unha táboa, inserimos un par de rexistros na base de datos MySQL e chamamos ao argumento sync_tables en pg_chameleon para actualizar os daemons e replicar a táboa cos rexistros na 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 confirmar os resultados da proba, consultamos a táboa desde a base de datos PostgreSQL e mostramos as filas.

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

Se estamos a facer unha migración, os seguintes comandos pg_chameleon serán o final da mesma. Os comandos deben ser executados despois de estar seguros de que se replicaron as filas de todas as táboas de destino e o resultado será unha base de datos PostgreSQL perfectamente migrada sen referencias á base de datos de orixe ou ao esquema de replicación (sch_chameleon).

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

Se o desexa, pode usar os seguintes comandos para eliminar a configuración orixinal e o esquema de replicación.

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

Vantaxes de pg_chameleon

Fácil instalación e configuración.
Resolve e identifique as anomalías facilmente con mensaxes de erro claras.
Pódense engadir táboas especiais adicionais á replicación despois da inicialización sen cambiar o resto da configuración.
É posible configurar varias bases de datos de orixe para unha única base de datos de destino, e isto é moi útil se está a combinar datos dunha ou máis bases de datos MySQL nunha única base de datos PostgreSQL.
Non tes que replicar as táboas seleccionadas.

Desvantaxes de pg_chameleon

Só é compatible con MySQL 5.5 e superior como fonte e PostgreSQL 9.5 e superior como base de datos de destino.
Cada táboa debe ter unha chave primaria ou única, se non, as táboas inicialízanse durante o proceso init_replica pero non se replican.
Replicación unidireccional: só de MySQL a PostgreSQL. Polo tanto, só é adecuado para o circuíto "activo-pasivo".
A fonte só pode ser unha base de datos MySQL e o soporte para unha base de datos PostgreSQL como fonte só é experimental e con limitacións (máis información aquí)

Resultados para pg_chameleon

O método de replicación en pg_chameleon é excelente para migrar unha base de datos de MySQL a PostgreSQL. A desvantaxe importante é que a replicación é só unidireccional, polo que é improbable que os profesionais de bases de datos queiran usala para outra cousa que non sexa a migración. Pero o problema da replicación unidireccional pódese resolver con outra ferramenta de código aberto: SymmetricDS.

Ler máis na documentación oficial aquí. Pódese atopar axuda na liña de comandos aquí.

Visión xeral de SymmetricDS

SymmetricDS é unha ferramenta de código aberto que replica calquera base de datos en calquera outra base de datos común: Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird e outras instancias de bases de datos na nube, por exemplo, Redshift e Azure, etc. Funcións dispoñibles: sincronización de bases de datos e ficheiros, replicación de bases de datos multimaster, sincronización filtrada, transformación e outras. Esta é unha ferramenta Java e require unha versión estándar de JRE ou JDK (versión 8.0 ou superior). Aquí, os cambios de datos dos disparadores na base de datos de orixe pódense rexistrar e enviar á base de datos de destino adecuada en forma de lotes.

Características SymmetricDS

A ferramenta é independente da plataforma, o que significa que dúas ou máis bases de datos diferentes poden intercambiar datos.
As bases de datos relacionais sincronízanse mediante rexistros de cambios de datos, mentres que as bases de datos baseadas no sistema de ficheiros usan a sincronización de ficheiros.
Replicación bidireccional mediante métodos Push e Pull baseados nun conxunto de regras.
A transferencia de datos é posible a través de redes seguras e de baixo ancho de banda.
Recuperación automática cando os nodos retoman a operación despois dun fallo e resolución automática de conflitos.
API de extensións potentes e compatibles coa nube.

Exemplo

SymmetricDS pódese configurar nunha das dúas opcións:
Un nodo mestre (pai) que coordina centralmente a replicación de datos entre dous nodos escravos (fillos), e a comunicación entre os nodos fillos só ocorre a través do pai.
Un nodo activo (nodo 1) pode comunicarse para a súa replicación con outro nodo activo (nodo 2) sen intermediario.

En ambas as opcións, o intercambio de datos prodúcese mediante Push e Pull. Neste exemplo consideraremos unha configuración activo-activo. Tardaría demasiado en describir toda a arquitectura, así que investiga. lideradopara obter máis información sobre o dispositivo SymmetricDS.

Instalar SymmetricDS é moi sinxelo: descarga a versión de código aberto do ficheiro zip por iso e sácao onde queiras. A táboa seguinte ofrece información sobre a localización e versión de instalación de SymmetricDS neste exemplo, así como as versións da base de datos, as versións de Linux, os enderezos IP e os portos de ambos os nodos.

Anfitrión
vm1
vm2

versión do SO
CentOS Linux 7.6 x86_64
CentOS Linux 7.6 x86_64

Versión do servidor DB
MySQL 5.7.26
PostgreSQL 10.5

Porto DB
3306
5832

Enderezo IP
192.168.1.107
192.168.1.112

Versión 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

Nome de nodo SymmetricDS
corpo-000
tenda-001

Aquí instalamos SymmetricDS en /usr/local/symmetric-server-3.9.20, e alí almacenaranse varios subdirectorios e ficheiros. Estamos interesados ​​nos subdirectorios de mostras e motores. O directorio de mostras contén ficheiros de configuración de exemplo con propiedades de nodos, así como exemplos de scripts SQL para comezar rapidamente.

No directorio de mostras vemos tres ficheiros de configuración con propiedades do nodo: o nome mostra a natureza do nodo nun esquema determinado.

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

SymmetricDS ten todos os ficheiros de configuración necesarios para un deseño básico de 3 nodos (opción 1) e os mesmos ficheiros pódense usar para un deseño de 2 nodos (opción 2). Copie o ficheiro de configuración necesario do directorio de mostras aos motores do servidor 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=000

Este nodo na configuración SymmetricDS chámase corp-000 e a conexión á base de datos é xestionada polo controlador mysql jdbc, que usa a cadea de conexión anterior e as credenciais de inicio de sesión. Conectámonos á base de datos replica_db e as táboas crearanse durante a creación do esquema. sync.url mostra onde contactar co nodo para a sincronización.

O nodo 2 do host vm2 está configurado como store-001 e o resto especifícase no ficheiro node.properties a continuación. Node store-001 executa a base de datos PostgreSQL e pgdb_replica é a base de datos de replicación. registration.url permite que o host vm2 se poña en contacto con host vm1 e reciba detalles de configuración del.

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

O exemplo SymmetricDS completo contén parámetros para configurar a replicación bidireccional entre dous servidores de bases de datos (dous nodos). Os pasos seguintes realízanse no host vm1 (corp-000), que creará un esquema de exemplo con 4 táboas. A continuación, executar create-sym-tables co comando symadmin crea táboas de directorio onde se almacenarán as regras e a dirección de replicación entre os nodos. Finalmente, os datos de mostra cárganse nas táboas.

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

No exemplo, as táboas de artigo e prezo_de_venda_de_venda están configuradas automaticamente para replicarse de corp-000 a store-001, e as táboas de venda (sale_transaction e sale_return_line_item) configúranse automaticamente para replicarse de store-001 a corp-000. Agora creamos un esquema na base de datos PostgreSQL no host vm2 (store-001) para preparalo 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

Asegúrese de comprobar que a base de datos MySQL en vm1 ten táboas de exemplo e táboas de catálogo SymmetricDS. Teña en conta que as táboas do sistema SymmetricDS (con prefixo sym_) actualmente só están dispoñibles no node corp-000 porque aí é onde executamos o comando create-sym-tables e xestionaremos a replicación. E na base de datos do node store-001 só haberá 4 táboas de exemplo sen datos.

Todos. O ambiente está preparado para executar procesos do servidor sym en ambos os nós, como se mostra a continuación.

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

As entradas de rexistro envíanse a un ficheiro de rexistro en segundo plano (symmetric.log) no cartafol de rexistros no directorio onde está instalado SymmetricDS, así como á saída estándar. O servidor sym agora pódese iniciar no node store-001.

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

Se executa o proceso do servidor sym no host vm2, tamén creará táboas de catálogo SymmetricDS na base de datos PostgreSQL. Se executas o proceso do servidor sym en ambos os nós, coordinaranse entre si para replicar os datos de corp-000 a store-001. Se despois duns segundos consultamos as 4 táboas de ambos os dous lados, veremos que a replicación foi exitosa. Ou pode enviar o bootstrap ao node store-001 desde corp-000 co seguinte comando.

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

Neste punto, insírese un novo rexistro na táboa de elementos da base de datos MySQL no nodo corp-000 (host: vm1) e pode comprobar a súa replicación na base de datos PostgreSQL no node store-001 (host: vm2). Vemos unha 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 unha operación Push para mover datos de store-001 a corp-000, inserimos un rexistro na táboa sale_transaction e verificamos que a replicación se realizou correctamente.

O resultado.

Vemos a configuración exitosa da replicación bidireccional das táboas de exemplo entre as bases de datos MySQL e PostgreSQL. Para configurar a replicación para novas táboas de usuarios, siga estes pasos: Creamos a táboa t1 por exemplo e configuramos as súas regras de replicación do seguinte xeito. Deste xeito configuramos só a 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)

A continuación, notifícase á configuración o cambio de esquema, é dicir, a adición dunha nova táboa, mediante o comando symadmin co argumento sync-triggers, que recrea os disparadores para mapear as definicións da táboa. send-schema execútase para enviar cambios de esquema ao node store-001 e configúrase a replicación da táboa t1.

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

Beneficios de SymmetricDS

Fácil instalación e configuración, incluíndo un conxunto listo de ficheiros con parámetros para crear un circuíto de tres ou dous nodos.
Bases de datos multiplataforma e independencia da plataforma, incluíndo servidores, portátiles e dispositivos móbiles.
Replica calquera base de datos en calquera outra base de datos localmente, na WAN ou na nube.
Posibilidade de traballo óptimo cun par de bases de datos ou varios miles para unha cómoda replicación.
Versión de pago con GUI e excelente soporte.

Desvantaxes de SymmetricDS

Debe definir manualmente as regras e a dirección da replicación na liña de comandos mediante instrucións SQL para cargar táboas de catálogo, o que pode resultar inconveniente.
Configurar moitas táboas para a replicación pode ser tedioso a menos que use scripts para crear instrucións SQL que definan as regras e a dirección da replicación.
Hai demasiada información que se rexistra nos rexistros e, ás veces, cómpre ordenar o ficheiro de rexistro para que non ocupe demasiado espazo.

Resultados para SymmetricDS

SymmetricDS permítelle configurar a replicación bidireccional entre dous, tres ou incluso varios miles de nodos para replicar e sincronizar ficheiros. Esta é unha ferramenta única que realiza de forma independente moitas tarefas, como a recuperación automática de datos despois dun longo período de inactividade nun nodo, o intercambio de datos seguro e eficiente entre nodos a través de HTTPS, a xestión automática de conflitos baseada nun conxunto de regras, etc. SymmetricDS realiza replicación entre calquera base de datos, polo tanto, pódese usar para unha gran variedade de escenarios, incluíndo migración, migración, distribución, filtrado e transformación de datos entre plataformas.

O exemplo baséase no oficial guía rápida por SymmetricDS. EN manual do usuario Describe en detalle os distintos conceptos implicados na configuración da replicación con SymmetricDS.

Fonte: www.habr.com