Descreverei a replicação cruzada entre o PostgreSQL e o MySQL, bem como os métodos para configurar a replicação cruzada entre esses dois servidores de banco de dados. Normalmente, os bancos de dados de replicação cruzada são chamados homogêneos e esse é um método conveniente de mover de um servidor de banco de dados relacional para outro.
Os bancos de dados PostgreSQL e MySQL são considerados relacionais, mas com extensões adicionais, eles oferecem recursos NoSQL. Aqui discutiremos a replicação entre o PostgreSQL e o MySQL, em termos de DBMS relacional.
Não descreveremos toda a cozinha interna, apenas os princípios básicos, para que você tenha uma idéia de como configurar a replicação entre servidores de banco de dados, as vantagens, limitações e cenários de uso.
Normalmente, a replicação entre dois servidores de banco de dados idênticos é realizada no modo binário ou através de solicitações entre o nó principal (é o publicador, mestre ou ativo) e o escravo (assinante, pendente 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 do mestre para o escravo, ou seja, do ativo para o passivo, porque 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 na configuração ativo-ativo. Tudo isso, incluindo a replicação em cascata, possivelmente entre dois ou mais servidores de banco de dados idênticos.A configuração ativo-ativo ou passivo-ativo depende da necessidade, da disponibilidade de tais recursos na configuração inicial ou do uso de soluções de configuração externas e trade-offs existentes. .
A configuração descrita é possível entre diferentes servidores de banco de dados. O servidor pode ser configurado para receber dados replicados de outro servidor de banco de dados e ainda salvar instantâneos em tempo real dos dados replicados. O MySQL e o PostgreSQL oferecem a maioria dessas configurações por conta própria ou com extensões de terceiros, incluindo métodos de log binário, bloqueios de disco e métodos baseados em instruções e strings.
A replicação cruzada entre MySQL e PostgreSQL é necessária para uma única migração de um servidor de banco de dados para outro. Esses bancos de dados usam protocolos diferentes, portanto não podem ser conectados 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
O pg_chameleon é um sistema de replicação do MySQL para o PostgreSQL no Python 3. Ele usa a biblioteca de código aberto mysql-replication, também no Python. As imagens de sequência são extraídas das tabelas MySQL e armazenadas como objetos JSONB no banco de dados PostgreSQL, e depois descriptografadas pela função pl / pgsql e reproduzidas no banco de dados PostgreSQL.
Recursos de Pg_chameleon
Vários esquemas MySQL do mesmo cluster podem ser replicados no mesmo banco de dados de destino do PostgreSQL com uma configuração um para muitos
Os nomes dos esquemas de origem e destino não podem corresponder.
Os dados de replicação podem ser recuperados de uma réplica do MySQL em cascata.
Tabelas que não podem replicar ou gerar erros são excluídas.
Cada função de replicação é controlada por daemons.
Controle usando parâmetros e arquivos de configuração com base no YAML.
Exemplo
Para começar, prepare todos os componentes necessários para instalar o pg_chameleon. Neste exemplo, o Python 3.6.8 está instalado, o 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 altinstall
Após a instalação bem-sucedida do Python3.6, você precisa atender aos outros requisitos, por exemplo, 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. Nos comandos abaixo, o pg_chameleon 2.0.9 é intencionalmente instalado, embora a versão mais recente seja 2.0.10. Isso é necessário para evitar novos erros 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.9
Em 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.yml
Agora criamos uma cópia do 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 é mostrado 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 de amostra com pg_chameleon com pequenas alterações de acordo com os ambientes de origem e de destino, e a seguir é apresentada 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 configurações globais onde é possível controlar configurações como o local do arquivo de bloqueio, o local dos logs, o período de armazenamento dos logs etc. A próxima seção é a seção de substituição de tipo, onde o conjunto é especificado regras para substituir tipos durante a replicação. O exemplo padrão usa uma regra de redefinição de tipo que converte tinyint (1) em um valor booleano. Na próxima seção, indicamos os detalhes da conexão com o banco de dados de destino. No nosso caso, este é um banco de dados PostgreSQL designado como 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 dos bancos de dados de origem e de destino, as tabelas a serem ignoradas, tempo limite, memória, tamanho do pacote. Observe que “origens” é indicado no plural, ou seja, podemos adicionar vários bancos de dados de origem para o mesmo destino para definir a configuração muitos-para-um.
O banco de dados world_x no exemplo contém 4 tabelas com linhas que a comunidade MySQL oferece para o exemplo. Pode ser baixado aqui . O banco de dados de amostra vem na forma de tar e um arquivo compactado com instruções para criar e importar seqüências de caracteres.
Um usuário especial é criado nos bancos de dados MySQL e PostgreSQL com o mesmo nome usr_replica. No MySQL, ele recebe 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, o banco de dados db_replica é criado, o que aceita alterações no banco de dados MySQL. O usuário usr_replica do PostgreSQL é configurado automaticamente como o proprietário dos dois esquemas pgworld_x e sch_chameleon que contêm tabelas replicadas reais e tabelas com diretórios de replicação, respectivamente. O argumento create_replica_schema é responsável pela configuração automática, como você verá abaixo.
postgres=# CREATE USER usr_replica WITH PASSWORD 'pass123'; CREATE ROLE postgres=# CREATE DATABASE db_replica WITH OWNER usr_replica; CREATE DATABASE
O banco de dados MySQL está configurado com algumas alterações para prepará-lo para replicação, como mostrado abaixo. Você precisará reiniciar o servidor de banco de dados 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 = 1
Agora é importante verificar a conexão com os dois servidores de banco de dados para que não haja problemas ao executar comandos pg_chameleon.
No nó PostgreSQL:
$> mysql -u usr_replica -Ap'admin123' -h 192.168.56.102 -D world_x
No nó MySQL:
$> psql -p 5433 -U usr_replica -h 192.168.56.106 db_replica
Os três comandos a seguir pg_chameleon (chameleon) preparam o ambiente, adicionam a fonte e inicializam a réplica. O argumento create_replica_schema em pg_chameleon cria o esquema padrão (sch_chameleon) e o esquema de replicação (pgworld_x) no banco de dados PostgreSQL, como já dissemos. O argumento add_source adiciona o banco de dados original à 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 no arquivo de configuração.
$> chameleon create_replica_schema --debug $> chameleon add_source --config default --source mysql --debug $> chameleon init_replica --config default --source mysql --debug
A saída desses três comandos obviamente indica sua execução bem-sucedida. Todas as falhas ou erros de sintaxe são indicadas em mensagens simples e claras com dicas de solução de problemas.
Por fim, inicie a replicação com start_replica e receba uma mensagem de sucesso.
$> chameleon start_replica --config default --source mysql output: Starting the replica process for source mysql
O status da replicação pode ser solicitado usando o argumento show_status, e os erros podem ser visualizados usando o argumento show_errors.
Resultado.
Como dissemos antes, cada função de replicação é controlada por daemons. Para visualizá-los, consultamos a tabela de processos com o comando ps do Linux, como mostrado abaixo.
Resultado.
A replicação não é considerada configurada até testá-la em tempo real, como 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 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 Sync tables process for source mysql started.
Para confirmar os resultados do teste, consultamos a tabela no 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 | two
Se realizarmos a migração, os seguintes comandos pg_chameleon serão o seu fim. 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 perfeitamente migrado sem referência ao banco de dados ou esquema de replicação original (sch_chameleon).
$> chameleon stop_replica --config default --source mysql $> chameleon detach_replica --config default --source mysql --debug
Se desejado, os seguintes comandos podem remover o esquema original de configuração e replicação.
$> chameleon drop_source --config default --source mysql --debug $> chameleon drop_replica_schema --config default --source mysql --debug
Benefícios de pg_chameleon
Fácil instalação e configuração.
Solução de problemas conveniente e detecção de anomalias com claras mensagens de erro.
Você pode adicionar tabelas especiais adicionais à replicação após a inicialização sem alterar o restante da configuração.
Você pode configurar vários bancos de dados de origem para um destino, e isso é muito conveniente se você combinar dados de um ou vários bancos de dados MySQL em um banco de dados PostgreSQL.
Você não pode replicar tabelas selecionadas.
Desvantagens do pg_chameleon
Suportado apenas com o MySQL 5.5 e superior como fonte e o 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 são inicializadas no processo init_replica, mas não são replicadas.
Replicação unidirecional - somente do MySQL para o PostgreSQL. Portanto, é adequado apenas para o esquema ativo-passivo.
Somente o banco de dados MySQL pode ser a fonte, e o suporte ao banco de dados PostgreSQL, pois a fonte é apenas experimental e com limitações (saiba mais aqui )
Resultados Pg_chameleon
O método de replicação no pg_chameleon é ótimo para migrar um banco de dados do MySQL para o PostgreSQL. Um ponto negativo significativo é que a replicação é apenas unidirecional; portanto, é improvável que os especialistas em banco de dados desejem usá-la para outra coisa que não a migração. Mas o problema da replicação unidirecional pode ser resolvido por outra ferramenta de código aberto - o SymmetricDS.
Leia mais na documentação oficial aqui . Ajuda na linha de comando pode ser encontrada aqui .
Visão geral do SymmetricDS
O 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. Funções disponíveis: sincronização de bancos de dados e arquivos, replicação de vários bancos de dados líderes, sincronização filtrada, conversão e outros. Esta é uma ferramenta Java e requer uma liberação padrão do JRE ou JDK (versão 8.0 ou superior). Aqui você pode registrar alterações de dados em gatilhos no banco de dados de origem e enviá-las ao banco de dados de destino correspondente na forma de pacotes.
Recursos do SymmetricDS
A ferramenta é independente da plataforma, ou seja, dois ou mais bancos de dados diferentes podem trocar dados.
Os bancos de dados relacionais são sincronizados escrevendo alterações de dados e os bancos de dados baseados no sistema de arquivos usam a sincronização de arquivos.
Replicação bidirecional usando os métodos Push and Pull com base em um conjunto de regras.
A transmissão de dados é possível através de redes seguras e redes com baixa largura de banda.
Recuperação automática quando os nós são retomados após uma falha e resolução automática de conflitos.
APIs de extensão poderosas e compatíveis com a nuvem.
Exemplo
O SymmetricDS pode ser configurado de duas maneiras:
Um nó principal (pai) que coordena centralmente a replicação de dados entre dois nós escravos (filhos) e a troca de dados entre nós filhos é realizada apenas através do pai.
O nó ativo (nó 1) pode trocar dados para replicação com outro nó ativo (nó 2) sem um intermediário.
Nos dois casos, os dados são trocados usando Push e Pull. Neste exemplo, veremos a configuração ativo-ativo. Descreva a arquitetura inteira por muito tempo. Confira o guia para saber mais sobre o SymmetricDS.
A instalação do SymmetricDS é muito simples: baixe a versão de código aberto do arquivo zip daqui e extraia-a onde quiser. A tabela abaixo fornece informações sobre o local da instalação e a versão do SymmetricDS neste exemplo, bem como versões de banco de dados, versões do Linux, endereços IP e portas para os dois nós.
Aqui instalamos o SymmetricDS em /usr/local/symmetric-server-3.9.20, e diferentes subdiretórios e arquivos serão armazenados ali. Estamos interessados nos exemplos e nos mecanismos de diretórios aninhados. O diretório de amostras contém arquivos de configuração de amostra com propriedades do host, bem como scripts SQL de amostra para iniciar rapidamente a demonstração.
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 esquema específico.
corp-000.properties store-001.properties store-002.properties
O SymmetricDS possui todos os arquivos de configuração necessários para um esquema base de 3 nós (opção 1) e os mesmos arquivos podem ser usados para um esquema de 2 nós (opção 2). Copie o arquivo de configuração desejado 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=000
Esse nó na configuração do SymmetricDS é chamado corp-000 e a conexão com o banco de dados é processada pelo driver mysql jdbc, que usa a cadeia de conexão especificada 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 site de comunicaçã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 para replicação. registration.url permite que o host vm2 entre em contato com o host vm1 e obtenha 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=001
O exemplo pré-criado do SymmetricDS contém opções 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órios nas quais regras e direção de replicação entre nós serão armazenadas. Por fim, 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.sql
No exemplo, as tabelas item e item_selling_price são configuradas automaticamente para replicar de corp-000 para store-001, e as tabelas de venda (sale_transaction e sale_return_line_item) são configuradas automaticamente para replicar da store-001 para corp-000. Agora crie o esquema no banco de dados PostgreSQL no host vm2 (store-001) para prepará-lo para receber dados do corp-000.
vm2$> cd /usr/local/symmetric-server-3.9.20/bin vm2$> ./dbimport --engine store-001 --format XML create_sample.xml
Certifique-se de verificar se o banco de dados MySQL na vm1 possui tabelas de amostra e tabelas de diretório SymmetricDS. Observe que as tabelas do sistema SymmetricDS (com o prefixo sym_) agora estão disponíveis apenas no host corp-000, porque executamos o comando create-sym-tables e gerenciamos a replicação. E no banco de dados no nó store-001, haverá apenas 4 tabelas de exemplo sem dados.
Só isso. O ambiente está pronto para executar processos do servidor sym nos dois nós, como mostrado abaixo.
vm1$> cd /usr/local/symmetric-server-3.9.20/bin vm1$> sym 2>&1 &
As entradas de log são enviadas para o arquivo de log em segundo plano (symmetric.log) na pasta de log no diretório em que 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 criará as tabelas de catálogos SymmetricDS no banco de dados PostgreSQL. Se você executar o processo do servidor sym nos dois nós, eles se coordenarão entre si para replicar dados de corp-000 para store-001. Se, após alguns segundos, consultarmos todas as 4 tabelas dos dois lados, veremos que a replicação foi bem-sucedida. Ou você pode enviar o bootstrap para store-001 de corp-000 com o seguinte comando.
vm1$> ./symadmin --engine corp-000 reload-node 001
Nesse ponto, um novo registro é inserido na tabela de itens no banco de dados MySQL no host corp-000 (host: vm1) e você pode verificar sua replicação no banco de dados PostgreSQL no host 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 executar uma operação Push para mover dados do store-001 para corp-000, insira um registro na tabela sale_transaction e verifique se a replicação está concluída.
Resultado.
Vemos a configuração bem-sucedida da replicação bidirecional de tabelas de amostra entre os bancos de dados MySQL e PostgreSQL. Para configurar a replicação para novas tabelas de usuários, faça o seguinte: Criamos a tabela t1 como exemplo e configuramos as regras para sua replicação da seguinte maneira. Portanto, apenas configuramos 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 de uma alteração no esquema, ou seja, a adição de uma nova tabela, usando o comando symadmin com o argumento sync-triggers, que recria os gatilhos para corresponder às definições da tabela. O esquema de envio é executado para enviar as 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 t1
Benefícios do SymmetricDS
Fácil instalação e configuração, incluindo um conjunto de arquivos prontos com parâmetros para criar um circuito com três ou dois nós.
Bancos de dados entre plataformas e independência de plataforma, incluindo servidores, laptops e dispositivos móveis.
Replicar qualquer banco de dados para qualquer outro banco de dados localmente, em uma WAN ou na nuvem.
A capacidade de trabalhar de maneira ideal com alguns bancos de dados ou vários milhares para facilitar a replicação.
Versão paga com interface gráfica e excelente suporte.
Desvantagens do SymmetricDS
É necessário determinar manualmente as regras e a direção da replicação por meio das instruções SQL na linha de comandos para carregar tabelas de diretório, o que é inconveniente.
A configuração de muitas tabelas para replicação pode ser entediante se você não usar scripts para criar instruções SQL que definem as regras e a direção da replicação.
Muita informação é inserida nos logs e, às vezes, você precisa limpar o arquivo de log para que ele não ocupe muito espaço.
Resumo do SymmetricDS
O SymmetricDS permite configurar a replicação bidirecional entre dois, três ou até vários milhares de nós para replicar e sincronizar arquivos. Essa é uma ferramenta exclusiva que executa independentemente muitas tarefas, por exemplo, recuperação automática de dados após um longo tempo 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. O SymmetricDS replica entre todos os bancos de dados, portanto, ele pode ser usado para uma variedade de cenários, incluindo migração, atualização, distribuição, filtragem e conversão de dados entre plataformas.
A amostra é baseada no Guia de início rápido oficial do SymmetricDS. O guia do usuário detalha vários conceitos relacionados à configuração da replicação usando o SymmetricDS.