Descreverei a replicação cruzada entre PostgreSQL e MySQL, bem como métodos para configurar a replicação cruzada entre os dois servidores de banco de dados. Normalmente, os bancos de dados com replicação cruzada são chamados de homogêneos e é um método conveniente de migrar de um servidor RDBMS para outro.
Os bancos de dados PostgreSQL e MySQL são geralmente considerados relacionais, mas com extensões adicionais oferecem recursos NoSQL. Aqui discutiremos a replicação entre PostgreSQL e MySQL de uma perspectiva de SGBD relacional.
Não descreveremos todo o funcionamento interno, apenas os princípios básicos para que você tenha uma ideia de como configurar a replicação entre servidores de banco de dados, vantagens, limitações e casos de uso.
Normalmente, a replicação entre dois servidores de banco de dados idênticos é feita em modo binário ou usando consultas entre um mestre (também conhecido como editor, mestre ou ativo) e um escravo (assinante, em espera ou passivo). O objetivo da replicação é fornecer uma cópia em tempo real do banco de dados mestre no lado escravo. Nesse caso, os dados são transferidos de mestre para escravo, ou seja, de ativo para passivo, pois a replicação é realizada apenas em uma direção. Mas você pode configurar a replicação entre dois bancos de dados em ambas as direções, para que os dados sejam transferidos do escravo para o mestre em uma configuração ativa-ativa. Tudo isso, incluindo a replicação em cascata, é possível entre dois ou mais servidores de banco de dados idênticos. A configuração ativo-ativo ou ativo-passivo depende da necessidade, da disponibilidade de tais recursos na configuração inicial ou do uso de soluções de configuração externas e das compensações existentes.
A configuração descrita é possível entre diferentes servidores de banco de dados. O servidor pode ser configurado para aceitar dados replicados de outro servidor de banco de dados e ainda manter instantâneos em tempo real dos dados replicados. MySQL e PostgreSQL oferecem a maioria dessas configurações internamente ou por meio de extensões de terceiros, incluindo métodos de log binário, bloqueio de disco e métodos baseados em instruções e linhas.
A replicação cruzada entre MySQL e PostgreSQL é necessária para uma migração única de um servidor de banco de dados para outro. Esses bancos de dados utilizam protocolos diferentes, portanto não é possível vinculá-los diretamente. Para estabelecer a troca de dados, você pode usar uma ferramenta externa de código aberto, por exemplo pg_chameleon.
O que é pg_chameleon
pg_chameleon é um sistema de replicação de MySQL para PostgreSQL em Python 3. Ele usa a biblioteca de replicação mysql de código aberto, também em Python. As imagens de linha são extraídas de tabelas MySQL e armazenadas como objetos JSONB no banco de dados PostgreSQL e, em seguida, descriptografadas pela função pl/pgsql e reproduzidas no banco de dados PostgreSQL.
Recursos do pg_chameleon
Vários esquemas MySQL do mesmo cluster podem ser replicados para um único banco de dados PostgreSQL de destino em uma configuração um-para-muitos
Os nomes dos esquemas de origem e de destino não podem ser iguais.
Os dados de replicação podem ser recuperados de uma réplica MySQL em cascata.
As tabelas que não podem ser replicadas ou produzir erros são excluídas.
Cada função de replicação é controlada por daemons.
Controle por meio de parâmetros e arquivos de configuração baseados em YAML.
Exemplo
Host
vm1
vm2
Versão do SO
CentOSLinux 7.6 x86_64
CentOSLinux 7.5 x86_64
Versão do servidor de banco de dados
MySQL 5.7.26
PostgreSQL 10.5
Porta do banco de dados
3306
5433
Endereço IP
192.168.56.102
192.168.56.106
Para começar, prepare todos os componentes necessários para instalar o pg_chameleon. Este exemplo instala o Python 3.6.8, que cria e ativa 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 altinstallDepois de instalar o Python3.6 com sucesso, você precisa concluir os requisitos restantes, como criar e ativar um ambiente virtual. Além disso, o módulo pip é atualizado para a versão mais recente e usado para instalar o pg_chameleon. Os comandos abaixo instalam intencionalmente o pg_chameleon 2.0.9, embora a versão mais recente seja 2.0.10. Isso é necessário para evitar novos bugs na versão atualizada.
$> python3.6 -m venv venv
$> source venv/bin/activate
(venv) $> pip install pip --upgrade
(venv) $> pip install pg_chameleon==2.0.9Em seguida, chamamos pg_chameleon (chameleon é um comando) com o argumento set_configuration_files para ativar o pg_chameleon e criar diretórios e arquivos de configuração padrão.
(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.ymlAgora criamos uma cópia de config-example.yml como default.yml para que ele se torne o arquivo de configuração padrão. Um arquivo de configuração de amostra para este exemplo é fornecido abaixo.
$> 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 arquivo de configuração neste exemplo é um arquivo pg_chameleon de amostra com pequenas modificações para se adequar aos ambientes de origem e destino, e abaixo está uma visão geral das diferentes seções do arquivo de configuração.
No arquivo de configuração default.yml há uma seção de configurações globais, onde você pode gerenciar configurações como a localização do arquivo de bloqueio, a localização dos logs, o período de armazenamento dos logs, etc. um conjunto de regras para substituir tipos durante a replicação. O exemplo padrão é uma regra de substituição de tipo que converte tinyint(1) em um valor booleano. Na próxima seção, especificamos os detalhes da conexão com o banco de dados de destino. No nosso caso, este é um banco de dados PostgreSQL, designado pg_conn. Na última seção indicamos os dados de origem, ou seja, os parâmetros de conexão do banco de dados de origem, o esquema de mapeamento entre os bancos de origem e de destino, tabelas que precisam ser ignoradas, tempo de espera, memória, tamanho do pacote. Observe que "fontes" é plural, o que significa que podemos adicionar vários bancos de dados de origem a um único banco de dados de destino para definir uma configuração muitos para um.
O banco de dados de exemplo world_x contém 4 tabelas com linhas que a comunidade MySQL oferece como exemplos. Ele pode ser baixado . O banco de dados de amostra vem como um arquivo tar e compactado com instruções para criar e importar linhas.
Nos bancos de dados MySQL e PostgreSQL, um usuário especial é criado com o mesmo nome usr_replica. No MySQL, são concedidos direitos de leitura adicionais a todas as tabelas 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 PostgreSQL, é criado um banco de dados db_replica que aceitará alterações do banco de dados MySQL. O usuário usr_replica no PostgreSQL é automaticamente configurado como proprietário de dois esquemas, pgworld_x e sch_chameleon, que contêm as tabelas replicadas reais e as tabelas do diretório de replicação, respectivamente. O argumento create_replica_schema é responsável pela configuração automática, como você verá a seguir.
postgres=# CREATE USER usr_replica WITH PASSWORD 'pass123';
CREATE ROLE
postgres=# CREATE DATABASE db_replica WITH OWNER usr_replica;
CREATE DATABASEO banco de dados MySQL é configurado com algumas alterações de parâmetros para prepará-lo para replicação, conforme mostrado abaixo. Você precisará reiniciar o servidor de banco de dados para que as alterações tenham efeito.
$> vi /etc/my.cnf
binlog_format= ROW
binlog_row_image=FULL
log-bin = mysql-bin
server-id = 1Agora é importante verificar a conexão com ambos os servidores de banco de dados para que não haja problemas ao executar os comandos pg_chameleon.
No nó PostgreSQL:
$> mysql -u usr_replica -Ap'admin123' -h 192.168.56.102 -D world_xNo nó MySQL:
$> psql -p 5433 -U usr_replica -h 192.168.56.106 db_replicaOs próximos três comandos pg_chameleon (chameleon) preparam o ambiente, adicionam a origem e inicializam a réplica. O argumento create_replica_schema para pg_chameleon cria um esquema padrão (sch_chameleon) e um esquema de replicação (pgworld_x) no banco de dados PostgreSQL, como já discutimos. O argumento add_source adiciona um banco de dados de origem à configuração lendo o arquivo de configuração (default.yml), e no nosso caso é mysql, e init_replica inicializa a configuração com base nos parâmetros do arquivo de configuração.
$> chameleon create_replica_schema --debug
$> chameleon add_source --config default --source mysql --debug
$> chameleon init_replica --config default --source mysql --debugA saída desses três comandos indica claramente que eles foram executados com sucesso. Quaisquer falhas ou erros de sintaxe são relatados em mensagens simples e claras com dicas sobre como resolver o problema.
Finalmente, iniciamos a replicação usando start_replica e recebemos uma mensagem de sucesso.
$> chameleon start_replica --config default --source mysql
output: Starting the replica process for source mysqlO status da replicação pode ser consultado usando o argumento show_status e os erros podem ser visualizados usando o argumento show_errors.
Como já dissemos, cada função de replicação é controlada por daemons. Para visualizá-los, consultamos a tabela de processos com o comando ps do Linux, conforme mostrado abaixo.
A replicação não é considerada configurada até que a testemos em tempo real, conforme mostrado abaixo. Criamos uma tabela, inserimos alguns registros no banco de dados MySQL e chamamos o argumento sync_tables em pg_chameleon para atualizar os daemons e replicar a tabela com os registros para o banco de dados 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 do teste, consultamos a tabela do banco de dados PostgreSQL e geramos as linhas.
$> psql -p 5433 -U usr_replica -d db_replica -c "select * from pgworld_x.t1";
n1 | n2
----+-------
1 | one
2 | twoSe estivermos fazendo uma migração, os seguintes comandos pg_chameleon serão o fim dela. Os comandos precisam ser executados depois de termos certeza de que as linhas de todas as tabelas de destino foram replicadas e o resultado será um banco de dados PostgreSQL migrado perfeitamente, sem referências ao banco de dados de origem ou esquema de replicação (sch_chameleon).
$> chameleon stop_replica --config default --source mysql
$> chameleon detach_replica --config default --source mysql --debugSe desejar, você pode usar os comandos a seguir para excluir a configuração original e o esquema de replicação.
$> chameleon drop_source --config default --source mysql --debug
$> chameleon drop_replica_schema --config default --source mysql --debugVantagens do pg_chameleon
Fácil instalação e configuração.
Solucione problemas e identifique anomalias facilmente com mensagens de erro claras.
Tabelas especiais adicionais podem ser adicionadas à replicação após a inicialização sem alterar o restante da configuração.
É possível configurar vários bancos de dados de origem para um único banco de dados de destino, e isso é muito útil se você estiver combinando dados de um ou mais bancos de dados MySQL em um único banco de dados PostgreSQL.
Você não precisa replicar as tabelas selecionadas.
Desvantagens do pg_chameleon
Compatível apenas com MySQL 5.5 e superior como origem e PostgreSQL 9.5 e superior como banco de dados de destino.
Cada tabela deve ter uma chave primária ou exclusiva; caso contrário, as tabelas serão inicializadas durante o processo init_replica, mas não serão replicadas.
Replicação unidirecional - somente de MySQL para PostgreSQL. Portanto, é adequado apenas para o circuito “ativo-passivo”.
A fonte só pode ser um banco de dados MySQL, e o suporte a um banco de dados PostgreSQL como fonte é apenas experimental e com limitações (saiba mais )
Resultados para pg_chameleon
O método de replicação em pg_chameleon é ótimo para migrar um banco de dados MySQL para PostgreSQL. A desvantagem significativa é que a replicação é unidirecional, portanto, é improvável que os profissionais de banco de dados queiram usá-la para outra coisa que não seja a migração. Mas o problema da replicação unilateral pode ser resolvido com outra ferramenta de código aberto - SymmetricDS.
Leia mais na documentação oficial . A ajuda da linha de comando pode ser encontrada .
Visão geral do SymmetricDS
SymmetricDS é uma ferramenta de código aberto que replica qualquer banco de dados para qualquer outro banco de dados comum: Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird e outras instâncias de banco de dados em nuvem, por exemplo, Redshift e Azure, etc. Recursos disponíveis: sincronização de banco de dados e arquivos, replicação de banco de dados multimestre, sincronização filtrada, transformação e outros. Esta é uma ferramenta Java e requer uma versão padrão do JRE ou JDK (versão 8.0 ou superior). Aqui, as alterações de dados nos gatilhos no banco de dados de origem podem ser registradas e enviadas para o banco de dados de destino apropriado na forma de lotes.
Recursos do SymmetricDS
A ferramenta é independente de plataforma, o que significa que dois ou mais bancos de dados diferentes podem trocar dados.
Os bancos de dados relacionais são sincronizados usando registros de alteração de dados, enquanto os bancos de dados baseados em sistema de arquivos usam a sincronização de arquivos.
Replicação bidirecional usando métodos Push e Pull baseados em um conjunto de regras.
A transferência de dados é possível em redes seguras e de baixa largura de banda.
Recuperação automática quando os nós retomam a operação após uma falha e resolução automática de conflitos.
APIs de extensão poderosas e compatíveis com a nuvem.
Exemplo
SymmetricDS pode ser configurado em uma das duas opções:
Um nó mestre (pai) que coordena centralmente a replicação de dados entre dois nós escravos (filhos), e a comunicação entre os nós filhos ocorre apenas por meio do pai.
Um nó ativo (Nó 1) pode se comunicar para replicação com outro nó ativo (Nó 2) sem intermediário.
Em ambas as opções, a troca de dados ocorre por meio de Push e Pull. Neste exemplo consideraremos uma configuração ativa-ativa. Levaria muito tempo para descrever toda a arquitetura, então faça sua pesquisa. para saber mais sobre o dispositivo SymmetricDS.
Instalar o SymmetricDS é muito simples: baixe a versão open source do arquivo zip e leve-o para onde quiser. A tabela abaixo fornece informações sobre o local de instalação e a versão do SymmetricDS neste exemplo, bem como as versões do banco de dados, versões do Linux, endereços IP e portas para ambos os nós.
Host
vm1
vm2
Versão do SO
CentOSLinux 7.6 x86_64
CentOSLinux 7.6 x86_64
Versão do servidor de banco de dados
MySQL 5.7.26
PostgreSQL 10.5
Porta do banco de dados
3306
5832
Endereço IP
192.168.1.107
192.168.1.112
Versão SymmetricDS
SimétricoDS 3.9
SimétricoDS 3.9
Caminho de instalação do SymmetricDS
/usr/local/servidor-simétrico-3.9.20
/usr/local/servidor-simétrico-3.9.20
Nome do nó SymmetricDS
corp-000
loja-001
Aqui instalamos SymmetricDS em /usr/local/symmetric-server-3.9.20, e vários subdiretórios e arquivos serão armazenados lá. Estamos interessados nos subdiretórios samples e motores. O diretório samples contém exemplos de arquivos de configuração com propriedades de nó, bem como exemplos de scripts SQL para você começar rapidamente.
No diretório de amostras, vemos três arquivos de configuração com propriedades do nó - o nome mostra a natureza do nó em um determinado esquema.
corp-000.properties
store-001.properties
store-002.propertiesSymmetricDS possui todos os arquivos de configuração necessários para um projeto básico de 3 nós (opção 1), e os mesmos arquivos podem ser usados para um projeto de 2 nós (opção 2). Copie o arquivo de configuração necessário do diretório de amostras para os mecanismos no host vm1. Acontece assim:
$> 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 nó na configuração SymmetricDS é chamado corp-000, e a conexão com o banco de dados é controlada pelo driver mysql jdbc, que usa a string de conexão acima e as credenciais de login. Nós nos conectamos ao banco de dados replica_db e as tabelas serão criadas durante a criação do esquema. sync.url mostra o local da conexão com o nó para sincronização.
O nó 2 no host vm2 é configurado como store-001 e o restante é especificado no arquivo node.properties abaixo. O nó store-001 executa o banco de dados PostgreSQL e pgdb_replica é o banco de dados de replicação. Registration.url permite que o host vm2 entre em contato com o host vm1 e receba detalhes de configuração dele.
$> 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=001O exemplo completo do SymmetricDS contém parâmetros para configurar a replicação bidirecional entre dois servidores de banco de dados (dois nós). As etapas abaixo são executadas no host vm1 (corp-000), que criará um esquema de exemplo com 4 tabelas. Em seguida, executar create-sym-tables com o comando symadmin cria tabelas de diretório onde as regras e a direção de replicação entre os nós serão armazenadas. Finalmente, os dados de amostra são carregados nas tabelas.
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.sqlNo exemplo, as tabelas item e item_selling_price são configuradas automaticamente para replicar de corp-000 para store-001, e as tabelas de vendas (sale_transaction e sale_return_line_item) são automaticamente configuradas para replicar de store-001 para corp-000. Agora criamos um esquema no banco de dados PostgreSQL no host vm2 (store-001) para prepará-lo para receber dados de corp-000.
vm2$> cd /usr/local/symmetric-server-3.9.20/bin
vm2$> ./dbimport --engine store-001 --format XML create_sample.xmlCertifique-se de verificar se o banco de dados MySQL na vm1 possui tabelas de exemplo e tabelas de catálogo SymmetricDS. Observe que as tabelas do sistema SymmetricDS (prefixadas com sym_) estão atualmente disponíveis apenas no nó corp-000 porque é onde executamos o comando create-sym-tables e gerenciaremos a replicação. E no banco de dados do nó store-001 haverá apenas 4 tabelas de exemplo sem dados.
Todos. O ambiente está pronto para executar processos do servidor sym em ambos os nós, conforme mostrado abaixo.
vm1$> cd /usr/local/symmetric-server-3.9.20/bin
vm1$> sym 2>&1 &As entradas de log são enviadas para um arquivo de log em segundo plano (symmetric.log) na pasta logs no diretório onde o SymmetricDS está instalado, bem como para a saída padrão. O servidor sym agora pode ser iniciado no nó store-001.
vm2$> cd /usr/local/symmetric-server-3.9.20/bin
vm2$> sym 2>&1 &Se você executar o processo do servidor sym no host vm2, ele também criará tabelas de catálogo SymmetricDS no banco de dados PostgreSQL. Se você executar o processo do servidor sym em ambos os nós, eles se coordenarão para replicar dados de corp-000 para store-001. Se após alguns segundos consultarmos todas as 4 tabelas de ambos os lados, veremos que a replicação foi bem-sucedida. Ou você pode enviar o bootstrap para o nó store-001 de corp-000 com o seguinte comando.
vm1$> ./symadmin --engine corp-000 reload-node 001Neste ponto, um novo registro é inserido na tabela de itens do banco de dados MySQL no nó corp-000 (host: vm1), e você pode verificar sua replicação para o banco de dados PostgreSQL no nó store-001 (host: vm2). Vemos uma operação Pull para mover dados de corp-000 para 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 uma operação Push para mover dados de store-001 para corp-000, inserimos um registro na tabela sale_transaction e verificamos se a replicação foi bem-sucedida.
Vemos a configuração bem-sucedida da replicação bidirecional das tabelas de exemplo entre os bancos de dados MySQL e PostgreSQL. Para configurar a replicação para novas tabelas de usuários, siga estas etapas: Criamos a tabela t1 por exemplo e configuramos suas regras de replicação da seguinte forma. Desta forma configuramos apenas a replicação de corp-000 para 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 configuração é então notificada sobre a alteração do esquema, ou seja, a adição de uma nova tabela, utilizando o comando symadmin com o argumento sync-triggers, que recria os triggers para mapear as definições da tabela. send-schema é executado para enviar alterações de esquema para o nó store-001 e a replicação da tabela t1 é configurada.
vm1$> ./symadmin -e corp-000 --node=001 sync-triggers
vm1$> ./symadmin send-schema -e corp-000 --node=001 t1Benefícios do SymmetricDS
Fácil instalação e configuração, incluindo um conjunto pronto de arquivos com parâmetros para criar um circuito de três ou dois nós.
Bancos de dados multiplataforma e independência de plataforma, incluindo servidores, laptops e dispositivos móveis.
Replique qualquer banco de dados para qualquer outro banco de dados localmente, na WAN ou na nuvem.
Possibilidade de trabalho ideal com alguns bancos de dados ou vários milhares para replicação conveniente.
Versão paga com GUI e excelente suporte.
Desvantagens do SymmetricDS
Você precisa definir manualmente as regras e a direção da replicação na linha de comando por meio de instruções SQL para carregar tabelas de catálogo, o que pode ser inconveniente.
Configurar muitas tabelas para replicação pode ser entediante, a menos que você use scripts para criar instruções SQL que definam as regras e a direção da replicação.
Há muitas informações sendo registradas nos logs e às vezes é necessário arrumar o arquivo de log para que não ocupe muito espaço.
Resultados para SymmetricDS
SymmetricDS permite configurar a replicação bidirecional entre dois, três ou até vários milhares de nós para replicar e sincronizar arquivos. Esta é uma ferramenta única que executa muitas tarefas de forma independente, como recuperação automática de dados após um longo período de inatividade em um nó, troca segura e eficiente de dados entre nós via HTTPS, gerenciamento automático de conflitos com base em um conjunto de regras, etc. replicação entre quaisquer bancos de dados, portanto, pode ser usado para uma ampla variedade de cenários, incluindo migração, migração, distribuição, filtragem e transformação de dados entre plataformas.
O exemplo é baseado no documento oficial por SymmetricDS. EM Descreve detalhadamente os vários conceitos envolvidos na configuração da replicação com SymmetricDS.
Fonte: habr.com