{"id":38146,"date":"2019-10-31T22:21:54","date_gmt":"2019-10-31T19:21:54","guid":{"rendered":"https:\/\/prohoster.info\/blog\/perekrestnaya-replikatsiya-mezhdu-postgresql-i-mysql\/"},"modified":"2019-10-31T22:21:54","modified_gmt":"2019-10-31T19:21:54","slug":"perekrestnaya-replikatsiya-mezhdu-postgresql-i-mysql","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/perekrestnaya-replikatsiya-mezhdu-postgresql-i-mysql","title":{"rendered":"Replica incrociata tra PostgreSQL e MySQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Replica<\/p>\n

<\/p>\n

In generale, parler\u00f2 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 \u00e8 un metodo conveniente per passare da un server di un RDBMS a un altro.<\/p>\n

<\/p>\n

I database PostgreSQL e MySQL sono comunemente considerati relazionali, ma con estensioni aggiuntive offrono funzionalit\u00e0 NoSQL. Qui discuteremo della replica tra PostgreSQL e MySQL, dal punto di vista dei RDBMS.<\/p>\n

<\/p>\n

Non descriveremo tutta la cucina interna, solo i principi di base, affinch\u00e9 possiate avere un'idea della configurazione della replica tra i server di database, dei vantaggi, dei limiti e degli scenari d'uso.<\/p>\n

<\/a><\/noindex><\/p>\n

Di solito, la replica tra due server di database identici avviene sia in modalit\u00e0 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 \u00e8 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\u00e9 la replica avviene solo in una direzione. Tuttavia, \u00e8 possibile configurare la replica tra due database in entrambe le direzioni, affinch\u00e9 i dati vengano trasferiti dal secondario al principale in una configurazione<\/p>\n

<\/p>\n

La configurazione descritta \u00e8 possibile tra server di database diversi. Un server pu\u00f2 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.<\/p>\n

<\/p>\n

La replica incrociata tra MySQL e PostgreSQL \u00e8 necessaria per una migrazione unica da un server di database a un altro. Questi database utilizzano protocolli diversi, quindi non \u00e8 possibile collegarli direttamente. Per stabilire uno scambio di dati, \u00e8 possibile utilizzare uno strumento open source esterno, come pg_chameleon.<\/p>\n

<\/p>\n

Cos'\u00e8 pg_chameleon<\/h3>\n

<\/p>\n

pg_chameleon \u00e8 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.<\/p>\n

<\/p>\n

Funzionalit\u00e0 di pg_chameleon<\/h3>\n

<\/p>\n

\u00c8 possibile replicare pi\u00f9 schemi MySQL da un cluster a un singolo database PostgreSQL con una configurazione 'uno a molti'.
\nI nomi degli schemi di origine e di destinazione non possono coincidere.
\nI dati di replica possono essere estratti da una replica cascata di MySQL.
\nLe tabelle che non possono essere replicate o che generano errori vengono escluse.
\nOgni funzione di replica \u00e8 gestita da demoni.
\nControllo tramite parametri e file di configurazione basati su YAML.<\/p>\n

<\/p>\n

Esempio<\/h3>\n

<\/p>\n

Host
\nvm1
\nvm2<\/p>\n

Versione del sistema operativo<\/strong>
\nCentOS Linux 7.6 x86_64
\nCentOS Linux 7.5 x86_64<\/p>\n

Versione del server DB<\/strong>
\nMySQL 5.7.26
\nPostgreSQL 10.5<\/p>\n

Porta DB<\/strong>
\n3306
\n5433<\/p>\n

indirizzo IP<\/strong>
\n192.168.56.102
\n192.168.56.106<\/p>\n

<\/p>\n

Per iniziare, prepara tutti i componenti necessari per installare pg_chameleon. In questo esempio, \u00e8 installato Python 3.6.8, che crea e attiva un ambiente virtuale.<\/p>\n

<\/p>\n

$> wget https:\/\/www.python.org\/ftp\/python\/3.6.8\/Python-3.6.8.tar.xz\n$> tar -xJf Python-3.6.8.tar.xz\n$> cd Python-3.6.8\n$> .\/configure --enable-optimizations\n$> make altinstall<\/code><\/pre>\n
<\/p>\n
Dopo aver installato con successo Python 3.6, \u00e8 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 \u00e8 2.0.10. Questo \u00e8 necessario per evitare nuovi bug nella versione aggiornata.<\/p>\n
<\/p>\n
$> python3.6 -m venv venv\n$> source venv\/bin\/activate\n(venv) $> pip install pip --upgrade\n(venv) $> pip install pg_chameleon==2.0.9<\/code><\/pre>\n
<\/p>\n
Quindi chiamiamo pg_chameleon (chameleon \u00e8 il comando) con l'argomento set_configuration_files, per abilitare pg_chameleon e creare le cartelle e i file di configurazione predefiniti.<\/p>\n
<\/p>\n
(venv) $> chameleon set_configuration_files\ncreating directory \/root\/.pg_chameleon\ncreating directory \/root\/.pg_chameleon\/configuration\/\ncreating directory \/root\/.pg_chameleon\/logs\/\ncreating directory \/root\/.pg_chameleon\/pid\/\ncopiando il file di configurazione di esempio in \/root\/.pg_chameleon\/configuration\/\/config-example.yml<\/code><\/pre>\n
<\/p>\n
Ora stiamo creando una copia di config-example.yml come default.yml, affinch\u00e9 diventi il file di configurazione predefinito. Un modello di file di configurazione per questo esempio \u00e8 fornito di seguito.<\/p>\n
<\/p>\n
$> cat default.yml\n---\n# impostazioni globali\npid_dir: '~\/.pg_chameleon\/pid\/'\nlog_dir: '~\/.pg_chameleon\/logs\/'\nlog_dest: file\nlog_level: info\nlog_days_keep: 10\nrollbar_key: ''\nrollbar_env: ''\n\n# type_override consente all'utente di sovrascrivere la conversione del tipo predefinito in uno diverso.\ntype_override:\n  \"tinyint(1)\":\n    override_to: boolean\n    override_tables:\n      - \"*\"\n\n# connessione di destinazione postgres\npg_conn:\n  host: \"192.168.56.106\"\n  port: \"5433\"\n  user: \"usr_replica\"\n  password: \"pass123\"\n  database: \"db_replica\"\n  charset: \"utf8\"\n\nsources:\n  mysql:\n    db_conn:\n      host: \"192.168.56.102\"\n      port: \"3306\"\n      user: \"usr_replica\"\n      password: \"pass123\"\n      charset: 'utf8'\n      connect_timeout: 10\n    schema_mappings:\n      world_x: pgworld_x\n    limit_tables:\n#      - delphis_mediterranea.foo\n    skip_tables:\n#      - delphis_mediterranea.bar\n    grant_select_to:\n      - usr_readonly\n    lock_timeout: \"120s\"\n    my_server_id: 100\n    replica_batch_size: 10000\n    replay_max_rows: 10000\n    batch_retention: '1 day'\n    copy_max_memory: \"300M\"\n    copy_mode: 'file'\n    out_dir: \/tmp\n    sleep_loop: 1\n    on_error_replay: continue\n    on_error_read: continue\n    auto_maintenance: \"disabled\"\n    gtid_enable: No\n    type: mysql\n    skip_events:\n      insert:\n        - delphis_mediterranea.foo #salta gli insert sulla tabella delphis_mediterranea.foo\n      delete:\n        - delphis_mediterranea #salta i delete sullo schema delphis_mediterranea\n      update:<\/code><\/pre>\n
<\/p>\n
Il file di configurazione in questo esempio \u00e8 un modello di file per pg_chameleon con lievi modifiche in base agli ambienti sorgente e di destinazione, e di seguito \u00e8 fornita una panoramica delle diverse sezioni del file di configurazione.<\/p>\n
<\/p>\n
Nel file di configurazione default.yml \u00e8 presente una sezione di impostazioni globali (global settings), dove \u00e8 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\" \u00e8 indicato al plurale, il che significa che possiamo aggiungere pi\u00f9 database sorgente per uno solo di destinazione, per configurare una configurazione \"molti a uno\".<\/p>\n
<\/p>\n
Il database world_x nell'esempio contiene 4 tabelle con righe che la comunit\u00e0 MySQL offre come esempio. Pu\u00f2 essere scaricato qui<\/a><\/noindex>. L'esempio del database \u00e8 fornito come tar e in un archivio compresso con istruzioni su come creare e importare le righe.<\/p>\n
<\/p>\n
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.<\/p>\n
<\/p>\n
mysql> CREATE USER usr_replica ;\nmysql> SET PASSWORD FOR usr_replica='pass123';\nmysql> GRANT ALL ON world_x.* TO 'usr_replica';\nmysql> GRANT RELOAD ON *.* to 'usr_replica';\nmysql> GRANT REPLICATION CLIENT ON *.* to 'usr_replica';\nmysql> GRANT REPLICATION SLAVE ON *.* to 'usr_replica';\nmysql> FLUSH PRIVILEGES;<\/code><\/pre>\n
<\/p>\n
Sul lato PostgreSQL viene creato un database db_replica, che accetter\u00e0 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 \u00e8 gestita dall'argomento create_replica_schema, come vedrete di seguito.<\/p>\n
<\/p>\n
postgres=# CREATE USER usr_replica WITH PASSWORD 'pass123';\nCREATE ROLE\npostgres=# CREATE DATABASE db_replica WITH OWNER usr_replica;\nCREATE DATABASE<\/code><\/pre>\n
<\/p>\n
Il database MySQL viene configurato con modifiche a alcuni parametri per prepararlo alla replica, come mostrato di seguito. Sar\u00e0 necessario riavviare il server dei database affinch\u00e9 le modifiche abbiano effetto.<\/p>\n
<\/p>\n
$> vi \/etc\/my.cnf\nbinlog_format= ROW\nbinlog_row_image=FULL\nlog-bin = mysql-bin\nserver-id = 1<\/code><\/pre>\n
<\/p>\n
Adesso \u00e8 importante controllare la connessione a entrambi i server di database, in modo che durante l'esecuzione dei comandi pg_chameleon non si verifichino problemi.<\/p>\n
<\/p>\n
Sul nodo PostgreSQL:<\/p>\n
<\/p>\n
$> mysql -u usr_replica -Ap'admin123' -h 192.168.56.102 -D world_x<\/code><\/pre>\n
<\/p>\n
Sul nodo MySQL :<\/p>\n
<\/p>\n
$> psql -p 5433 -U usr_replica -h 192.168.56.106 db_replica<\/code><\/pre>\n
<\/p>\n
I 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\u00e0 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.<\/p>\n
<\/p>\n
$> chameleon create_replica_schema --debug\n$> chameleon add_source --config default --source mysql --debug\n$> chameleon init_replica --config default --source mysql --debug<\/code><\/pre>\n
<\/p>\n
I 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.<\/p>\n
<\/p>\n
Infine, iniziamo la replica utilizzando start_replica e riceviamo un messaggio di esecuzione corretta.<\/p>\n
<\/p>\n
$> chameleon start_replica --config default --source mysql \noutput: Avvio del processo di replica per la sorgente mysql<\/code><\/pre>\n
<\/p>\n
Lo stato della replica pu\u00f2 essere richiesto utilizzando l'argomento show_status, e gli errori possono essere visualizzati con l'argomento show_errors.<\/p>\n
<\/p>\n
Risultato.<\/a><\/noindex><\/p>\n
<\/p>\n
Come gi\u00e0 detto, ogni funzione di replicazione \u00e8 gestita da demoni. Per visualizzarli, richiediamo la tabella dei processi con il comando Linux ps, come mostrato di seguito.<\/p>\n
<\/p>\n
Risultato.<\/a><\/noindex><\/p>\n
<\/p>\n
La replica non \u00e8 considerata configurata finch\u00e9 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.<\/p>\n
<\/p>\n
mysql> create table t1 (n1 int primary key, n2 varchar(10));\nQuery OK, 0 righe interessate (0.01 sec)\nmysql> insert into t1 values (1,'one');\nQuery OK, 1 riga interessata (0.00 sec)\nmysql> insert into t1 values (2,'two');\nQuery OK, 1 riga interessata (0.00 sec)<\/code><\/pre>\n
<\/p>\n
$> chameleon sync_tables --tables world_x.t1 --config default --source mysql\nIl processo di sincronizzazione delle tabelle per la sorgente mysql \u00e8 iniziato.<\/code><\/pre>\n
<\/p>\n
Per confermare i risultati del test, richiediamo la tabella dal database PostgreSQL e visualizziamo le righe.<\/p>\n
<\/p>\n
$> psql -p 5433 -U usr_replica -d db_replica -c \"select * from pgworld_x.t1\";\n n1 |  n2\n----+-------\n  1 | one\n  2 | two<\/code><\/pre>\n
<\/p>\n
Se 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\u00e0 un database PostgreSQL trasferito senza riferimenti al database sorgente o allo schema di replica (sch_chameleon).<\/p>\n
<\/p>\n
$> chameleon stop_replica --config default --source mysql \n$> chameleon detach_replica --config default --source mysql --debug<\/code><\/pre>\n
<\/p>\n
Facoltativamente, con i seguenti comandi \u00e8 possibile rimuovere la configurazione sorgente e lo schema di replica.<\/p>\n
<\/p>\n
$> chameleon drop_source --config default --source mysql --debug\n$> chameleon drop_replica_schema --config default --source mysql --debug<\/code><\/pre>\n
<\/p>\n
Vantaggi di pg_chameleon<\/h3>\n
<\/p>\n
Configurazione e impostazione semplici.
\nFacile risoluzione dei problemi e identificazione delle anomalie con messaggi di errore chiari.
\n\u00c8 possibile aggiungere ulteriori tabelle speciali alla replica dopo l'inizializzazione, senza modificare il resto della configurazione.
\n\u00c8 possibile configurare pi\u00f9 database sorgente per un unico obiettivo, il che \u00e8 molto comodo se si stanno unendo dati da uno o pi\u00f9 database MySQL in un unico database PostgreSQL.
\n\u00c8 possibile non replicare le tabelle selezionate.<\/p>\n
<\/p>\n
Svantaggi di pg_chameleon<\/h3>\n
<\/p>\n
\u00c8 supportato solo da MySQL 5.5 e versioni superiori come sorgente e PostgreSQL 9.5 e versioni superiori come database di destinazione.
\nOgni tabella deve avere una chiave primaria o unica, altrimenti le tabelle vengono inizializzate durante il processo init_replica, ma non vengono replicate.
\nLa replica unidirezionale \u00e8 possibile solo da MySQL a PostgreSQL. Pertanto, \u00e8 adeguata solo per uno schema \"attivo-passivo\".
\nIl database sorgente pu\u00f2 essere solo MySQL, mentre il supporto del database PostgreSQL come sorgente \u00e8 solo esperimentale e con limitazioni (scopri di pi\u00f9 qui<\/a><\/noindex>)<\/p>\n
<\/p>\n
Riepiloghi su pg_chameleon<\/h3>\n
<\/p>\n
Il metodo di replica in pg_chameleon \u00e8 ottimale per la migrazione di database da MySQL a PostgreSQL. Un grosso svantaggio \u00e8 che la replica \u00e8 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\u00f2 essere risolto con un altro strumento open source: SymmetricDS.<\/p>\n
<\/p>\n
Leggi di pi\u00f9 nella documentazione ufficiale qui<\/a><\/noindex>. La guida per la riga di comando pu\u00f2 essere trovata qui<\/a><\/noindex>.<\/p>\n
<\/p>\n
Panoramica di SymmetricDS<\/h3>\n
<\/p>\n
SymmetricDS \u00e8 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\u00e0 disponibili includono: sincronizzazione di database e file, replica di pi\u00f9 database principali, sincronizzazione filtrata, trasformazione e altro. \u00c8 uno strumento basato su Java e richiede una versione standard di JRE o JDK (versioni 8.0 o superiori). Qui \u00e8 possibile registrare le modifiche ai dati tramite trigger nel database sorgente e indirizzarle al database di destinazione corrispondente in pacchetti.<\/p>\n
<\/p>\n
Funzionalit\u00e0 di SymmetricDS<\/h3>\n
<\/p>\n
Lo strumento \u00e8 indipendente dalla piattaforma, il che significa che due o pi\u00f9 database diversi possono scambiare dati.
\nI database relazionali vengono sincronizzati tramite la registrazione delle modifiche ai dati, mentre i database basati su file utilizzano la sincronizzazione dei file.
\nReplica bidirezionale utilizzando metodi Push e Pull basati su un insieme di regole.
\nLa trasmissione dei dati \u00e8 possibile su reti sicure e su reti con bassa capacit\u00e0 di banda.
\nRipristino automatico al riavvio dei nodi dopo un guasto e risoluzione automatica dei conflitti.
\nCompatibilit\u00e0 con il cloud ed API per estensioni efficienti.<\/p>\n
<\/p>\n
Esempio<\/h3>\n
<\/p>\n
SymmetricDS pu\u00f2 essere configurato in una delle due varianti:
\nNodo 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.
\nUn nodo attivo (nodo 1) pu\u00f2 scambiare dati per la replica con un altro nodo attivo (nodo 2) senza intermediari.<\/p>\n
<\/p>\n
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 guida<\/a><\/noindex>, per saperne di pi\u00f9 sul funzionamento di SymmetricDS.<\/p>\n
<\/p>\n
Installare SymmetricDS \u00e8 molto semplice: scarica la versione open source del file zip da qui<\/a><\/noindex> 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.<\/p>\n
<\/p>\n
Host
\nvm1
\nvm2<\/p>\n
Versione del sistema operativo<\/strong>
\nCentOS Linux 7.6 x86_64
\nCentOS Linux 7.6 x86_64<\/p>\n
Versione del server DB<\/strong>
\nMySQL 5.7.26
\nPostgreSQL 10.5<\/p>\n
Porta DB<\/strong>
\n3306
\n5832<\/p>\n
indirizzo IP<\/strong>
\n192.168.1.107
\n192.168.1.112<\/p>\n
Versione di SymmetricDS<\/strong>
\nSymmetricDS 3.9
\nSymmetricDS 3.9<\/p>\n
Percorso di installazione di SymmetricDS<\/strong>
\n\/usr\/local\/symmetric-server-3.9.20
\n\/usr\/local\/symmetric-server-3.9.20<\/p>\n
Nome del nodo SymmetricDS<\/strong>
\ncorp-000
\nstore-001<\/p>\n
<\/p>\n
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\u00e0 del nodo, oltre ad esempi di script SQL per cominciare rapidamente la dimostrazione.<\/p>\n
<\/p>\n
Nella cartella samples vediamo tre file di configurazione con le propriet\u00e0 del nodo \u2014 il nome indica la funzione del nodo in un determinato schema.<\/p>\n
<\/p>\n
corp-000.properties\nstore-001.properties\nstore-002.properties<\/code><\/pre>\n
<\/p>\n
In 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:<\/p>\n
<\/p>\n
$> cat engines\/corp-000.properties\nengine.name=corp-000\ndb.driver=com.mysql.jdbc.Driver\ndb.url=jdbc:mysql:\/\/192.168.1.107:3306\/replica_db?autoReconnect=true&useSSL=false\ndb.user=root\ndb.password=admin123\nregistration.url=\nsync.url=http:\/\/192.168.1.107:31415\/sync\/corp-000\ngroup.id=corp\nexternal.id=000<\/code><\/pre>\n
<\/p>\n
Questo nodo nella configurazione di SymmetricDS si chiama corp-000, e la connessione al database \u00e8 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.<\/p>\n
<\/p>\n
Il nodo 2 sull'host vm2 \u00e8 configurato come store-001, mentre il resto \u00e8 specificato nel file node.properties riportato di seguito. Il nodo store-001 esegue un database PostgreSQL, mentre pgdb_replica \u00e8 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.<\/p>\n
<\/p>\n
$> cat engines\/store-001.properties\nengine.name=store-001\ndb.driver=org.postgresql.Driver\ndb.url=jdbc:postgresql:\/\/192.168.1.112:5832\/pgdb_replica\ndb.user=postgres\ndb.password=admin123\nregistration.url=http:\/\/192.168.1.107:31415\/sync\/corp-000\ngroup.id=store\nexternal.id=001<\/code><\/pre>\n
<\/p>\n
Un 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\u00e0 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.<\/p>\n
<\/p>\n
vm1$> cd \/usr\/local\/symmetric-server-3.9.20\/bin\nvm1$> .\/dbimport --engine corp-000 --format XML create_sample.xml\nvm1$> .\/symadmin --engine corp-000 create-sym-tables\nvm1$> .\/dbimport --engine corp-000 insert_sample.sql<\/code><\/pre>\n
<\/p>\n
Nell'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.<\/p>\n
<\/p>\n
vm2$> cd \/usr\/local\/symmetric-server-3.9.20\/bin\nvm2$> .\/dbimport --engine store-001 --format XML create_sample.xml<\/code><\/pre>\n
<\/p>\n
Controlliamo 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\u00e9 l\u00ec 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.<\/p>\n
<\/p>\n
Tutto. L'ambiente \u00e8 pronto per avviare i processi server sym su entrambi i nodi, come indicato di seguito.<\/p>\n
<\/p>\n
vm1$> cd \/usr\/local\/symmetric-server-3.9.20\/bin\nvm1$> sym 2>&1 &<\/code><\/pre>\n
<\/p>\n
I log delle registrazioni vengono inviati al file di log in background (symmetric.log) nella cartella dei log nella directory in cui \u00e8 installato SymmetricDS, nonch\u00e9 nei dati di output standard. Il server sym pu\u00f2 ora essere avviato sul nodo store-001.<\/p>\n
<\/p>\n
vm2$> cd \/usr\/local\/symmetric-server-3.9.20\/bin\nvm2$> sym 2>&1 &<\/code><\/pre>\n
<\/p>\n
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 \u00e8 stata eseguita con successo. In alternativa, possiamo inviare il caricamento iniziale al nodo store-001 da corp-000 con il seguente comando.<\/p>\n
<\/p>\n
vm1$> .\/symadmin --engine corp-000 reload-node 001<\/code><\/pre>\n
<\/p>\n
A questo punto, una nuova registrazione viene inserita nella tabella item del database MySQL sul nodo corp-000 (host: vm1) e si pu\u00f2 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.<\/p>\n
<\/p>\n
mysql> insert into item values ('22000002','Jelly Bean');\nQuery OK, 1 row affected (0.00 sec)<\/code><\/pre>\n
<\/p>\n
vm2$> psql -p 5832 -U postgres pgdb_replica -c \"select * from item\"\n item_id  |   name\n----------+-----------\n 11000001 | Yummy Gum\n 22000002 | Jelly Bean\n(2 rows)<\/code><\/pre>\n
<\/p>\n
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.<\/p>\n
<\/p>\n
Risultato.<\/a><\/noindex><\/p>\n
<\/p>\n
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.<\/p>\n
<\/p>\n
mysql> create table  t1 (no integer);\nQuery OK, 0 rows affected (0.01 sec)<\/code><\/pre>\n
<\/p>\n
mysql> insert into sym_channel (channel_id,create_time,last_update_time) \nvalues ('t1',current_timestamp,current_timestamp);\nQuery OK, 1 row affected (0.01 sec)<\/code><\/pre>\n
<\/p>\n
mysql> insert into sym_trigger (trigger_id, source_table_name,channel_id,\nlast_update_time, create_time) values ('t1', 't1', 't1', current_timestamp,\ncurrent_timestamp);\nQuery OK, 1 row affected (0.01 sec)<\/code><\/pre>\n
<\/p>\n
mysql> insert into sym_trigger_router (trigger_id, router_id,\nInitial_load_order, create_time,last_update_time) values ('t1',\n'corp-2-store-1', 1, current_timestamp,current_timestamp);\nQuery OK, 1 row affected (0.01 sec)<\/code><\/pre>\n
<\/p>\n
Quindi, la configurazione riceve una notifica sulla modifica dello schema, cio\u00e8 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 \u00e8 configurata.<\/p>\n
<\/p>\n
vm1$> .\/symadmin -e corp-000 --node=001 sync-triggers    \nvm1$> .\/symadmin send-schema -e corp-000 --node=001 t1<\/code><\/pre>\n
<\/p>\n
Vantaggi di SymmetricDS<\/h3>\n
<\/p>\n
Installazione e configurazione semplici, compreso un set di file predefiniti con parametri per creare uno schema con tre o due nodi.
\nCross-platform delle basi di dati e indipendenza dalla piattaforma, inclusi server, laptop e dispositivi mobili.
\nReplicazione di qualsiasi base di dati in un'altra base di dati localmente, in WAN o nel cloud.
\nPossibilit\u00e0 di gestire in modo ottimale una coppia di basi di dati o diverse migliaia per una replicazione comoda.
\nVersione a pagamento con interfaccia grafica e ottimo supporto.<\/p>\n
<\/p>\n
Svantaggi di SymmetricDS<\/h3>\n
<\/p>\n
\u00c8 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\u00f2 risultare scomodo.
\nConfigurare molte tabelle per la replicazione pu\u00f2 essere faticoso, se non si utilizzano script per creare gli operatori SQL che definiscono le regole e la direzione della replicazione.
\nNei log viene registrata troppa informazione e a volte \u00e8 necessario sistemare il file di log per evitare che occupi troppo spazio.<\/p>\n
<\/p>\n
Conclusioni su SymmetricDS<\/h3>\n
<\/p>\n
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\u00e0, 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\u00f2 essere utilizzato per i pi\u00f9 svariati scenari, inclusa la migrazione, l'aggiornamento a una nuova versione, la distribuzione, la filtrazione e la trasformazione dei dati su diverse piattaforme.<\/p>\n
<\/p>\n
L'esempio \u00e8 stato creato sulla base della guida breve ufficiale<\/a><\/noindex> su SymmetricDS. In manuale utente<\/a><\/noindex> Viene descritto in dettaglio vari concetti legati alla configurazione della replicazione utilizzando SymmetricDS.<\/p>\n
Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u042f \u0432 \u043e\u0431\u0449\u0438\u0445 \u0447\u0435\u0440\u0442\u0430\u0445 \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443 \u043e \u043f\u0435\u0440\u0435\u043a\u0440\u0435\u0441\u0442\u043d\u043e\u0439 \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u0438 \u043c\u0435\u0436\u0434\u0443 PostgreSQL \u0438 MySQL, \u0430 \u0435\u0449\u0435 \u043e \u043c\u0435\u0442\u043e\u0434\u0430\u0445 \u043d\u0430\u0441\u0442\u0440\u043e\u0439\u043a\u0438 \u043f\u0435\u0440\u0435\u043a\u0440\u0435\u0441\u0442\u043d\u043e\u0439 \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u0438 \u043c\u0435\u0436\u0434\u0443 \u044d\u0442\u0438\u043c\u0438 \u0434\u0432\u0443\u043c\u044f \u0441\u0435\u0440\u0432\u0435\u0440\u0430\u043c\u0438 \u0431\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445. \u041e\u0431\u044b\u0447\u043d\u043e \u0431\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445 \u0432 \u043f\u0435\u0440\u0435\u043a\u0440\u0435\u0441\u0442\u043d\u043e\u0439 \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u0438 \u043d\u0430\u0437\u044b\u0432\u0430\u044e\u0442\u0441\u044f \u043e\u0434\u043d\u043e\u0440\u043e\u0434\u043d\u044b\u043c\u0438, \u0438 \u044d\u0442\u043e \u0443\u0434\u043e\u0431\u043d\u044b\u0439 \u043c\u0435\u0442\u043e\u0434 \u043f\u0435\u0440\u0435\u0445\u043e\u0434\u0430 \u0441 \u043e\u0434\u043d\u043e\u0433\u043e \u0441\u0435\u0440\u0432\u0435\u0440\u0430 \u0440\u0435\u043b\u044f\u0446\u0438\u043e\u043d\u043d\u043e\u0439 \u0421\u0423\u0411\u0414 \u043d\u0430 \u0434\u0440\u0443\u0433\u043e\u0439. \u0411\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445 PostgreSQL \u0438 MySQL \u043f\u0440\u0438\u043d\u044f\u0442\u043e \u0441\u0447\u0438\u0442\u0430\u0442\u044c \u0440\u0435\u043b\u044f\u0446\u0438\u043e\u043d\u043d\u044b\u043c\u0438, \u043d\u043e \u0441 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28635,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-38146","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Replicazione incrociata tra PostgreSQL e MySQL | ProHoster","description":"In termini generali, parler\u00f2 di.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/perekrestnaya-replikatsiya-mezhdu-postgresql-i-mysql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041f\u0435\u0440\u0435\u043a\u0440\u0435\u0441\u0442\u043d\u0430\u044f \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u044f \u043c\u0435\u0436\u0434\u0443 PostgreSQL \u0438 MySQL | ProHoster","og:description":"\u042f \u0432 \u043e\u0431\u0449\u0438\u0445 \u0447\u0435\u0440\u0442\u0430\u0445 \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443 \u043e.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/perekrestnaya-replikatsiya-mezhdu-postgresql-i-mysql","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:21:54+00:00","article:modified_time":"2019-10-31T19:21:54+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"38146","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 20:38:22","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 18:59:41","updated":"2026-01-23 20:38:22","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/38146","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=38146"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/38146\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/28635"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=38146"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=38146"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=38146"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}