In generale, parlerò della replica incrociata tra PostgreSQL e MySQL, e anche dei metodi di configurazione della replica incrociata tra questi due server di database. Di solito i database in replica incrociata sono chiamati omogenei, ed è un metodo conveniente per passare da un server di un RDBMS a un altro.
I database PostgreSQL e MySQL sono comunemente considerati relazionali, ma con estensioni aggiuntive offrono funzionalità NoSQL. Qui discuteremo della replica tra PostgreSQL e MySQL, dal punto di vista dei RDBMS.
Non descriveremo tutta la cucina interna, solo i principi di base, affinché possiate avere un'idea della configurazione della replica tra i server di database, dei vantaggi, dei limiti e degli scenari d'uso.
Di solito, la replica tra due server di database identici avviene sia in modalità binaria che tramite richieste tra il nodo principale (il publisher, principale o attivo) e il nodo secondario (sottoscrittore, in attesa o passivo). L'obiettivo della replica è fornire in tempo reale una copia del database principale sul lato secondario. I dati vengono trasferiti dal principale al secondario, ovvero dall'attivo al passivo, poiché la replica avviene solo in una direzione. Tuttavia, è possibile configurare la replica tra due database in entrambe le direzioni, affinché i dati vengano trasferiti dal secondario al principale in una configurazione
La configurazione descritta è possibile tra server di database diversi. Un server può essere configurato per ricevere dati replicati da un altro server di database e nel contempo mantenere istantanee dei dati replicati in tempo reale. MySQL e PostgreSQL offrono la maggior parte di queste configurazioni autonomamente o tramite estensioni di terze parti, comprese le metodologie di registro binario, di blocco del disco e metodi basati su operatori e righe.
La replica incrociata tra MySQL e PostgreSQL è necessaria per una migrazione unica da un server di database a un altro. Questi database utilizzano protocolli diversi, quindi non è possibile collegarli direttamente. Per stabilire uno scambio di dati, è possibile utilizzare uno strumento open source esterno, come pg_chameleon.
Cos'è pg_chameleon
pg_chameleon è un sistema di replica da MySQL a PostgreSQL scritto in Python 3. Utilizza una libreria open source, mysql-replication, anch'essa in Python. Le immagini delle righe vengono estratte dalle tabelle MySQL e salvate come oggetti JSONB nel database PostgreSQL, per poi essere decodificate dalla funzione pl/pgsql e riprodotte nel database PostgreSQL.
Funzionalità di pg_chameleon
È possibile replicare più schemi MySQL da un cluster a un singolo database PostgreSQL con una configurazione 'uno a molti'.
I nomi degli schemi di origine e di destinazione non possono coincidere.
I dati di replica possono essere estratti da una replica 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 del sistema operativo
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, prepara tutti i componenti necessari per installare pg_chameleon. In questo esempio, è installato Python 3.6.8, che crea e attiva un ambiente virtuale.
$> 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 restanti, ad esempio creando e attivando un ambiente virtuale. Inoltre, il modulo pip viene aggiornato all'ultima versione e utilizzato per installare pg_chameleon. Nei comandi seguenti, si installa esplicitamente 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.9Quindi chiamiamo pg_chameleon (chameleon è il comando) con l'argomento set_configuration_files, per abilitare pg_chameleon e creare le cartelle e i 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/
copiando il file di configurazione di esempio in /root/.pg_chameleon/configuration//config-example.ymlOra stiamo creando una copia di config-example.yml come default.yml, affinché diventi il file di configurazione predefinito. Un modello di file di configurazione per questo esempio è fornito di seguito.
$> 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 consente all'utente di sovrascrivere la conversione del tipo predefinito in uno 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 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 #salta gli insert sulla tabella delphis_mediterranea.foo
delete:
- delphis_mediterranea #salta i delete sullo schema delphis_mediterranea
update:Il file di configurazione in questo esempio è un modello di file per pg_chameleon con lievi modifiche in base agli ambienti sorgente e di destinazione, e di seguito è fornita una panoramica delle diverse sezioni del file di configurazione.
Nel file di configurazione default.yml è presente 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. Segue una sezione di sovrascrittura dei tipi (type override), dove sono indicati un insieme di regole per sovrascrivere i tipi durante la replica. Nell'esempio predefinito viene utilizzata una regola di sovrascrittura del tipo che trasforma tinyint(1) in un valore booleano. Nella sezione successiva indichiamo i dettagli di connessione al database di destinazione. Nel nostro caso si tratta di un database PostgreSQL, designato come pg_conn. Nell'ultima sezione indichiamo i dati della sorgente, ovvero i parametri di connessione del database sorgente, lo schema di mappatura tra i database sorgente e di destinazione, le tabelle da saltare, il timeout, la memoria, la dimensione del pacchetto. Nota che "sources" è indicato al plurale, il che significa che possiamo aggiungere più database sorgente per uno solo di destinazione, per configurare una configurazione "molti a uno".
Il database world_x nell'esempio contiene 4 tabelle con righe che la comunità MySQL offre come esempio. Può essere scaricato . L'esempio del database è fornito come tar e in un archivio compresso con istruzioni su come creare e importare le righe.
Nei database MySQL e PostgreSQL viene creato un utente speciale con lo stesso nome usr_replica. In MySQL gli vengono concessi diritti aggiuntivi per la lettura di 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;Sul lato PostgreSQL viene creato un database db_replica, che accetterà le modifiche dal database MySQL. L'utente usr_replica in PostgreSQL viene automaticamente configurato come proprietario di due schemi pgworld_x e sch_chameleon, che contengono rispettivamente le tabelle replicate effettive 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 modifiche a alcuni parametri per prepararlo alla replica, 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 = 1Adesso è importante controllare la connessione a entrambi i server di database, in modo che durante l'esecuzione dei comandi pg_chameleon non si verifichino 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 fonte e inizializzano la replica. L'argomento create_replica_schema in pg_chameleon crea lo schema predefinito (sch_chameleon) e lo schema di replica (pgworld_x) nel database PostgreSQL, come abbiamo già detto. L'argomento add_source aggiunge il database sorgente alla configurazione leggendo il file di configurazione (default.yml), e nel nostro caso si tratta di 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 --debugI risultati di queste tre squadre indicano chiaramente il loro successo. Tutti i guasti o errori di sintassi vengono riportati in messaggi semplici e comprensibili con suggerimenti per risolvere i problemi.
Infine, iniziamo la replica utilizzando start_replica e riceviamo un messaggio di esecuzione corretta.
$> 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 replicazione è 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 chiamiamo 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 righe interessate (0.01 sec)
mysql> insert into t1 values (1,'one');
Query OK, 1 riga interessata (0.00 sec)
mysql> insert into t1 values (2,'two');
Query OK, 1 riga interessata (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 | one
2 | twoSe stiamo eseguendo una migrazione, i seguenti comandi pg_chameleon la concluderanno. I comandi devono essere eseguiti dopo aver verificato che tutte le righe di tutte le tabelle di destinazione siano state replicate, e il risultato sarà un database PostgreSQL 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 rimuovere 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 ulteriori tabelle speciali alla replica dopo l'inizializzazione, senza modificare il resto della configurazione.
È possibile configurare più database sorgente per un unico obiettivo, il che è molto comodo se si stanno unendo dati da uno o più database MySQL in un unico database PostgreSQL.
È possibile non replicare le tabelle selezionate.
Svantaggi di pg_chameleon
È supportato solo da MySQL 5.5 e versioni superiori come sorgente e PostgreSQL 9.5 e versioni superiori come database di destinazione.
Ogni tabella deve avere una chiave primaria o unica, altrimenti le tabelle vengono inizializzate durante il processo init_replica, ma non vengono replicate.
La replica unidirezionale è possibile solo da MySQL a PostgreSQL. Pertanto, è adeguata solo per uno schema "attivo-passivo".
Il database sorgente può essere solo MySQL, mentre il supporto del database PostgreSQL come sorgente è solo esperimentale e con limitazioni (scopri di più )
Riepiloghi su pg_chameleon
Il metodo di replica in pg_chameleon è ottimale per la migrazione di database da MySQL a PostgreSQL. Un grosso svantaggio è che la replica è solo unidirezionale, quindi i database specialisti difficilmente lo vorranno utilizzare per qualcos'altro che non sia la migrazione. Tuttavia, il problema della replica unidirezionale può essere risolto con un altro strumento open source: SymmetricDS.
Leggi di più nella documentazione ufficiale . La guida per la riga di comando può essere trovata .
Panoramica di SymmetricDS
SymmetricDS è uno strumento open source che replica qualsiasi database in un altro database comune: Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird e altri esempi di database cloud, come Redshift, Azure, ecc. Le funzionalità disponibili includono: sincronizzazione di database e file, replica di più database principali, sincronizzazione filtrata, trasformazione e altro. È uno strumento basato su Java e richiede una versione standard di JRE o JDK (versioni 8.0 o superiori). Qui è possibile registrare le modifiche ai dati tramite trigger nel database sorgente e indirizzarle al database di destinazione corrispondente in pacchetti.
Funzionalità di SymmetricDS
Lo strumento è indipendente dalla piattaforma, il che significa che due o più database diversi possono scambiare dati.
I database relazionali vengono sincronizzati tramite 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 su reti sicure e su reti con bassa capacità di banda.
Ripristino automatico al riavvio dei nodi dopo un guasto e risoluzione automatica dei conflitti.
Compatibilità con il cloud ed API per estensioni efficienti.
Esempio
SymmetricDS può essere configurato in una delle due varianti:
Nodo principale (genitore) che coordina centralmente la replica dei dati tra due nodi secondari (figli), con uno scambio di dati tra nodi secondari che avviene solo attraverso il nodo genitore.
Un nodo attivo (nodo 1) può scambiare dati per la replica con un altro nodo attivo (nodo 2) senza intermediari.
In entrambe le varianti, lo scambio di dati avviene tramite Push e Pull. In questo esempio esamineremo la configurazione "attivo-attivo". Descrivere l'intera architettura richiede troppo tempo, quindi esamina , per saperne di più sul funzionamento di SymmetricDS.
Installare SymmetricDS è molto semplice: scarica la versione open source del file zip e estraila dove desideri. Nella tabella sottostante sono riportate informazioni sul percorso di installazione e sulla versione di SymmetricDS in questo esempio, oltre alle versioni dei database, versioni di Linux, indirizzi IP e porte per entrambi i nodi.
Host
vm1
vm2
Versione del sistema operativo
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 verranno memorizzati diversi cataloghi e file annidati. Ci interessano i cataloghi annidati samples e engines. Nella cartella samples si trovano esempi di file di configurazione con le proprietà del nodo, oltre ad esempi di script SQL per cominciare rapidamente la dimostrazione.
Nella cartella samples vediamo tre file di configurazione con le proprietà del nodo — il nome indica la funzione del nodo in un determinato schema.
corp-000.properties
store-001.properties
store-002.propertiesIn SymmetricDS ci sono tutti i file di configurazione necessari per uno schema di 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 dalla cartella samples nella cartella engines sull'host vm1. Risultato:
$> 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 sopra indicata e le credenziali di accesso. Ci connettiamo al database replica_db e durante la creazione dello schema verranno create le tabelle. sync.url indica il luogo di connessione con il 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, mentre pgdb_replica è il database per la replicazione. registration.url consente all'host vm2 di collegarsi all'host vm1 e di ricevere da esso 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=001Un esempio completo di SymmetricDS include parametri per la configurazione della replicazione bidirezionale tra due server di database (due nodi). I seguenti passaggi vengono eseguiti sull'host vm1 (corp-000), il quale creerà un esempio di schema con 4 tabelle. Quindi, l'esecuzione di create-sym-tables tramite il comando symadmin crea le tabelle del catalogo, dove verranno memorizzate le regole e la direzione della replicazione tra i nodi. Infine, i dati di esempio vengono caricati 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 automaticamente configurate per la replicazione da corp-000 a store-001, mentre le tabelle sale (sale_transaction e sale_return_line_item) sono automaticamente configurate per la replicazione 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.xmlControlliamo attentamente che nel database MySQL su vm1 siano presenti esempi di tabelle e tabelle del catalogo di SymmetricDS. Si noti che le tabelle di sistema di SymmetricDS (con il prefisso sym_) sono attualmente disponibili solo sul nodo corp-000, perché lì abbiamo eseguito il comando create-sym-tables e gestiremo la replicazione. 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 indicato di seguito.
vm1$> cd /usr/local/symmetric-server-3.9.20/bin
vm1$> sym 2>&1 &I log delle registrazioni vengono inviati al file di log in background (symmetric.log) nella cartella dei log nella directory in cui è installato SymmetricDS, nonché nei dati di 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 del server sym sull'host vm2, verranno create le tabelle del catalogo SymmetricDS anche nel database PostgreSQL. Se si avvia il processo del server sym su entrambi i nodi, essi si coordineranno tra loro per replicare i dati da corp-000 a store-001. Se dopo alcuni secondi richiediamo tutte e quattro le tabelle su entrambi i lati, vedremo che la replicazione è stata eseguita con successo. In alternativa, possiamo inviare il 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 del database MySQL sul nodo corp-000 (host: vm1) e si può controllare la sua replicazione nel database PostgreSQL sul nodo store-001 (host: vm2). Vediamo l'operazione Pull per trasferire 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 l'operazione Push per trasferire i dati da store-001 a corp-000, inseriamo una registrazione nella tabella sale_transaction e verifichiamo che la replicazione sia stata completata.
Vediamo la configurazione riuscita della replicazione bidirezionale delle tabelle di esempio tra i database MySQL e PostgreSQL. Per configurare la replicazione per le nuove tabelle utente, eseguiamo le seguenti operazioni. Creiamo una tabella t1 come esempio e configuriamo le regole di replicazione nel modo seguente. In questo modo, impostiamo solo la replicazione 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)Quindi, la configurazione riceve una notifica sulla modifica dello schema, cioè l'aggiunta di una nuova tabella, utilizzando il comando symadmin con l'argomento sync-triggers, che ricrea i trigger per abbinare le definizioni delle tabelle. Viene eseguita la send-schema per inviare le modifiche dello schema al nodo store-001, e la replicazione 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, compreso un set di file predefiniti con parametri per creare uno schema con tre o due nodi.
Cross-platform delle basi di dati e indipendenza dalla piattaforma, inclusi server, laptop e dispositivi mobili.
Replicazione di qualsiasi base di dati in un'altra base di dati localmente, in WAN o nel cloud.
Possibilità di gestire in modo ottimale una coppia di basi di dati o diverse migliaia per una replicazione comoda.
Versione a pagamento con interfaccia grafica e ottimo supporto.
Svantaggi di SymmetricDS
È necessario definire manualmente nella riga di comando le regole e la direzione della replicazione tramite gli operatori SQL per il caricamento delle tabelle catalogo, il che può risultare scomodo.
Configurare molte tabelle per la replicazione può essere faticoso, se non si utilizzano script per creare gli operatori SQL che definiscono le regole e la direzione della replicazione.
Nei log viene registrata troppa informazione e a volte è necessario sistemare il file di log per evitare che occupi troppo spazio.
Conclusioni su SymmetricDS
SymmetricDS consente di configurare la replicazione bidirezionale tra due, tre e persino diverse migliaia di nodi per effettuare la replicazione e sincronizzare file. Si tratta di uno strumento unico che svolge autonomamente molte attività, come il ripristino automatico dei dati dopo un lungo downtime su un nodo, uno scambio dati protetto ed efficiente tra nodi tramite HTTPS, e una gestione automatica dei conflitti sulla base di un set di regole, ecc. SymmetricDS esegue la replicazione tra qualsiasi database, quindi può essere utilizzato per i più svariati scenari, inclusa la migrazione, l'aggiornamento a una nuova versione, la distribuzione, la filtrazione e la trasformazione dei dati su diverse piattaforme.
L'esempio è stato creato sulla base della su SymmetricDS. In Viene descritto in dettaglio vari concetti legati alla configurazione della replicazione utilizzando SymmetricDS.
Fonte: habr.com
