Una panoramica della replica incrociata di PostgreSQL e MySQL

Questo blog ha lo scopo di spiegare una panoramica della replica incrociata tra PostgreSQL e MySQL e discutere ulteriormente i metodi di configurazione della replica incrociata tra i due server di database. Tradizionalmente, i database coinvolti in una configurazione di replica incrociata sono chiamati database eterogenei, il che è un buon approccio per spostarsi da un server RDBMS a un altro.

Sia i database PostgreSQL che MySQL sono convenzionalmente database RDBMS, ma offrono anche funzionalità NoSQL con estensioni aggiuntive per avere il meglio di entrambi i mondi. Questo articolo si concentra sulla discussione sulla replica tra PostgreSQL e MySQL da una prospettiva RDBMS.

Una spiegazione esauriente sugli interni della replica non rientra nell'ambito di questo blog, tuttavia, alcuni elementi fondamentali devono essere discussi per fornire al pubblico una comprensione di come è configurata la replica tra server di database, vantaggi, limitazioni e forse alcuni casi d'uso noti.

In generale, la replica tra due server di database identici si ottiene in modalità binaria o in modalità query tra un nodo master (altrimenti chiamato editore, primario o attivo) e un nodo slave (sottoscrittore, standby o passivo). Lo scopo della replica è fornire una copia in tempo reale del database master sul lato slave, dove i dati vengono trasferiti da master a slave, formando così una configurazione attiva-passiva perché la replica è configurata per avvenire solo in un modo. D'altra parte, la replica tra due database può essere configurata in entrambi i modi in modo che i dati possano anche essere trasferiti dallo slave al master, stabilendo una configurazione attivo-attivo. Tutto questo può essere configurato tra due o più server di database identici che possono includere anche una replica a cascata. La configurazione di attivo-attivo o attivo-passivo dipende in realtà dalle esigenze aziendali, dalla disponibilità di tali funzionalità all'interno della configurazione nativa o dall'utilizzo di soluzioni esterne per la configurazione e dai compromessi applicabili.

La configurazione sopra menzionata può essere realizzata con diversi server di database, in cui un server di database può essere configurato per accettare dati replicati da un altro server di database completamente diverso e mantenere comunque un'istantanea in tempo reale dei dati da replicare. Sia i server di database MySQL che PostgreSQL offrono la maggior parte delle configurazioni discusse in precedenza o nella loro nascita o con l'aiuto di estensioni di terze parti, inclusi il metodo del registro binario, il metodo del blocco del disco, i metodi basati su istruzioni e righe.

L'esigenza di configurare una replica incrociata tra MySQL e PostgreSQL è in realtà il risultato di uno sforzo di migrazione una tantum per spostarsi da un server di database a un altro. Poiché entrambi i database utilizzano protocolli diversi, non possono parlare direttamente tra loro. Per ottenere quel flusso di comunicazione, esiste uno strumento open source esterno come pg_chameleon.

Sfondo di pg_chameleon

pg_chameleon è un sistema di replica da MySQL a PostgreSQL sviluppato in Python 3. Utilizza una libreria open source chiamata mysql-replication, anch'essa sviluppata utilizzando Python. La funzionalità prevede l'estrazione di immagini di riga di tabelle MySQL e la loro memorizzazione come oggetti JSONB in ​​un database PostgreSQL, che viene ulteriormente decodificato da una funzione pl/pgsql e la riproduzione di tali modifiche rispetto al database PostgreSQL.

Caratteristiche di pg_chameleon

• Più schemi MySQL dello stesso cluster possono essere replicati su un singolo database PostgreSQL di destinazione, formando una configurazione di replica molti-a-uno
• I nomi dello schema di origine e di destinazione possono essere non identici
• I dati di replica possono essere estratti dalla replica a cascata di MySQL
• Le tabelle che non riescono a replicare o generano errori sono escluse
• Ogni funzionalità di replica è gestita con l'aiuto di demoni
• Controllato con l'aiuto di parametri e file di configurazione basati sul costrutto YAML

Demo

