{"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 questa panoramica parler\u00f2 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 \u00e8 un modo conveniente per passare da un server di 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 la replica tra PostgreSQL e MySQL dal punto di vista di RDBMS.<\/p>\n

<\/p>\n

Non descriveremo tutti i dettagli tecnici, solo i principi di base, affinch\u00e9 possiate avere un'idea di come configurare la replica tra i server di database, i vantaggi, le limitazioni e i casi d'uso.<\/p>\n

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

La replicazione tra due server di database identici avviene generalmente in modalit\u00e0 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 \u00e8 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\u00e9 la replicazione avviene solo in una direzione. Tuttavia, \u00e8 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\u00f2, compresa la replicazione a cascata, \u00e8 possibile tra due o pi\u00f9 server di database identici. La configurazione \"attivo-attivo\" o \"attivo-passivo\" dipende dalle esigenze, dalla disponibilit\u00e0 delle funzionalit\u00e0 nella configurazione originale o dall'uso di soluzioni esterne per la configurazione e dai compromessi esistenti.<\/p>\n

<\/p>\n

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

<\/p>\n

La replicazione incrociata tra MySQL e PostgreSQL \u00e8 necessaria per una migrazione una tantum 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, si pu\u00f2 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 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.<\/p>\n

<\/p>\n

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

<\/p>\n

\u00c8 possibile replicare diversi schemi MySQL da un cluster in un unico database PostgreSQL con una configurazione \"uno a molti\".
\nI nomi degli schemi di origine e di destinazione non possono coincidere.
\nI dati di replicazione possono essere estratti da una replica a 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 OS<\/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, preparare tutti i componenti necessari per l'installazione di pg_chameleon. In questo esempio, \u00e8 installato Python 3.6.8, che crea un ambiente virtuale e lo attiva.<\/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 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 \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
Successivamente, chiamiamo pg_chameleon (chameleon \u00e8 il comando) con l'argomento set_configuration_files, per abilitare pg_chameleon e creare le directory e i file di configurazione predefiniti.<\/p>\n
<\/p>\n
(venv) $> chameleon set_configuration_files\ncreazione della directory \/root\/.pg_chameleon\ncreazione della directory \/root\/.pg_chameleon\/configuration\/\ncreazione della directory \/root\/.pg_chameleon\/logs\/\ncreazione della directory \/root\/.pg_chameleon\/pid\/\ncopiatura dell'esempio di configurazione in \/root\/.pg_chameleon\/configuration\/config-example.yml<\/code><\/pre>\n
<\/p>\n
Ora creiamo una copia di config-example.yml come default.yml, in modo che diventi il file di configurazione predefinito. Di seguito \u00e8 riportato un esempio del file di configurazione per questo esempio.<\/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 permette all'utente di sovrascrivere la conversione di tipo predefinita in un tipo 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 giorno'\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: \"disabilitato\"\n    gtid_enable: No\n    type: mysql\n    skip_events:\n      insert:\n        - delphis_mediterranea.foo #salta gli inserimenti nella tabella delphis_mediterranea.foo\n      delete:\n        - delphis_mediterranea #salta le cancellazioni nello schema delphis_mediterranea\n      update:<\/code><\/pre>\n
<\/p>\n
Il file di configurazione in questo esempio \u00e8 un campione di file con pg_chameleon con lievi modifiche in base agli ambienti sorgente e di destinazione, e sotto \u00e8 fornora una panoramica delle diverse sezioni del file di configurazione.<\/p>\n
<\/p>\n
Nel file di configurazione default.yml si trova 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. Successivamente, c'\u00e8 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' \u00e8 indicato al plurale, il che significa che possiamo aggiungere pi\u00f9 database sorgenti per uno solo di destinazione, configurando cos\u00ec 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 fornisce come esempio. Pu\u00f2 essere scaricato. qui<\/a><\/noindex>L'esempio del database \u00e8 fornito in formato tar e come archivio compresso con istruzioni per la creazione e l'importazione delle righe.<\/p>\n
<\/p>\n
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.<\/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
Dalla parte di PostgreSQL viene creato un database db_replica, che ricever\u00e0 le modifiche dal database MySQL. L'utente usr_replica in PostgreSQL \u00e8 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 \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 alcune modifiche ai parametri, per prepararlo alla replicazione, 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
\u00c8 ora importante verificare la connessione a entrambi i server dei database, affinch\u00e9 durante l'esecuzione dei comandi pg_chameleon non ci siano 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 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\u00e0 accennato. L'argomento add_source aggiunge il database sorgente alla configurazione, leggendo il file di configurazione (default.yml), e nel nostro caso \u00e8 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
L'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.<\/p>\n
<\/p>\n
Infine, avviamo la replica utilizzando start_replica e riceviamo un messaggio di esecuzione riuscita.<\/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 replica \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 invochiamo 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 rows affected (0.01 sec)\nmysql> insert into t1 values (1,'one');\nQuery OK, 1 row affected (0.00 sec)\nmysql> insert into t1 values (2,'two');\nQuery OK, 1 row affected (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 | uno\n  2 | due<\/code><\/pre>\n
<\/p>\n
Se 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\u00e0 un database PostgreSQL accuratamente 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 eliminare 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 tabelle speciali alla replica dopo l'inizializzazione, senza modificare il resto della configurazione.
\n\u00c8 possibile configurare pi\u00f9 database sorgente per uno obiettivo, il che \u00e8 molto utile se si uniscono 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
Supportato solo con MySQL 5.5 e versioni successive come sorgente e PostgreSQL 9.5 e versioni successive come database di destinazione.
\nOgni tabella deve avere una chiave primaria o unica, altrimenti le tabelle vengono inizializzate durante il processo di init_replica, ma non vengono replicate.
\nLa replicazione \u00e8 unidirezionale \u2014 solo da MySQL a PostgreSQL. Pertanto, si adatta solo a uno schema \"attivo-passivo\".
\nLa sorgente pu\u00f2 essere solo un database MySQL, mentre il supporto per il database PostgreSQL come sorgente \u00e8 solo sperimentale e con limitazioni (scopri di pi\u00f9 qui<\/a><\/noindex>)<\/p>\n
<\/p>\n
Conclusioni su pg_chameleon<\/h3>\n
<\/p>\n
Il metodo di replica in pg_chameleon \u00e8 eccellente per migrare un database da MySQL a PostgreSQL. Un notevole svantaggio \u00e8 che la replica \u00e8 unidirezionale, quindi gli specialisti di database probabilmente non vorranno utilizzarlo per altro, se non per la migrazione. Tuttavia, il problema della replicazione unidirezionale pu\u00f2 essere risolto con un altro strumento open source \u2014 SymmetricDS.<\/p>\n
<\/p>\n
Maggiore informazioni sono disponibili nella documentazione ufficiale qui<\/a><\/noindex>. Puoi trovare la guida per la riga di comando 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, 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\u00f9 database primari, sincronizzazione filtrata, trasformazione e altro. \u00c8 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.<\/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 scambiarsi dati.
\nI database relazionali sono sincronizzati mediante 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 tramite reti sicure e reti con bassa capacit\u00e0 di trasmissione.
\nRipristino automatico al riavvio dei nodi dopo un guasto e risoluzione automatica dei conflitti.
\nCompatibilit\u00e0 con il cloud e API di estensione efficienti.<\/p>\n
<\/p>\n
Esempio<\/h3>\n
<\/p>\n
SymmetricDS pu\u00f2 essere configurato in una delle due modalit\u00e0:
\nNodo 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.
\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 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 la guida<\/a><\/noindex>, per saperne di pi\u00f9 sul funzionamento di SymmetricDS.<\/p>\n
<\/p>\n
Instalare SymmetricDS \u00e8 molto semplice: scarica la versione open source del file zip. da qui<\/a><\/noindex> 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.<\/p>\n
<\/p>\n
Host
\nvm1
\nvm2<\/p>\n
Versione OS<\/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 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\u00e0 del nodo, insieme a esempi di script SQL per un rapido avvio della dimostrazione.<\/p>\n
<\/p>\n
Nel catalogo samples vediamo tre file di configurazione con le propriet\u00e0 del nodo \u2014 il nome indica la natura del nodo in uno schema specifico.<\/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 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\u00ec:<\/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 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.<\/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, e pgdb_replica \u00e8 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.<\/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 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\u00e0 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.<\/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 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.<\/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
Verifichiamo 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\u00e9 l\u00ec 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.<\/p>\n
<\/p>\n
Tutto. L'ambiente \u00e8 pronto per avviare i processi server sym su entrambi i nodi, come mostrato 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
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\u00ec come nell'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 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 \u00e8 avvenuta con successo. In alternativa, si pu\u00f2 inviare un 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 nel database MySQL sul nodo corp-000 (host: vm1), e si pu\u00f2 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.<\/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 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.<\/p>\n
<\/p>\n
Risultato.<\/a><\/noindex><\/p>\n
<\/p>\n
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\u00ec impostiamo solo la replica 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
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 \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, inclusi un insieme pronto di file con parametri per creare schemi con tre o due nodi.
\nCross-platform database compatibility e indipendenza dalla piattaforma, inclusi server, laptop e dispositivi mobili.
\nReplica di qualsiasi database in un altro database localmente, in WAN o nel cloud.
\nCapacit\u00e0 di gestire ottimamente da un paio a diverse migliaia di database per una replica comoda.
\nVersione a pagamento con interfaccia grafica e supporto eccellente.<\/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 replica tramite operatori SQL per il caricamento delle tabelle di catalogo, il che pu\u00f2 risultare scomodo.
\nConfigurare molte tabelle per la replica pu\u00f2 diventare stancante se non si utilizzano script per creare operatori SQL che definiscono le regole e la direzione della replica.
\nViene registrata troppe informazioni nei log, e a volte \u00e8 necessario sistemare il file di log affinch\u00e9 non occupi troppo spazio.<\/p>\n
<\/p>\n
Conclusioni su SymmetricDS<\/h3>\n
<\/p>\n
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\u00e0 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\u00ec via. SymmetricDS esegue la replica tra qualsiasi database, rendendolo utilizzabile per i pi\u00f9 diversi scenari, tra cui migrazione, aggiornamento, distribuzione, filtraggio e trasformazione dei dati su diverse piattaforme.<\/p>\n
<\/p>\n
Esempio creato basato sulla guida ufficiale guida rapida<\/a><\/noindex> per SymmetricDS. Nel manuale dell'utente<\/a><\/noindex> vengono descritti dettagliatamente vari concetti legati alla configurazione della replica tramite 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\udd47 Replica incrociata tra PostgreSQL e MySQL | ProHoster","description":"In questo articolo, parler\u00f2 in linea generale della replica incrociata tra PostgreSQL e MySQL, e dei metodi per configurare questa replica tra i due server di database. Le basi dati nella replica incrociata vengono solitamente definite omogenee e rappresentano un metodo conveniente per passare da un server di RDBMS a un altro. PostgreSQL e MySQL sono considerati database relazionali, ma con","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 \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","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"},"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}]}}