Illustrerò la replica incrociata tra PostgreSQL e MySQL, nonché i metodi per impostare la replica incrociata tra i due server di database. In genere, i database con replica incrociata sono detti omogenei e rappresentano un metodo conveniente per spostarsi da un server RDBMS a un altro.
I database PostgreSQL e MySQL sono generalmente considerati relazionali, ma con estensioni aggiuntive offrono funzionalità NoSQL. Qui discuteremo della replica tra PostgreSQL e MySQL dal punto di vista del DBMS relazionale.
Non descriveremo l'intero funzionamento interno, ma solo i principi di base in modo da darti un'idea della configurazione della replica tra server di database, vantaggi, limitazioni e casi d'uso.
In genere, la replica tra due server di database identici viene eseguita in modalità binaria o utilizzando query tra un master (ovvero editore, master o attivo) e uno slave (abbonato, standby o passivo). Lo scopo della replica è fornire una copia in tempo reale del database master sul lato slave. In questo caso i dati vengono trasferiti dal master allo slave, cioè dall'attivo al passivo, perché la replica viene eseguita solo in una direzione. Ma è possibile impostare la replica tra due database in entrambe le direzioni, in modo che i dati vengano trasferiti dallo slave al master in una configurazione attivo-attivo. Tutto ciò, inclusa la replica a cascata, è possibile tra due o più server di database identici. La configurazione attivo-attivo o attivo-passivo dipende dalle necessità, dalla disponibilità di tali funzionalità nella configurazione iniziale o dall'uso di soluzioni di configurazione esterne e dai compromessi esistenti.
La configurazione descritta è possibile tra diversi server di database. Il server può essere configurato per accettare dati replicati da un altro server database e mantenere comunque istantanee in tempo reale dei dati replicati. MySQL e PostgreSQL offrono la maggior parte di queste configurazioni internamente o tramite estensioni di terze parti, inclusi metodi di log binario, blocco del disco e metodi basati su istruzioni e righe.
La replica 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 lo scambio di dati, è possibile utilizzare uno strumento open source esterno, ad esempio pg_chameleon.
Cos'è pg_chameleon
pg_chameleon è un sistema di replica da MySQL a PostgreSQL in Python 3. Utilizza la libreria open source mysql-replication, anch'essa in Python. Le immagini delle righe vengono estratte dalle tabelle MySQL e archiviate come oggetti JSONB nel database PostgreSQL, quindi decrittografate dalla funzione pl/pgsql e riprodotte nel database PostgreSQL.
Caratteristiche di pg_chameleon
È possibile replicare più schemi MySQL dallo stesso cluster su un singolo database PostgreSQL di destinazione in una configurazione uno-a-molti
I nomi dello schema di origine e di destinazione non possono essere gli stessi.
I dati di replica possono essere recuperati da una replica MySQL in cascata.
Sono escluse le tabelle che non possono replicarsi o produrre errori.
Ogni funzione di replica è controllata dai demoni.
Controllo tramite parametri basati su YAML e file di configurazione.
esempio
ospite
vm1
vm2
Versione del sistema operativo
CentOSLinux 7.6x86_64
CentOSLinux 7.5x86_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. Questo esempio installa Python 3.6.8, che crea e attiva l'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 Python3.6, è necessario completare i requisiti rimanenti, come la creazione e l'attivazione di un ambiente virtuale. Inoltre, il modulo pip viene aggiornato all'ultima versione e utilizzato per installare pg_chameleon. I comandi seguenti installano intenzionalmente pg_chameleon 2.0.9, sebbene l'ultima versione sia la 2.0.10. Ciò è 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 è un comando) con l'argomento set_configuration_files per abilitare pg_chameleon e 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.ymlOra creiamo una copia di config-example.yml come default.yml in modo che diventi il file di configurazione predefinito. Di seguito viene fornito un file di configurazione di esempio per questo esempio.
$> 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 in questo esempio è un file pg_chameleon di esempio con piccole modifiche per adattarsi agli ambienti di origine e di destinazione e di seguito è riportata una panoramica delle diverse sezioni del file di configurazione.
Nel file di configurazione default.yml è presente una sezione delle impostazioni globali, in cui è possibile gestire impostazioni come la posizione del file di blocco, la posizione dei log, il periodo di archiviazione per i log, ecc. Segue la sezione di override del tipo, dove un insieme di regole per sovrascrivere i tipi durante la replica. L'esempio utilizza per impostazione predefinita una regola di override del tipo che converte tinyint(1) in un valore booleano. Nella sezione successiva specifichiamo i dettagli della connessione al database di destinazione. Nel nostro caso, si tratta di un database PostgreSQL, designato pg_conn. Nell'ultima sezione indichiamo i dati di origine, ovvero i parametri di connessione del database di origine, lo schema di mappatura tra il database di origine e quello di destinazione, le tabelle che devono essere saltate, il tempo di attesa, la memoria, la dimensione del pacchetto. Tieni presente che "sorgenti" è plurale, il che significa che possiamo aggiungere più database di origine a un singolo database di destinazione per impostare una configurazione molti-a-uno.
Il database di esempio world_x contiene 4 tabelle con righe che la comunità MySQL offre come esempi. Può essere scaricato . Il database di esempio viene fornito come archivio tar e compresso con istruzioni per la creazione e l'importazione di righe.
Nei database MySQL e PostgreSQL viene creato un utente speciale con lo stesso nome usr_replica. In MySQL vengono concessi diritti di lettura aggiuntivi a 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 della directory di replica. L'argomento create_replica_schema è responsabile della configurazione automatica, come vedrai 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 è configurato con alcune modifiche ai parametri per prepararlo alla replica, come mostrato di seguito. Sarà necessario riavviare il 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 = 1Ora è importante verificare la connessione ad entrambi i server del database in modo 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_xSul nodo MySQL:
$> psql -p 5433 -U usr_replica -h 192.168.56.106 db_replicaI successivi tre comandi pg_chameleon (chameleon) preparano l'ambiente, aggiungono il sorgente e inizializzano la replica. L'argomento create_replica_schema di pg_chameleon crea uno schema predefinito (sch_chameleon) e uno schema di replica (pgworld_x) nel database PostgreSQL, come abbiamo già discusso. L'argomento add_source aggiunge un database sorgente alla configurazione leggendo il file di configurazione (default.yml), e nel nostro caso è mysql, e 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 che sono stati eseguiti con successo. Eventuali arresti anomali o errori di sintassi vengono segnalati in messaggi semplici e chiari con suggerimenti su come risolvere il problema.
Infine, avviamo la replica utilizzando start_replica e riceviamo un messaggio di successo.
$> chameleon start_replica --config default --source mysql
output: Starting the replica process for source mysqlLo stato della replica può essere interrogato utilizzando l'argomento show_status e gli errori possono essere visualizzati utilizzando l'argomento show_errors.
Come abbiamo già detto, ogni funzione di replica è controllata da demoni. Per visualizzarli, interroghiamo la tabella dei processi con il comando Linux ps, come mostrato di seguito.
La replica non viene 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 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.Per confermare i risultati del test, interroghiamo la tabella dal database PostgreSQL e restituiamo 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 ne metteranno fine. I comandi devono essere eseguiti dopo essere sicuri che le righe di tutte le tabelle di destinazione siano state replicate e il risultato sarà un database PostgreSQL accuratamente migrato senza riferimenti 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 --debugSe lo si desidera, è possibile utilizzare i seguenti comandi per eliminare la configurazione originale 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
Facile installazione e configurazione.
Risolvi facilmente i problemi e identifica le 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 di origine per un singolo database di destinazione e ciò è molto utile se si combinano dati da uno o più database MySQL in un singolo database PostgreSQL.
Non è necessario replicare le tabelle selezionate.
Svantaggi di pg_chameleon
Supportato solo con MySQL 5.5 e versioni successive come origine e PostgreSQL 9.5 e versioni successive come database di destinazione.
Ogni tabella deve avere una chiave primaria o univoca, altrimenti le tabelle vengono inizializzate durante il processo init_replica ma non vengono replicate.
Replica unidirezionale: solo da MySQL a PostgreSQL. Pertanto è adatto solo per il circuito “attivo-passivo”.
L'origine può essere solo un database MySQL e il supporto per un database PostgreSQL come origine è solo sperimentale e con limitazioni (ulteriori informazioni )
Risultati per pg_chameleon
Il metodo di replica in pg_chameleon è ottimo per migrare un database da MySQL a PostgreSQL. Lo svantaggio significativo è che la replica è solo unidirezionale, quindi è improbabile che i professionisti dei database vogliano utilizzarla per qualcosa di diverso dalla migrazione. Ma il problema della replica unidirezionale può essere risolto con un altro strumento open source: SymmetricDS.
Maggiori informazioni nella documentazione ufficiale . È possibile trovare la guida della riga di comando .
Panoramica di SymmetricDS
SymmetricDS è uno strumento open source che replica qualsiasi database su qualsiasi altro database comune: Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird e altre istanze di database cloud, ad esempio Redshift e Azure, ecc. Funzionalità disponibili: sincronizzazione di database e file, replica di database multi-master, sincronizzazione filtrata, trasformazione e altre. Questo è uno strumento Java e richiede una versione standard di JRE o JDK (versione 8.0 o successiva). Qui le modifiche dei dati ai trigger nel database di origine possono essere registrate e inviate al database di destinazione appropriato sotto forma di batch.
Funzionalità DS simmetriche
Lo strumento è indipendente dalla piattaforma, il che significa che due o più database diversi possono scambiarsi dati.
I database relazionali vengono sincronizzati utilizzando i record di modifica dei dati, mentre i database basati su file system utilizzano la sincronizzazione dei file.
Replica bidirezionale utilizzando metodi Push e Pull basati su un insieme di regole.
Il trasferimento dei dati è possibile su reti sicure e con larghezza di banda ridotta.
Ripristino automatico quando i nodi riprendono il funzionamento dopo un errore e risoluzione automatica dei conflitti.
API di estensione potenti e compatibili con il cloud.
esempio
SymmetricDS può essere configurato in due modi:
Un nodo master (genitore) che coordina centralmente la replica dei dati tra due nodi slave (figlio) e la comunicazione tra i nodi figli avviene solo attraverso il nodo genitore.
Un nodo attivo (Nodo 1) può comunicare per la replica con un altro nodo attivo (Nodo 2) senza intermediari.
In entrambe le opzioni lo scambio dati avviene tramite Push and Pull. In questo esempio considereremo una configurazione attivo-attivo. Ci vorrebbe troppo tempo per descrivere l'intera architettura, quindi fai la tua ricerca. per saperne di più sul dispositivo SymmetricDS.
Installare SymmetricDS è molto semplice: scarica la versione open source del file zip e portalo fuori dove vuoi. La tabella seguente fornisce informazioni sul percorso di installazione e sulla versione di SymmetricDS in questo esempio, nonché sulle versioni del database, sulle versioni Linux, sugli indirizzi IP e sulle porte per entrambi i nodi.
ospite
vm1
vm2
Versione del sistema operativo
CentOSLinux 7.6x86_64
CentOSLinux 7.6x86_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 DS simmetrica
Simmetrico DS 3.9
Simmetrico DS 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
negozio-001
Qui installiamo SymmetricDS in /usr/local/symmetric-server-3.9.20 e varie sottodirectory e file verranno archiviati lì. Siamo interessati alle sottodirectory dei campioni e dei motori. La directory degli esempi contiene file di configurazione di esempio con proprietà del nodo, nonché script SQL di esempio per iniziare rapidamente.
Nella directory degli esempi vediamo tre file di configurazione con le proprietà del nodo: il nome mostra la natura del nodo in un determinato schema.
corp-000.properties
store-001.properties
store-002.propertiesSymmetricDS dispone di tutti i file di configurazione necessari per una progettazione di base a 3 nodi (opzione 1) e gli stessi file possono essere utilizzati per una progettazione a 2 nodi (opzione 2). Copia il file di configurazione richiesto dalla directory degli esempi sui motori 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 SymmetricDS si chiama corp-000 e la connessione al database è gestita dal driver mysql jdbc, che utilizza la stringa di connessione sopra e le credenziali di accesso. Ci colleghiamo al database replica_db e le tabelle verranno create durante la creazione dello schema. sync.url mostra dove contattare il nodo per la sincronizzazione.
Il nodo 2 sull'host VM2 è configurato come store-001 e il resto è specificato nel file node.properties riportato di seguito. Il nodo store-001 esegue il database PostgreSQL e pgdb_replica è il database di replica. Registration.url consente all'host VM2 di contattare l'host VM1 e 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=001L'esempio SymmetricDS completato contiene parametri per l'impostazione della 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. Quindi l'esecuzione di create-sym-tables con il comando symadmin crea tabelle di directory in cui verranno archiviate le regole e la direzione della replica 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 vengono configurate automaticamente per la replica da corp-000 a store-001 e le tabelle di vendita (sale_transaction e sale_return_line_item) vengono configurate automaticamente 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.xmlAssicurati di controllare che il database MySQL su VM1 disponga di tabelle di esempio e tabelle del catalogo SymmetricDS. Tieni presente che le tabelle di sistema SymmetricDS (con prefisso sym_) sono attualmente disponibili solo sul nodo corp-000 perché è lì che abbiamo eseguito il comando create-sym-tables e gestiremo la replica. E nel database sul nodo store-001 ci saranno solo 4 tabelle di esempio senza dati.
Tutto. L'ambiente è pronto per eseguire 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 a un file di registro in background (symmetric.log) nella cartella logs nella directory in cui è installato SymmetricDS, nonché 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 &Se esegui il processo del server sym sull'host VM2, creerà anche le tabelle del catalogo SymmetricDS nel database PostgreSQL. Se esegui il processo del server Sym su entrambi i nodi, si coordinano tra loro per replicare i dati da corp-000 a store-001. Se dopo qualche secondo interroghiamo tutte e 4 le tabelle su entrambi i lati, vedremo che la replica ha avuto successo. Oppure puoi inviare il bootstrap al nodo store-001 da corp-000 con il seguente comando.
vm1$> ./symadmin --engine corp-000 reload-node 001A questo punto, un nuovo record viene inserito nella tabella degli elementi nel database MySQL sul nodo corp-000 (host: vm1) ed è possibile verificarne la replica nel database PostgreSQL sul nodo store-001 (host: vm2). Vediamo 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 un record nella tabella sale_transaction e verifichiamo che la replica abbia esito positivo.
Vediamo la corretta configurazione della replica bidirezionale delle tabelle di esempio tra i database MySQL e PostgreSQL. Per impostare la replica per le nuove tabelle utente, attenersi alla seguente procedura: Creiamo ad esempio la tabella t1 e configuriamo le sue regole di replica come segue. In questo modo configuriamo 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)Alla configurazione viene quindi notificata la modifica dello schema, ovvero l'aggiunta di una nuova tabella, utilizzando il comando symadmin con l'argomento sync-triggers, che ricrea i trigger per mappare le definizioni della tabella. send-schema viene eseguito per inviare le modifiche dello schema al nodo store-001 e viene configurata la replica della tabella t1.
vm1$> ./symadmin -e corp-000 --node=001 sync-triggers
vm1$> ./symadmin send-schema -e corp-000 --node=001 t1Vantaggi di SymmetricDS
Facile installazione e configurazione, incluso un set di file già pronto con parametri per la creazione di un circuito a tre o due nodi.
Database multipiattaforma e indipendenza dalla piattaforma, inclusi server, laptop e dispositivi mobili.
Replica qualsiasi database su qualsiasi altro database localmente, sulla WAN o nel cloud.
Possibilità di lavoro ottimale con un paio di database o diverse migliaia per una comoda replica.
Versione a pagamento con GUI e supporto eccellente.
Svantaggi di SymmetricDS
È necessario definire manualmente le regole e la direzione della replica sulla riga di comando tramite istruzioni SQL per caricare le tabelle del catalogo, il che può risultare scomodo.
L'impostazione di molte tabelle per la replica può essere noiosa a meno che non si utilizzino script per creare istruzioni SQL che definiscono le regole e la direzione della replica.
Ci sono troppe informazioni registrate nei registri e talvolta è necessario riordinare il file di registro in modo che non occupi troppo spazio.
Risultati per SymmetricDS
SymmetricDS consente di impostare la replica bidirezionale tra due, tre o anche diverse migliaia di nodi per replicare e sincronizzare i file. Si tratta di uno strumento unico che esegue in modo indipendente molte attività, come il ripristino automatico dei dati dopo un lungo periodo di inattività su un nodo, lo scambio di dati sicuro ed efficiente tra nodi tramite HTTPS, la gestione automatica dei conflitti basata su una serie di regole, ecc. SymmetricDS esegue la replica tra qualsiasi database, pertanto, può essere utilizzata per un'ampia varietà di scenari, tra cui migrazione, migrazione, distribuzione, filtraggio e trasformazione dei dati su piattaforme.
L'esempio è basato sul funzionario di SymmetricDS. IN Descrive in dettaglio i vari concetti coinvolti nella configurazione della replica con SymmetricDS.
Fonte: habr.com