In questa panoramica parlerò della replica incrociata tra PostgreSQL e MySQL, oltre ai metodi per configurare la replica incrociata tra questi due server di database. Di solito, i database nella replica incrociata sono considerati omogenei, e questo è un modo conveniente per passare da un server di RDBMS a un altro.
I database PostgreSQL e MySQL sono comunemente considerati relazionali, ma con estensioni aggiuntive offrono funzionalità NoSQL. Qui discuteremo la replica tra PostgreSQL e MySQL dal punto di vista di RDBMS.
Non descriveremo tutti i dettagli tecnici, solo i principi di base, affinché possiate avere un'idea di come configurare la replica tra i server di database, i vantaggi, le limitazioni e i casi d'uso.
La replicazione tra due server di database identici avviene generalmente in modalità binaria o tramite richieste tra il nodo principale (noto anche come publisher, master o attivo) e il nodo secondario (abbonato, standby o passivo). L'obiettivo della replicazione è fornire in tempo reale una copia del database principale sul lato secondario. I dati vengono trasmessi dal nodo principale a quello secondario, ossia da attivo a passivo, poiché la replicazione avviene solo in una direzione. Tuttavia, è possibile configurare la replicazione tra due database in entrambe le direzioni, consentendo il trasferimento di dati dal secondario al principale in una configurazione "attivo-attivo". Tutto ciò, compresa la replicazione a cascata, è possibile tra due o più server di database identici. La configurazione "attivo-attivo" o "attivo-passivo" dipende dalle esigenze, dalla disponibilità delle funzionalità nella configurazione originale o dall'uso di soluzioni esterne per la configurazione e dai compromessi esistenti.
La configurazione descritta è possibile tra diversi server di database. Il server può essere configurato per ricevere dati replicati da un altro server di database, mantenendo nel contempo istantanee dei dati replicati in tempo reale. MySQL e PostgreSQL offrono la maggior parte di queste configurazioni autonomamente o tramite estensioni di terzi, inclusi i metodi di log binario, il blocco su disco e i metodi basati su operatori e righe.
La replicazione incrociata tra MySQL e PostgreSQL è necessaria per una migrazione una tantum da un server di database a un altro. Questi database utilizzano protocolli diversi, quindi non è possibile collegarli direttamente. Per stabilire uno scambio di dati, si può utilizzare uno strumento open source esterno, come pg_chameleon.
Cos'è pg_chameleon
pg_chameleon è un sistema di replicazione da MySQL a PostgreSQL basato su Python 3. Utilizza una libreria open source chiamata mysql-replication, anch'essa scritta in Python. Le righe vengono estratte dalle tabelle MySQL e salvate come oggetti JSONB nel database PostgreSQL, per essere poi decodificate tramite una funzione pl/pgsql e riprodotte nel database PostgreSQL.
Funzionalità di pg_chameleon
È possibile replicare diversi schemi MySQL da un cluster in un unico database PostgreSQL con una configurazione "uno a molti".
I nomi degli schemi di origine e di destinazione non possono coincidere.
I dati di replicazione possono essere estratti da una replica a cascata di MySQL.
Le tabelle che non possono essere replicate o che generano errori vengono escluse.
Ogni funzione di replica è gestita da demoni.
Controllo tramite parametri e file di configurazione basati su YAML.
Esempio
Host
vm1
vm2
Versione OS
CentOS Linux 7.6 x86_64
CentOS Linux 7.5 x86_64
Versione del server DB
MySQL 5.7.26
PostgreSQL 10.5
Porta DB
3306
5433
Indirizzo IP
192.168.56.102
192.168.56.106
Per iniziare, preparare tutti i componenti necessari per l'installazione di pg_chameleon. In questo esempio, è installato Python 3.6.8, che crea un ambiente virtuale e lo attiva.
$> 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 altinstallDopo aver installato con successo Python 3.6, è necessario soddisfare i requisiti rimanenti, ad esempio creare e attivare un ambiente virtuale. Inoltre, il modulo pip viene aggiornato all'ultima versione e utilizzato per installare pg_chameleon. Nei comandi qui sotto, si installa volutamente pg_chameleon 2.0.9, anche se l'ultima versione è 2.0.10. Questo è necessario per evitare nuovi bug nella versione aggiornata.
$> python3.6 -m venv venv
$> source venv/bin/activate
(venv) $> pip install pip --upgrade
(venv) $> pip install pg_chameleon==2.0.9Successivamente, chiamiamo pg_chameleon (chameleon è il comando) con l'argomento set_configuration_files, per abilitare pg_chameleon e creare le directory e i file di configurazione predefiniti.
(venv) $> chameleon set_configuration_files
creazione della directory /root/.pg_chameleon
creazione della directory /root/.pg_chameleon/configuration/
creazione della directory /root/.pg_chameleon/logs/
creazione della directory /root/.pg_chameleon/pid/
copiatura dell'esempio di configurazione in /root/.pg_chameleon/configuration/config-example.ymlOra creiamo una copia di config-example.yml come default.yml, in modo che diventi il file di configurazione predefinito. Di seguito è riportato un esempio del file di configurazione per questo esempio.
$> cat default.yml
---
#impostazioni globali
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 permette all'utente di sovrascrivere la conversione di tipo predefinita in un tipo diverso.
type_override:
"tinyint(1)":
override_to: boolean
override_tables:
- "*"
#connessione di destinazione 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 giorno'
copy_max_memory: "300M"
copy_mode: 'file'
out_dir: /tmp
sleep_loop: 1
on_error_replay: continue
on_error_read: continue
auto_maintenance: "disabilitato"
gtid_enable: No
type: mysql
skip_events:
insert:
- delphis_mediterranea.foo #salta gli inserimenti nella tabella delphis_mediterranea.foo
delete:
- delphis_mediterranea #salta le cancellazioni nello schema delphis_mediterranea
update:Il file di configurazione in questo esempio è un campione di file con pg_chameleon con lievi modifiche in base agli ambienti sorgente e di destinazione, e sotto è fornora una panoramica delle diverse sezioni del file di configurazione.
Nel file di configurazione default.yml si trova una sezione di impostazioni globali (global settings), dove è possibile gestire impostazioni come la posizione del file di blocco, la posizione dei log, il periodo di conservazione dei log, ecc. Successivamente, c'è una sezione di sovrascrittura dei tipi (type override), che specifica un insieme di regole per la sovrascrittura dei tipi durante la replica. Nell'esempio predefinito viene utilizzata una regola di sovrascrittura del tipo che converte tinyint(1) in un valore booleano. Nella sezione successiva, forniamo i dettagli di connessione al database di destinazione. Nel nostro caso, si tratta di un database PostgreSQL, indicato come pg_conn. Nell'ultima sezione, indichiamo i dati di origine, ovvero le impostazioni di connessione al database sorgente, lo schema di mapping tra i database sorgente e di destinazione, le tabelle da escludere, i tempi di attesa, la memoria, la dimensione del pacchetto. Si noti che 'sources' è indicato al plurale, il che significa che possiamo aggiungere più database sorgenti per uno solo di destinazione, configurando così una configurazione 'molti a uno'.
Il database world_x nell'esempio contiene 4 tabelle con righe che la comunità MySQL fornisce come esempio. Può essere scaricato. L'esempio del database è fornito in formato tar e come archivio compresso con istruzioni per la creazione e l'importazione delle righe.
Negli ambienti MySQL e PostgreSQL viene creato un utente speciale con lo stesso nome usr_replica. In MySQL, gli vengono concessi diritti aggiuntivi per leggere tutte le tabelle replicate.
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;Dalla parte di PostgreSQL viene creato un database db_replica, che riceverà le modifiche dal database MySQL. L'utente usr_replica in PostgreSQL è automaticamente configurato come proprietario di due schemi pgworld_x e sch_chameleon, che contengono rispettivamente le tabelle replicate reali e le tabelle con i cataloghi di replica. La configurazione automatica è gestita dall'argomento create_replica_schema, come vedrete di seguito.
postgres=# CREATE USER usr_replica WITH PASSWORD 'pass123';
CREATE ROLE
postgres=# CREATE DATABASE db_replica WITH OWNER usr_replica;
CREATE DATABASEIl database MySQL viene configurato con alcune modifiche ai parametri, per prepararlo alla replicazione, come mostrato di seguito. Sarà necessario riavviare il server dei database affinché le modifiche abbiano effetto.
$> vi /etc/my.cnf
binlog_format= ROW
binlog_row_image=FULL
log-bin = mysql-bin
server-id = 1È ora importante verificare la connessione a entrambi i server dei database, affinché durante l'esecuzione dei comandi pg_chameleon non ci siano problemi.
Sul nodo PostgreSQL:
$> mysql -u usr_replica -Ap'admin123' -h 192.168.56.102 -D world_xSul nodo MySQL:
$> psql -p 5433 -U usr_replica -h 192.168.56.106 db_replicaI seguenti tre comandi pg_chameleon (chameleon) preparano l'ambiente, aggiungono la sorgente e inizializzano la replica. L'argomento create_replica_schema in pg_chameleon crea lo schema predefinito (sch_chameleon) e lo schema di replicazione (pgworld_x) nel database PostgreSQL, come già accennato. L'argomento add_source aggiunge il database sorgente alla configurazione, leggendo il file di configurazione (default.yml), e nel nostro caso è mysql, mentre init_replica inizializza la configurazione in base ai parametri nel file di configurazione.
$> chameleon create_replica_schema --debug
$> chameleon add_source --config default --source mysql --debug
$> chameleon init_replica --config default --source mysql --debugL'output di questi tre comandi indica chiaramente la loro esecuzione con successo. Tutti i guasti o gli errori di sintassi vengono visualizzati in messaggi semplici e chiari con suggerimenti su come risolvere i problemi.
Infine, avviamo la replica utilizzando start_replica e riceviamo un messaggio di esecuzione riuscita.
$> chameleon start_replica --config default --source mysql
output: Avvio del processo di replica per la sorgente mysqlLo stato della replica può essere richiesto utilizzando l'argomento show_status e gli errori possono essere visualizzati con l'argomento show_errors.
Come già detto, ogni funzione di replica è gestita da demoni. Per visualizzarli, richiediamo la tabella dei processi con il comando Linux ps, come mostrato di seguito.
La replica non è considerata configurata finché non la testiamo in tempo reale, come mostrato di seguito. Creiamo una tabella, inseriamo un paio di record nel database MySQL e invochiamo l'argomento sync_tables in pg_chameleon per aggiornare i demoni e replicare la tabella con i 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
Il processo di sincronizzazione delle tabelle per la sorgente mysql è iniziato.Per confermare i risultati del test, richiediamo la tabella dal database PostgreSQL e visualizziamo le righe.
$> psql -p 5433 -U usr_replica -d db_replica -c "select * from pgworld_x.t1";
n1 | n2
----+-------
1 | uno
2 | dueSe stiamo eseguendo una migrazione, i seguenti comandi di pg_chameleon segneranno la sua conclusione. I comandi devono essere eseguiti dopo aver confermato che tutte le righe delle tabelle di destinazione siano state replicate, e il risultato sarà un database PostgreSQL accuratamente trasferito senza riferimenti al database sorgente o allo schema di replica (sch_chameleon).
$> chameleon stop_replica --config default --source mysql
$> chameleon detach_replica --config default --source mysql --debugFacoltativamente, con i seguenti comandi è possibile eliminare la configurazione sorgente e lo schema di replica.
$> chameleon drop_source --config default --source mysql --debug
$> chameleon drop_replica_schema --config default --source mysql --debugVantaggi di pg_chameleon
Configurazione e impostazione semplici.
Facile risoluzione dei problemi e identificazione delle anomalie con messaggi di errore chiari.
È possibile aggiungere tabelle speciali alla replica dopo l'inizializzazione, senza modificare il resto della configurazione.
È possibile configurare più database sorgente per uno obiettivo, il che è molto utile se si uniscono dati da uno o più database MySQL in un unico database PostgreSQL.
È possibile non replicare le tabelle selezionate.
Svantaggi di pg_chameleon
Supportato solo con MySQL 5.5 e versioni successive come sorgente e PostgreSQL 9.5 e versioni successive come database di destinazione.
Ogni tabella deve avere una chiave primaria o unica, altrimenti le tabelle vengono inizializzate durante il processo di init_replica, ma non vengono replicate.
La replicazione è unidirezionale — solo da MySQL a PostgreSQL. Pertanto, si adatta solo a uno schema "attivo-passivo".
La sorgente può essere solo un database MySQL, mentre il supporto per il database PostgreSQL come sorgente è solo sperimentale e con limitazioni (scopri di più )
Conclusioni su pg_chameleon
Il metodo di replica in pg_chameleon è eccellente per migrare un database da MySQL a PostgreSQL. Un notevole svantaggio è che la replica è unidirezionale, quindi gli specialisti di database probabilmente non vorranno utilizzarlo per altro, se non per la migrazione. Tuttavia, il problema della replicazione unidirezionale può essere risolto con un altro strumento open source — SymmetricDS.
Maggiore informazioni sono disponibili nella documentazione ufficiale . Puoi trovare la guida per la riga di comando .
Panoramica di SymmetricDS
SymmetricDS è uno strumento open source che replica qualsiasi database in un altro database comune, come Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird e altre istanze cloud di database, come Redshift e Azure, ecc. Funzioni disponibili: sincronizzazione di database e file, replica di più database primari, sincronizzazione filtrata, trasformazione e altro. È uno strumento basato su Java e richiede una release standard di JRE o JDK (versione 8.0 o superiore). Qui puoi registrare le modifiche ai dati tramite trigger nel database sorgente e indirizzarle nel corrispondente database di destinazione in pacchetti.
Funzionalità di SymmetricDS
Lo strumento è indipendente dalla piattaforma, il che significa che due o più database diversi possono scambiarsi dati.
I database relazionali sono sincronizzati mediante la registrazione delle modifiche ai dati, mentre i database basati su file utilizzano la sincronizzazione dei file.
Replica bidirezionale utilizzando metodi Push e Pull basati su un insieme di regole.
La trasmissione dei dati è possibile tramite reti sicure e reti con bassa capacità di trasmissione.
Ripristino automatico al riavvio dei nodi dopo un guasto e risoluzione automatica dei conflitti.
Compatibilità con il cloud e API di estensione efficienti.
Esempio
SymmetricDS può essere configurato in una delle due modalità:
Nodo principale (genitore) che coordina centralmente la replica dei dati tra due nodi secondari (figli), e lo scambio di dati tra i nodi secondari avviene esclusivamente tramite il nodo principale.
Un nodo attivo (nodo 1) può scambiare dati per la replica con un altro nodo attivo (nodo 2) senza intermediari.
In entrambe le configurazioni, lo scambio di dati avviene tramite Push e Pull. In questo esempio, esamineremo la configurazione "attivo-attivo". Descrivere l'intera architettura richiederebbe troppo tempo, quindi consulta , per saperne di più sul funzionamento di SymmetricDS.
Instalare SymmetricDS è molto semplice: scarica la versione open source del file zip. e estraila ovunque tu voglia. Nella tabella qui sotto sono riportate informazioni sul percorso di installazione e sulla versione di SymmetricDS in questo esempio, insieme alle versioni del database, versioni di Linux, indirizzi IP e porte per entrambi i nodi.
Host
vm1
vm2
Versione OS
CentOS Linux 7.6 x86_64
CentOS Linux 7.6 x86_64
Versione del server DB
MySQL 5.7.26
PostgreSQL 10.5
Porta DB
3306
5832
Indirizzo IP
192.168.1.107
192.168.1.112
Versione di SymmetricDS
SymmetricDS 3.9
SymmetricDS 3.9
Percorso di installazione di SymmetricDS
/usr/local/symmetric-server-3.9.20
/usr/local/symmetric-server-3.9.20
Nome del nodo SymmetricDS
corp-000
store-001
Qui stiamo installando SymmetricDS in /usr/local/symmetric-server-3.9.20, e qui saranno memorizzati diversi cataloghi e file annidati. Ci interessano i cataloghi annidati samples ed engines. Nel catalogo samples si trovano esempi di file di configurazione con le proprietà del nodo, insieme a esempi di script SQL per un rapido avvio della dimostrazione.
Nel catalogo samples vediamo tre file di configurazione con le proprietà del nodo — il nome indica la natura del nodo in uno schema specifico.
corp-000.properties
store-001.properties
store-002.propertiesIn SymmetricDS ci sono tutti i file di configurazione necessari per uno schema base di 3 nodi (opzione 1), e gli stessi file possono essere utilizzati per uno schema di 2 nodi (opzione 2). Copiamo il file di configurazione necessario dal catalogo samples nella directory engines sull'host vm1. Risulta così:
$> 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=000Questo nodo nella configurazione di SymmetricDS si chiama corp-000 e la connessione al database è gestita dal driver mysql jdbc, che utilizza la stringa di connessione fornita sopra e le credenziali di accesso. Ci connettiamo al database replica_db e durante la creazione dello schema verranno create le tabelle. sync.url mostra il punto di collegamento del nodo per la sincronizzazione.
Il nodo 2 sull'host vm2 è configurato come store-001, mentre il resto è specificato nel file node.properties, riportato di seguito. Il nodo store-001 esegue un database PostgreSQL, e pgdb_replica è il database per la replicazione. registration.url consente all'host vm2 di mettersi in contatto con l'host vm1 e ottenere i dettagli della 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=001Un esempio preconfigurato di SymmetricDS include parametri per configurare la replica bidirezionale tra due server di database (due nodi). I passaggi sottostanti vengono eseguiti sull'host vm1 (corp-000), che creerà un esempio di schema con 4 tabelle. Successivamente, l'esecuzione del comando create-sym-tables tramite symadmin crea le tabelle di catalogo, dove saranno memorizzate le regole e la direzione della replica tra i nodi. Infine, vengono caricati esempi di dati nelle tabelle.
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.sqlNell'esempio, le tabelle item e item_selling_price sono configurate automaticamente per la replica da corp-000 a store-001, mentre le tabelle sale (sale_transaction e sale_return_line_item) sono automaticamente configurate per la replica da store-001 a corp-000. Ora creiamo uno schema nel database PostgreSQL sull'host vm2 (store-001) per prepararlo a ricevere dati da corp-000.
vm2$> cd /usr/local/symmetric-server-3.9.20/bin
vm2$> ./dbimport --engine store-001 --format XML create_sample.xmlVerifichiamo che nel database MySQL su vm1 siano presenti esempi di tabelle e tabelle di catalogo di SymmetricDS. Nota che le tabelle di sistema di SymmetricDS (con prefisso sym_) sono attualmente disponibili solo sul nodo corp-000, poiché lì abbiamo eseguito il comando create-sym-tables e gestiremo la replica. Inoltre, nel database sul nodo store-001 ci saranno solo 4 tabelle di esempio senza dati.
Tutto. L'ambiente è pronto per avviare i processi 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 registrazioni dei log vengono inviate nel file del log in background (symmetric.log) nella cartella dei log nel percorso di installazione di SymmetricDS, così come nell'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 &Se si avvia il processo server sym su host vm2, verranno create anche le tabelle di catalogo di SymmetricDS nel database PostgreSQL. Se si avvia il processo server sym su entrambi i nodi, si coordineranno tra loro per replicare i dati da corp-000 a store-001. Se dopo alcuni secondi richiediamo tutte e 4 le tabelle su entrambi i lati, vedremo che la replicazione è avvenuta con successo. In alternativa, si può inviare un caricamento iniziale al nodo store-001 da corp-000 con il seguente comando.
vm1$> ./symadmin --engine corp-000 reload-node 001A questo punto, una nuova registrazione viene inserita nella tabella item nel database MySQL sul nodo corp-000 (host: vm1), e si può verificare la sua replicazione nel database PostgreSQL sul nodo store-001 (host: vm2). Viene visualizzata un'operazione Pull per spostare i 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)Per eseguire un'operazione Push per spostare i dati da store-001 a corp-000, inseriamo una registrazione nella tabella sale_transaction e verifichiamo che la replicazione sia avvenuta.
Vediamo una configurazione riuscita della replica bidirezionale di una tabella di esempio tra i database MySQL e PostgreSQL. Per configurare la replica per nuove tabelle utente, seguiamo questi passaggi. Creiamo una tabella t1 per l'esempio e configuriamo le regole di replica nel seguente modo. Così impostiamo 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, la configurazione riceve una notifica di modifica dello schema, ossia l'aggiunta di una nuova tabella, tramite il comando symadmin con l'argomento sync-triggers, che ricrea i trigger per allineare le definizioni delle tabelle. Viene eseguito il send-schema per inviare le modifiche dello schema al nodo store-001, e la replica della tabella t1 è configurata.
vm1$> ./symadmin -e corp-000 --node=001 sync-triggers
vm1$> ./symadmin send-schema -e corp-000 --node=001 t1Vantaggi di SymmetricDS
Installazione e configurazione semplici, inclusi un insieme pronto di file con parametri per creare schemi con tre o due nodi.
Cross-platform database compatibility e indipendenza dalla piattaforma, inclusi server, laptop e dispositivi mobili.
Replica di qualsiasi database in un altro database localmente, in WAN o nel cloud.
Capacità di gestire ottimamente da un paio a diverse migliaia di database per una replica comoda.
Versione a pagamento con interfaccia grafica e supporto eccellente.
Svantaggi di SymmetricDS
È necessario definire manualmente nella riga di comando le regole e la direzione della replica tramite operatori SQL per il caricamento delle tabelle di catalogo, il che può risultare scomodo.
Configurare molte tabelle per la replica può diventare stancante se non si utilizzano script per creare operatori SQL che definiscono le regole e la direzione della replica.
Viene registrata troppe informazioni nei log, e a volte è necessario sistemare il file di log affinché non occupi troppo spazio.
Conclusioni su SymmetricDS
SymmetricDS consente di configurare la replica bidirezionale tra due, tre o addirittura migliaia di nodi per eseguire la replica e sincronizzare i file. Questo strumento unico svolge autonomamente molte funzioni, come il ripristino automatico dei dati dopo una lunga inattività di un nodo, lo scambio di dati protetto ed efficiente tra i nodi tramite HTTPS, la gestione automatica dei conflitti basata su un insieme di regole, e così via. SymmetricDS esegue la replica tra qualsiasi database, rendendolo utilizzabile per i più diversi scenari, tra cui migrazione, aggiornamento, distribuzione, filtraggio e trasformazione dei dati su diverse piattaforme.
Esempio creato basato sulla guida ufficiale per SymmetricDS. Nel vengono descritti dettagliatamente vari concetti legati alla configurazione della replica tramite SymmetricDS.
Fonte: habr.com
