Vou dar uma visão geral sobre replicação cruzada entre PostgreSQL e MySQL, além de métodos de configuração para essa replicação entre esses dois servidores de banco de dados. Geralmente, os bancos de dados na replicação cruzada são chamados de homogêneos, e esse é um método conveniente para a transição de um servidor de SGBD relacional para outro.
Os bancos de dados PostgreSQL e MySQL são considerados relacionais, mas com extensões adicionais, eles oferecem capacidades NoSQL. Aqui, discutiremos a replicação entre PostgreSQL e MySQL na perspectiva de SGBDs relacionais.
Não vamos descrever toda a mecânica interna, apenas os princípios básicos, para que você possa ter uma noção de como configurar a replicação entre servidores de banco de dados, incluindo vantagens, limitações e cenários de uso.
Geralmente, a replicação entre dois servidores de banco de dados idênticos é realizada em modo binário ou através de consultas entre o nó principal (também chamado de editor, master ou ativo) e o secundário (assinante, standby ou passivo). O objetivo da replicação é fornecer uma cópia em tempo real do banco de dados principal no lado secundário. Os dados são transferidos do principal para o secundário, ou seja, do ativo para o passivo, uma vez que a replicação ocorre apenas em uma direção. Contudo, é possível configurar a replicação entre dois bancos de dados em ambas as direções, permitindo que os dados sejam transferidos do secundário para o principal em uma configuração “ativo-ativo”. Tudo isso, incluindo replicação em cascata, é viável entre dois ou mais servidores de banco de dados idênticos. A configuração “ativo-ativo” ou “ativo-passivo” depende das necessidades, da disponibilidade dessas capacidades na configuração original ou do uso de soluções externas para a configuração, além de compromissos existentes.
A configuração descrita é possível entre diferentes servidores de banco de dados. Um servidor pode ser configurado para receber dados replicados de outro servidor de banco de dados, mantendo ao mesmo tempo instantâneas dos dados replicados em tempo real. MySQL e PostgreSQL oferecem a maioria dessas configurações, seja por conta própria ou por meio de extensões de terceiros, incluindo métodos de log binário, bloqueio de disco e métodos baseados em operadores 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 usam protocolos diferentes, portanto, não é possível conectá-los diretamente. Para estabelecer a troca de dados, pode-se usar uma ferramenta de código aberto externa, como o pg_chameleon.
O que é pg_chameleon
O pg_chameleon é um sistema de replicação do MySQL para PostgreSQL escrito em Python 3. Ele utiliza a biblioteca de código aberto mysql-replication, também em Python. As imagens das linhas são extraídas das tabelas do MySQL e salvas como objetos JSONB no banco de dados PostgreSQL, e depois decodificadas pela função pl/pgsql e reproduzidas no banco de dados PostgreSQL.
Recursos do pg_chameleon
Várias esquemas MySQL de um cluster podem ser replicados em um único banco de dados PostgreSQL com a 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 extraídos de uma réplica em cascata do MySQL.
Tabelas que não podem ser replicadas ou que geram erros são excluídas.
Cada função de replicação é controlada por demônios.
Controle através de parâmetros e arquivos de configuração em formato YAML.
Exemplo
Host
vm1
vm2
Versão do SO
CentOS Linux 7.6 x86_64
CentOS Linux 7.5 x86_64
Versão do servidor de BD
MySQL 5.7.26
PostgreSQL 10.5
Porta do BD
3306
5433
Endereço IP
192.168.56.102
192.168.56.106
Primeiro, prepare todos os componentes necessários para a instalação do pg_chameleon. Neste exemplo, o Python 3.6.8 está instalado, que cria um ambiente virtual e o ativa.
$> 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 altinstallApós a instalação bem-sucedida do Python 3.6, é necessário cumprir os outros requisitos, 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. Nas comandos abaixo, o pg_chameleon 2.0.9 é instalado intencionalmente, embora a versão mais recente seja 2.0.10. Isso é para evitar bugs novos 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 o pg_chameleon (chameleon é o comando) com o argumento set_configuration_files, para ativar o pg_chameleon e criar os diretórios e os arquivos de configuração padrão.
(venv) $> chameleon set_configuration_files
criando diretório /root/.pg_chameleon
criando diretório /root/.pg_chameleon/configuration/
criando diretório /root/.pg_chameleon/logs/
criando diretório /root/.pg_chameleon/pid/
copiando configuração exemplo em /root/.pg_chameleon/configuration//config-example.ymlAgora estamos criando uma cópia do config-example.yml como default.yml, para que se torne o arquivo de configuração padrão. Um exemplo do arquivo de configuração para este caso é fornecido abaixo.
$> cat default.yml
---
# configurações globais
pid_dir: '~/.pg_chameleon/pid/'
log_dir: '~/.pg_chameleon/logs/'
log_dest: file
log_level: info
log_days_keep: 10
rollbar_key: ''
rollbar_env: ''
# type_override permite que o usuário substitua a conversão de tipo padrão por uma diferente.
type_override:
"tinyint(1)":
override_to: boolean
override_tables:
- "*"
# conexão de destino do postgres
pg_conn:
host: "192.168.56.106"
port: "5433"
user: "usr_replica"
password: "pass123"
database: "db_replica"
charset: "utf8"
sources:
mysql:
db_conn:
host: "192.168.56.102"
port: "3306"
user: "usr_replica"
password: "pass123"
charset: 'utf8'
connect_timeout: 10
schema_mappings:
world_x: pgworld_x
limit_tables:
# - delphis_mediterranea.foo
skip_tables:
# - delphis_mediterranea.bar
grant_select_to:
- usr_readonly
lock_timeout: "120s"
my_server_id: 100
replica_batch_size: 10000
replay_max_rows: 10000
batch_retention: '1 day'
copy_max_memory: "300M"
copy_mode: 'file'
out_dir: /tmp
sleep_loop: 1
on_error_replay: continue
on_error_read: continue
auto_maintenance: "disabled"
gtid_enable: No
type: mysql
skip_events:
insert:
- delphis_mediterranea.foo # ignora inserções na tabela delphis_mediterranea.foo
delete:
- delphis_mediterranea # ignora exclusões no esquema delphis_mediterranea
update:O arquivo de configuração neste exemplo é um modelo de arquivo pg_chameleon com pequenas alterações conforme o ambiente de origem e destino, e abaixo está uma visão geral das várias seções do arquivo de configuração.
No arquivo de configuração default.yml, há uma seção de parâmetros globais (global settings), 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. Em seguida, segue a seção de substituição de tipos (type override), onde um conjunto de regras para substituição de tipos durante a replicação é especificado. O exemplo padrão utiliza uma regra de substituição de tipo que transforma 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, é o banco de dados PostgreSQL, denominado pg_conn. Na última seção, fornecemos os dados da fonte, ou seja, os parâmetros de conexão do banco de dados de origem, o mapeamento de esquemas entre os bancos de dados de origem e destino, as tabelas que devem ser ignoradas, o tempo de espera, a memória, e o tamanho do lote. Observe que "sources" está no plural, o que significa que podemos adicionar vários bancos de dados de origem para um único destino, configurando a replicação de "muitos para um".
O banco de dados world_x no exemplo contém 4 tabelas com linhas que a comunidade MySQL oferece como exemplo. Ele pode ser baixado . O exemplo do banco de dados é fornecido em forma de tar e como um arquivo compactado com instruções para criar e importar as linhas.
Em bancos de dados MySQL e PostgreSQL, é criado um usuário especial com o mesmo nome usr_replica. No MySQL, lhe são concedidos direitos adicionais para ler 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 do PostgreSQL, é criado um banco de dados db_replica, que receberá 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 efetivas e as tabelas do catálogo de replicação, respectivamente. A configuração automática é gerenciada pelo argumento create_replica_schema, como você verá abaixo.
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 a alteração de alguns parâmetros para prepará-lo para replicação, como mostrado abaixo. O servidor de bancos de dados precisará ser reiniciado para que as alterações entrem em vigor.
$> vi /etc/my.cnf
binlog_format= ROW
binlog_row_image=FULL
log-bin = mysql-bin
server-id = 1Agora é importante verificar a conexão com os dois servidores de bancos de dados, para que não ocorram problemas ao executar 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 três comandos a seguir do pg_chameleon (chameleon) preparam o ambiente, adicionam a fonte e inicializam a réplica. O argumento create_replica_schema no pg_chameleon cria o esquema padrão (sch_chameleon) e o esquema de replicação (pgworld_x) no banco de dados PostgreSQL, como já mencionamos. O argumento add_source adiciona o banco de dados de origem à configuração, lendo o arquivo de configuração (default.yml), e no nosso caso é o mysql, enquanto 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 sua execução bem-sucedida. Todas as falhas ou erros de sintaxe são apresentados em mensagens simples e compreensíveis, com dicas para a correção dos problemas.
Finalmente, vamos iniciar a replicação usando start_replica e receber uma mensagem de execução bem-sucedida.
$> chameleon start_replica --config default --source mysql
output: Iniciando o processo de replicação para a fonte 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á mencionamos, cada função de replicação é gerenciada por demônios. Para visualizá-los, consultamos a tabela de processos com o comando Linux ps, conforme mostrado abaixo.
A replicação não é considerada configurada até que a testemos em tempo real, como mostrado abaixo. Criamos uma tabela, inserimos algumas linhas no banco de dados MySQL e chamamos o argumento sync_tables no pg_chameleon para atualizar os demônios e replicar a tabela com as entradas no 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
O processo de sincronização de tabelas para a fonte mysql foi iniciado.Para confirmar os resultados do teste, consultamos a tabela do banco de dados PostgreSQL e exibimos as linhas.
$> psql -p 5433 -U usr_replica -d db_replica -c "select * from pgworld_x.t1";
n1 | n2
----+-------
1 | one
2 | twoSe estivermos realizando uma migração, os seguintes comandos do pg_chameleon concluirão o processo. Os comandos devem ser executados após garantirmos que todas as linhas das tabelas de destino foram replicadas, resultando em um banco de dados PostgreSQL perfeitamente transferido, sem referências ao banco de dados ou esquema de replicação de origem (sch_chameleon).
$> chameleon stop_replica --config default --source mysql
$> chameleon detach_replica --config default --source mysql --debugOpcionalmente, os seguintes comandos podem ser usados para remover a configuração de origem 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
Configuração e configuração simples.
Depuração conveniente e identificação de anomalias 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árias bases de dados de origem para uma única base de dados de destino, o que é muito conveniente ao consolidar dados de uma ou mais bases de dados MySQL em uma única base de dados PostgreSQL.
É possível não replicar tabelas selecionadas.
Desvantagens do pg_chameleon
Suporta apenas MySQL 5.5 ou superior como fonte e PostgreSQL 9.5 ou superior como base de dados de destino.
Cada tabela deve ter uma chave primária ou única, caso contrário, as tabelas são inicializadas durante o processo init_replica, mas não são replicadas.
A replicação unidirecional é apenas de MySQL para PostgreSQL. Portanto, é adequada apenas para um esquema 'ativo-passivo'.
A base de dados de origem pode ser apenas uma base de dados MySQL, e o suporte à base de dados PostgreSQL como origem é apenas experimental e com restrições (saiba mais) )
Resumo sobre pg_chameleon
O método de replicação no pg_chameleon é ideal para migrar uma base de dados de MySQL para PostgreSQL. A desvantagem significativa é que a replicação é unidirecional, por isso, especialistas em bases de dados provavelmente não desejarão utilizá-lo para algo além de migração. No entanto, o problema da replicação unidirecional 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 base de dados para outra base de dados comum: Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird e outras instâncias de bancos de dados em nuvem, como Redshift e Azure, etc. Recursos disponíveis: sincronização de bases de dados e arquivos, replicação de várias bases de dados principais, sincronização filtrada, transformação e outros. Esta é uma ferramenta em Java, e é necessário ter a edição padrão do JRE ou JDK (versões 8.0 ou superior). Aqui, pode-se registrar alterações de dados através de triggers na base de dados de origem e direcioná-las para a respectiva base de dados de destino em pacotes.
Recursos do SymmetricDS
A ferramenta é independente de plataforma, o que significa que duas ou mais bases de dados diferentes podem trocar dados.
Bases de dados relacionais são sincronizadas por meio do registro de alterações de dados, enquanto bases de dados baseadas em sistemas de arquivos utilizam sincronização de arquivos.
Replicação bidirecional utilizando métodos Push e Pull baseados em um conjunto de regras.
A transferência de dados é possível através de redes seguras e redes com baixa largura de banda.
Recuperação automática ao retomar o funcionamento dos nós após falhas e resolução automática de conflitos.
Compatibilidade com a nuvem e APIs de extensões eficientes.
Exemplo
O SymmetricDS pode ser configurado de uma das duas maneiras:
Um nó principal (pai) que coordena centralmente a replicação de dados entre dois nós seguidores (filhos), e a troca de dados entre os nós filhos ocorre apenas através do pai.
Um nó ativo (nó 1) pode trocar dados 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, vamos considerar a configuração "ativo-ativo". Descrever toda a arquitetura leva muito tempo, então estude , para saber mais sobre o dispositivo SymmetricDS.
Instalar o SymmetricDS é muito simples: baixe a versão de código aberto do arquivo zip e extraia-o onde quiser. A tabela abaixo fornece informações sobre o local de instalação e a versão do SymmetricDS neste exemplo, além de versões de bancos de dados, versões do Linux, endereços IP e portas para ambos os nós.
Host
vm1
vm2
Versão do SO
CentOS Linux 7.6 x86_64
CentOS Linux 7.6 x86_64
Versão do servidor de BD
MySQL 5.7.26
PostgreSQL 10.5
Porta do BD
3306
5832
Endereço IP
192.168.1.107
192.168.1.112
Versão do SymmetricDS
SymmetricDS 3.9
SymmetricDS 3.9
Caminho de instalação do SymmetricDS
/usr/local/symmetric-server-3.9.20
/usr/local/symmetric-server-3.9.20
Nome do nó do SymmetricDS
corp-000
store-001
Aqui estamos instalando o SymmetricDS em /usr/local/symmetric-server-3.9.20, e diferentes diretórios e arquivos armazenados aqui. Estamos interessados nos diretórios e motores aninhados. No diretório de exemplos, existem exemplos de arquivos de configuração com propriedades do nó, bem como exemplos de scripts SQL para uma demonstração rápida.
No diretório de exemplos, vemos três arquivos de configuração com as propriedades do nó — o nome indica a natureza do nó em um determinado esquema.
corp-000.properties
store-001.properties
store-002.propertiesO SymmetricDS possui todos os arquivos de configuração necessários para um esquema básico de 3 nós (opção 1), e os mesmos arquivos podem ser usados para um esquema de 2 nós (opção 2). Copiamos o arquivo de configuração necessário do diretório de exemplos para os motores no host vm1. Ficamos 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 do SymmetricDS é chamado de corp-000, e a conexão com o banco de dados é gerenciada pelo driver mysql jdbc, que utiliza a string de conexão mencionada acima e as credenciais de acesso. Estamos conectando ao banco de dados replica_db, e durante a criação do esquema, as tabelas serão criadas. sync.url indica o local de conexão com o nó para sincronização.
O nó 2 no host vm2 é configurado como store-001, e o restante está especificado no arquivo node.properties, que é apresentado abaixo. O nó store-001 executa um banco de dados PostgreSQL, e pgdb_replica é o banco de dados para replicação. registration.url permite que o host vm2 se conecte ao host vm1 e obtenha os detalhes de configuração.
$> 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 exemplo de esquema com 4 tabelas. Em seguida, a execução do comando create-sym-tables pelo symadmin criará as tabelas de catálogo, onde serão armazenadas as regras e a direção da replicação entre os nós. Por fim, um conjunto de dados de exemplo é carregado 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 replicação de corp-000 para store-001, enquanto as tabelas sale (sale_transaction e sale_return_line_item) são configuradas automaticamente para replicação de store-001 para corp-000. Agora, criamos o 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 que há exemplos de tabelas e tabelas de catálogo do SymmetricDS no banco de dados MySQL em vm1. Observe que as tabelas de sistema do SymmetricDS (com o prefixo sym_) estão atualmente disponíveis apenas no nó corp-000, porque lá executamos o comando create-sym-tables e vamos gerenciar a replicação. Além disso, no banco de dados no nó store-001, haverá apenas 4 tabelas de exemplo sem dados.
Pronto. O ambiente está preparado para executar processos de servidor sym em ambos os nós, como mostrado abaixo.
vm1$> cd /usr/local/symmetric-server-3.9.20/bin
vm1$> sym 2>&1 &Os registros de log são enviados para o arquivo de log em segundo plano (symmetric.log) na pasta de logs no diretório onde o SymmetricDS está instalado, assim 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 o processo do servidor sym for iniciado no host vm2, ele criará tabelas do catálogo SymmetricDS também no banco de dados PostgreSQL. Se o processo do servidor sym for iniciado em ambos os nós, eles se coordenarão para replicar dados de corp-000 para store-001. Se, após alguns segundos, solicitarmos todas as 4 tabelas de ambos os lados, veremos que a replicação foi bem-sucedida. Ou podemos enviar uma carga inicial para o nó store-001 de corp-000 com o seguinte comando.
vm1$> ./symadmin --engine corp-000 reload-node 001Neste estágio, um novo registro é inserido na tabela item no banco de dados MySQL no nó corp-000 (host: vm1), e podemos verificar sua replicação no banco de dados PostgreSQL no nó store-001 (host: vm2). Observamos a 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 executar a 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 concluída.
Observamos uma configuração bem-sucedida de 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, seguimos as etapas a seguir. Criamos a tabela t1 como exemplo e configuramos suas regras de replicação da seguinte maneira. Dessa 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)Em seguida, a configuração recebe uma notificação sobre a alteração do esquema, ou seja, a adição de uma nova tabela, através do comando symadmin com o argumento sync-triggers, que recria os gatilhos para corresponder às definições das tabelas. O comando send-schema é executado para enviar as alterações do 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 t1Vantagens do SymmetricDS
Instalação e configuração simples, incluindo um pacote pronto de arquivos de parâmetros para criar um esquema com três ou dois nós.
Interoperabilidade de bancos de dados e independência de plataforma, incluindo servidores, laptops e dispositivos móveis.
Replicação de qualquer banco de dados para qualquer outro banco de dados localmente, em WAN ou na nuvem.
Capacidade de operar de forma otimizada com um par de bancos de dados ou até milhares para uma replicação conveniente.
Versão paga com interface gráfica e excelente suporte.
Desvantagens do SymmetricDS
É necessário definir manualmente na linha de comando as regras e a direção da replicação através de operadores SQL para carregar tabelas de catálogo, o que pode ser inconveniente.
Configurar muitas tabelas para replicação pode ser cansativo se não forem usados scripts para criar operadores SQL que definem as regras e a direção da replicação.
Os logs registram uma quantidade excessiva de informações, e às vezes é necessário organizar o arquivo de log para que ele não ocupe muito espaço.
Resumo sobre o SymmetricDS
O SymmetricDS permite configurar replicação bidirecional entre dois, três ou até milhares de nós, para realizar replicação e sincronização de arquivos. É uma ferramenta única que executa muitas tarefas por conta própria, como a recuperação automática de dados após longos períodos de inatividade em um nó, troca de dados entre nós de forma segura e eficiente via HTTPS, gerenciamento automático de conflitos com base em um conjunto de regras, entre outros. O SymmetricDS realiza replicação entre quaisquer bancos de dados, por isso pode ser utilizado em diversos cenários, incluindo migrações, atualizações de versões, disseminação, filtragem e transformação de dados em diferentes plataformas.
Exemplo criado com base no do SymmetricDS. Em são detalhadamente descritos vários conceitos relacionados à configuração de replicação com o SymmetricDS.
Fonte: habr.com