Per cominciare, prepara il setup con tutti i prerequisiti necessari per installare pg_chameleon. In questa demo viene installato Python 3.6.8, creando un ambiente virtuale e attivandolo per l'uso.

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

Dopo una corretta installazione di Python3.6, sono soddisfatti ulteriori requisiti aggiuntivi come la creazione e l'attivazione di un ambiente virtuale. Oltre a quel modulo pip aggiornato all'ultima versione e viene utilizzato per installare pg_chameleon. Nei comandi seguenti, pg_chameleon 2.0.9 è stato deliberatamente installato mentre l'ultima versione è una 2.0.10. Questo viene fatto per evitare eventuali bug introdotti di recente nella versione aggiornata.

$> python3.6 -m venv venv
$> source venv/bin/activate
(venv) $> pip install pip --upgrade
(venv) $> pip install pg_chameleon==2.0.9

Il passaggio successivo consiste nell'invocare pg_chameleon (chameleon è il comando) con l'argomento set_configuration_files per consentire a pg_chameleon di creare directory e file di configurazione predefiniti.

(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

Ora, crea una copia di config-example.yml come default.yml per renderlo il file di configurazione predefinito. Di seguito viene fornito un file di configurazione di esempio utilizzato per questa demo.

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

Il file di configurazione utilizzato in questa demo è il file di esempio fornito con pg_chameleon con modifiche minori per adattarsi all'ambiente di origine e di destinazione e segue un riepilogo delle diverse sezioni del file di configurazione.

Il file di configurazione default.yml ha una sezione "impostazioni globali" che controlla dettagli come la posizione del file di blocco, le posizioni di registrazione e il periodo di conservazione, ecc. La sezione successiva è la sezione "override del tipo", che è un insieme di regole da ignorare tipi durante la replica. Per impostazione predefinita, viene utilizzata una regola di sostituzione del tipo di esempio che converte un tinyint(1) in un valore booleano. La sezione successiva è la sezione dei dettagli della connessione al database di destinazione che nel nostro caso è un database PostgreSQL, indicato con "pg_conn". La sezione finale è la sezione di origine che contiene tutti i dettagli delle impostazioni di connessione al database di origine, la mappatura dello schema tra origine e destinazione, tutte le tabelle da saltare, incluse le impostazioni di timeout, memoria e dimensione batch. Notare le "sorgenti" che indicano che possono esserci più origini in una singola destinazione per formare una configurazione di replica molti-a-uno.

In questa demo viene utilizzato un database "world_x" che è un database di esempio con 4 tabelle contenenti righe di esempio, che la comunità MySQL offre a scopo dimostrativo e può essere scaricato da qui. Il database di esempio viene fornito come archivio tar e compresso insieme alle istruzioni per crearlo e importare le righe in esso contenute.

Un utente dedicato viene creato in entrambi i database MySQL e PostgreSQL con lo stesso nome di usr_replica a cui vengono inoltre concessi privilegi aggiuntivi su MySQL per avere accesso in lettura a tutte le tabelle da replicare.

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;

Viene creato un database sul lato PostgreSQL che accetterà le modifiche dal database MySQL, chiamato "db_replica". L'utente "usr_replica" in PostgreSQL viene automaticamente configurato come proprietario di due schemi come "pgworld_x" e "sch_chameleon" che contengono rispettivamente le tabelle replicate effettive e le tabelle catalogo di replica. Questa configurazione automatica viene eseguita dall'argomento create_replica_schema, indicato più avanti.

postgres=# CREATE USER usr_replica WITH PASSWORD 'pass123';
CREATE ROLE
postgres=# CREATE DATABASE db_replica WITH OWNER usr_replica;
CREATE DATABASE

Il database MySQL è configurato con alcune modifiche ai parametri per prepararlo alla replica, come mostrato di seguito, e richiede il riavvio del server del database affinché le modifiche abbiano effetto.

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

A questo punto, è importante testare la connettività a entrambi i server di database per assicurarsi che non ci siano problemi durante l'esecuzione dei comandi pg_chameleon.

Sul nodo PostgreSQL:

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

Sul nodo MySQL:

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

I prossimi tre comandi di pg_chameleon (chameleon) sono dove imposta l'ambiente, aggiunge un'origine e inizializza una replica. L'argomento "create_replica_schema" di pg_chameleon crea lo schema predefinito (sch_chameleon) e lo schema di replica (pgworld_x) nel database PostgreSQL come è già stato discusso. L'argomento “add_source” aggiunge il database sorgente alla configurazione leggendo il file di configurazione (default.yml), che in questo caso è “mysql”, mentre “init_replica” inizializza la configurazione in base alle impostazioni del file di configurazione.

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

L'output dei tre comandi precedenti è autoesplicativo e indica il successo di ciascun comando con un messaggio di output evidente. Eventuali errori o errori di sintassi sono chiaramente indicati in messaggi semplici e chiari, suggerendo in tal modo e sollecitando azioni correttive.

Il passaggio finale consiste nell'iniziare la replica con "start_replica", il cui successo è indicato da un suggerimento di output come mostrato di seguito.

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

Lo stato della replica può essere interrogato con l'argomento "show_status" mentre gli errori possono essere visualizzati con l'argomento "show_errors".

$> chameleon show_status --source mysql  
OUTPUT: 
  Source id  Source name    Type    Status    Consistent    Read lag    Last read    Replay lag    Last replay
-----------  -------------  ------  --------  ------------  ----------  -----------  ------------  -------------
          1  mysql          mysql   running   No            N/A                      N/A

== Schema mappings ==
Origin schema    Destination schema
---------------  --------------------
world_x          pgworld_x

== Replica status ==
---------------------  ---
Tables not replicated  0
Tables replicated      4
All tables             4
Last maintenance       N/A
Next maintenance       N/A
Replayed rows
Replayed DDL
Skipped rows
---------------------  ---
$> chameleon show_errors --config default 
output: There are no errors in the log

Come discusso in precedenza, ciascuna delle funzionalità di replica è gestita con l'aiuto di daemon, che possono essere visualizzati interrogando la tabella dei processi utilizzando il comando "ps" di Linux, mostrato di seguito.

$>  ps -ef|grep chameleon
root       763     1  0 19:20 ?        00:00:00 /u01/media/mysql_samp_dbs/world_x-db/venv/bin/python3.6 /u01/media/mysq l_samp_dbs/world_x-db/venv/bin/chameleon start_replica --config default --source mysql
root       764   763  0 19:20 ?        00:00:01 /u01/media/mysql_samp_dbs/world_x-db/venv/bin/python3.6 /u01/media/mysq l_samp_dbs/world_x-db/venv/bin/chameleon start_replica --config default --source mysql
root       765   763  0 19:20 ?        00:00:00 /u01/media/mysql_samp_dbs/world_x-db/venv/bin/python3.6 /u01/media/mysq l_samp_dbs/world_x-db/venv/bin/chameleon start_replica --config default --source mysql

Nessuna configurazione della replica è completa finché non viene sottoposta al test di "applicazione in tempo reale", che è stato simulato come di seguito. Implica la creazione di una tabella e l'inserimento di un paio di record nel database MySQL, successivamente, l'argomento "sync_tables" di pg_chameleon viene invocato per aggiornare i demoni per replicare la tabella insieme ai suoi record nel database 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.

Il test viene confermato interrogando la tabella dal database PostgreSQL per riflettere le righe.

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

Se si tratta di un progetto di migrazione, i seguenti comandi pg_chameleon segneranno la fine dello sforzo di migrazione. I comandi devono essere eseguiti dopo che è stato confermato che le righe di tutte le tabelle di destinazione sono state replicate e il risultato sarà un database PostgreSQL migrato in modo pulito senza alcun riferimento al database di origine o allo schema di replica (sch_chameleon).

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

Facoltativamente, i seguenti comandi rilasceranno la configurazione di origine e lo schema di replica.

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

Prof dell'utilizzo di pg_chameleon

• Semplice da configurare e configurazione meno complicata
• Risoluzione dei problemi indolore e rilevamento delle anomalie con output di errore di facile comprensione
• È possibile aggiungere ulteriori tabelle ad hoc alla replica dopo l'inizializzazione, senza alterare nessun'altra configurazione
• È possibile configurare più origini per un unico database di destinazione, utile nei progetti di consolidamento per unire i dati da uno o più database MySQL in un unico database PostgreSQL
• Le tabelle selezionate possono essere ignorate dalla replica

Contro dell'utilizzo di pg_chameleon

• Supportato solo da MySQL 5.5 in poi come database di origine e PostgreSQL 9.5 in poi per il database di destinazione
• Richiede che ogni tabella disponga di una chiave primaria o univoca, altrimenti le tabelle vengono inizializzate durante il processo init_replica ma non riusciranno a replicarsi
• Replica unidirezionale, ovvero da MySQL a PostgreSQL. Limitando così il suo utilizzo solo a una configurazione attiva-passiva
• Il database sorgente può essere solo un database MySQL mentre il supporto per il database PostgreSQL come sorgente è sperimentale con ulteriori limitazioni (clicca qui per saperne di più)

Riepilogo pg_chameleon

L'approccio di replica offerto da pg_chameleon è favorevole a una migrazione del database di MySQL a PostgreSQL. Tuttavia, una delle limitazioni significative della replica unidirezionale può scoraggiare i professionisti del database ad adottarla per scopi diversi dalla migrazione. Questo inconveniente della replica unidirezionale può essere risolto utilizzando un altro strumento open source chiamato SymmetricDS.

Per studiare l'utilità più in dettaglio, fare riferimento alla documentazione ufficiale qui. Il riferimento alla riga di comando può essere ottenuto da qui.

Una panoramica di SymmetricDS

SymmetricDS è uno strumento open source in grado di replicare qualsiasi database su qualsiasi altro database, dal popolare elenco di server di database come Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird e altre istanze di database basate su cloud come Redshift e Azure, ecc. Alcune delle offerte includono la sincronizzazione di database e file, la replica multi-master, la sincronizzazione filtrata e la trasformazione. Lo strumento è sviluppato utilizzando Java, che richiede un'edizione standard (versione 8.0 o successiva) di JRE o JDK. La funzionalità prevede l'acquisizione delle modifiche ai dati da parte dei trigger nel database di origine e l'instradamento a un database di destinazione partecipante come batch in uscita

Caratteristiche di SymmetricDS

• Indipendente dalla piattaforma, il che significa che due o più database dissimili possono comunicare tra loro, qualsiasi database con qualsiasi altro database
• I database relazionali ottengono la sincronizzazione utilizzando l'acquisizione dei dati di modifica mentre i sistemi basati su file system utilizzano la sincronizzazione dei file
• Replica bidirezionale utilizzando il metodo Push and Pull, che viene eseguita in base a regole prestabilite
• Il trasferimento dei dati può avvenire anche su reti sicure e con larghezza di banda ridotta
• Ripristino automatico durante la ripresa di un nodo in crash e risoluzione automatica dei conflitti
• Pronto per il cloud e contiene potenti API di estensione

Demo

SymmetricDS può essere configurato in una delle due opzioni:

• Un nodo master (genitore) che funge da intermediario centralizzato che coordina la replica dei dati tra due nodi slave (figli), in cui la comunicazione tra i due nodi figli può avvenire solo tramite il genitore.
• Un nodo attivo (nodo1) può replicarsi da e verso un altro nodo attivo (nodo2) senza alcun intermediario.

In entrambe le opzioni, la comunicazione tra i nodi avviene tramite eventi “Push” e “Pull”. In questa demo verrà spiegata una configurazione attivo-attivo tra due nodi. L'intera architettura può essere esaustiva, quindi i lettori sono incoraggiati a consultare la guida per l'utente disponibile qui per saperne di più sugli interni di SymmetricDS.

L'installazione di SymmetricDS è semplice come scaricare la versione open source del file zip da qui ed estrarla in una posizione comoda. I dettagli del percorso di installazione e della versione di SymmetricDS in questa demo sono quelli della tabella seguente, insieme ad altri dettagli relativi alle versioni del database, alle versioni Linux, agli indirizzi IP e alla porta di comunicazione per entrambi i nodi partecipanti.

La home di installazione in questo caso è "/usr/local/symmetric-server-3.9.20" che sarà la home directory di SymmetricDS, che contiene varie altre sottodirectory e file. Due delle sottodirectory che ora sono importanti sono "campioni" e "motori". La directory samples contiene esempi di file di configurazione delle proprietà del nodo oltre a script SQL di esempio per avviare una rapida demo.

I seguenti tre file di configurazione delle proprietà dei nodi possono essere visualizzati nella directory "samples" con nomi che indicano la natura del nodo in una determinata configurazione.

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

Poiché SymmetricDS viene fornito con tutti i file di configurazione necessari per supportare una configurazione di base a 3 nodi (opzione 1), è conveniente utilizzare gli stessi file di configurazione anche per configurare una configurazione a 2 nodi (opzione 2). Il file di configurazione previsto viene copiato dalla directory "samples" in "engines" sull'host vm1 e appare come di seguito.

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

Il nome di questo nodo nella configurazione di SymmetricDS è "corp-000" con la connessione al database gestita con il driver mysql jdbc utilizzando la stringa di connessione come indicato sopra insieme alle credenziali di accesso. Il database da collegare è “replica_db” e le tabelle verranno create durante la creazione dello schema di esempio. Il "sync.url" indica la posizione in cui contattare il nodo per la sincronizzazione.

Il nodo 2 sull'host vm2 è configurato come "store-001" con il resto dei dettagli come configurato nel file node.properties, mostrato di seguito. Il nodo "store-001" esegue un database PostgreSQL, con "pgdb_replica" come database per la replica. Il "registration.url" consente all'host "vm2" di comunicare con l'host "vm1" per estrarre i dettagli di configurazione.

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

La demo predefinita preconfigurata di SymmetricDS contiene le impostazioni per configurare una replica bidirezionale tra due server di database (due nodi). I passaggi seguenti vengono eseguiti sull'host vm1 (corp-000), che creerà uno schema di esempio con 4 tabelle. Inoltre, l'esecuzione di "create-sym-tables" con il comando "symadmin" creerà le tabelle del catalogo che memorizzano e controllano le regole e la direzione della replica tra i nodi. Infine, le tabelle demo vengono caricate con dati di esempio.

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

Le tabelle demo "item" e "item_selling_price" sono configurate automaticamente per replicare da corp-000 a store-001 mentre le tabelle di vendita (sale_transaction e sale_return_line_item) sono autoconfigurate per replicare da store-001 a corp-000. Il passaggio successivo consiste nel creare lo schema di esempio nel database PostgreSQL sull'host vm2 (store-001), in modo da prepararlo a ricevere i dati da corp-000.

vm2$> cd /usr/local/symmetric-server-3.9.20/bin
vm2$> ./dbimport --engine store-001 --format XML create_sample.xml

In questa fase è importante verificare l'esistenza di tabelle demo e tabelle di catalogo SymmetricDS nel database MySQL su vm1. Nota, le tabelle di sistema SymmetricDS (tabelle con prefisso "sym_") sono disponibili solo nel nodo corp-000 in questo momento, perché è lì che è stato eseguito il comando "create-sym-tables", che sarà il posto per controllare e gestire la replica. In aggiunta a ciò, il database del nodo store-001 avrà solo 4 tabelle demo senza dati.

L'ambiente è ora pronto per avviare i processi del server "sym" su entrambi i nodi, come mostrato di seguito.

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

Le voci di registro vengono inviate sia a un file di registro in background (symmetric.log) in una directory dei registri nel percorso di installazione di SymmetricDS, sia all'output standard. Il server "sym" può ora essere avviato sul nodo store-001.

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

L'avvio del processo del server "sym" sull'host vm2 creerà anche le tabelle del catalogo SymmetricDS nel database PostgreSQL. L'avvio del processo del server "sym" su entrambi i nodi li farà coordinare tra loro per replicare i dati da corp-000 a store-001. Dopo alcuni secondi, interrogando tutte e quattro le tabelle su entrambi i lati verranno visualizzati i risultati della replica riuscita. In alternativa, un caricamento iniziale può anche essere inviato al nodo store-001 da corp-000 con il comando seguente.

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

A questo punto, un nuovo record viene inserito nella tabella "item" nel database MySQL al nodo corp-000 (host:vm1) e può essere verificato che sia stato replicato con successo nel database PostgreSQL al nodo store-001 (host:vm2 ). Questo mostra l'evento "Pull" dei dati da 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)

L'evento "Push" dei dati da store-001 a corp-000 può essere ottenuto inserendo un record nella tabella "transazione_vendita" e confermandone la replica.

pgdb_replica=# insert into "sale_transaction" ("tran_id", "store_id", "workstation", "day", "seq") values (1000, '001', '3', '2007-11-01', 100);
vm1$> [[email protected] ~]#  mysql -uroot -p'admin123' -D replica_db -e "select * from sale_transaction";
+---------+----------+-------------+------------+-----+
| tran_id | store_id | workstation | day        | seq |
+---------+----------+-------------+------------+-----+
|     900 | 001      | 3           | 2012-12-01 |  90 |
|    1000 | 001      | 3           | 2007-11-01 | 100 |
|    2000 | 002      | 2           | 2007-11-01 | 200 |
+---------+----------+-------------+------------+-----+

Questo segna la corretta configurazione della replica bidirezionale delle tabelle demo tra un database MySQL e PostgreSQL. Considerando che, la configurazione della replica per le tabelle utente appena create può essere ottenuta utilizzando i passaggi seguenti. Per la demo viene creata una tabella di esempio “t1” e si configurano le regole della sua replica secondo la procedura seguente. I passaggi configurano solo la replica da 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)

Successivamente, alla configurazione viene notificata la modifica dello schema relativa all'aggiunta di una nuova tabella richiamando il comando symadmin con l'argomento "sync-triggers" che ricreerà i trigger in modo che corrispondano alle definizioni della tabella. Successivamente, esegui "send-schema" per inviare le modifiche allo schema al nodo store-001, dopodiché la replica della tabella "t1" verrà configurata correttamente.

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

Profughi dell'utilizzo di SymmetricDS

• Installazione e configurazione semplici, incluso un set preconfigurato di file di parametri per creare una configurazione a 3 o 2 nodi
• Database multipiattaforma abilitato e indipendente dalla piattaforma, inclusi server, laptop e dispositivi mobili
• Replica qualsiasi database su qualsiasi altro database, sia on-premise, WAN o cloud
• In grado di gestire in modo ottimale da un paio di database a diverse migliaia di database per replicare i dati senza interruzioni
• Una versione commerciale del software offre una console di gestione basata su GUI con un eccellente pacchetto di supporto

Contro dell'utilizzo di SymmetricDS

• La configurazione manuale della riga di comando può comportare la definizione di regole e la direzione della replica tramite istruzioni SQL per caricare le tabelle del catalogo, il che potrebbe essere scomodo da gestire
• Impostare un numero elevato di tabelle per la replica sarà uno sforzo esauriente, a meno che non venga utilizzata una qualche forma di scripting per generare le istruzioni SQL che definiscono le regole e la direzione della replica
• Un sacco di informazioni di registrazione ingombrano il file di log, richiedendo quindi una manutenzione periodica del file di log per non consentire al file di log di riempire il disco

Riepilogo SymmetricDS

SymmetricDS offre la possibilità di impostare la replica bidirezionale tra 2 nodi, 3 nodi e così via per diverse migliaia di nodi per replicare i dati e ottenere la sincronizzazione dei file. È uno strumento unico che esegue molte delle attività di manutenzione autoriparante come il ripristino automatico dei dati dopo lunghi periodi di inattività in un nodo, la comunicazione sicura ed efficiente tra i nodi con l'aiuto di HTTPS e la gestione automatica dei conflitti basata su regole stabilite , etc. The essential feature of replicating any database to any other database makes SymmetricDS ready to be deployed for a number of use cases including migration, version and patch upgrade, distribution, filtering and transformation of data across diverse platforms.

The demo was created by referring to the official quick-start tutorial of SymmetricDS which can be accessed from here. The user guide can be found here, which provides a detailed account of various concepts involved in a SymmetricDS replication setup.