Een overzicht van PostgreSQL- en MySQL-kruisreplicatie

Deze blog is bedoeld om een ​​overzicht van kruisreplicatie tussen PostgreSQL en MySQL uit te leggen en om de methoden voor het configureren van kruisreplicatie tussen de twee databaseservers verder te bespreken. Traditioneel worden de databases die betrokken zijn bij een cross-replicatieconfiguratie heterogene databases genoemd, wat een goede benadering is om van de ene RDBMS-server naar de andere te gaan.

Zowel PostgreSQL- als MySQL-databases zijn traditioneel RDBMS-databases, maar ze bieden ook NoSQL-mogelijkheden met toegevoegde extensies om het beste van twee werelden te hebben. Dit artikel richt zich op de bespreking van replicatie tussen PostgreSQL en MySQL vanuit een RDBMS-perspectief.

Een uitputtende uitleg over de interne aspecten van replicatie valt niet binnen de reikwijdte van deze blog, maar er zullen enkele fundamentele elementen worden besproken om het publiek inzicht te geven in hoe replicatie is geconfigureerd tussen databaseservers, voordelen, beperkingen en misschien enkele bekende gebruiksgevallen.

Over het algemeen wordt replicatie tussen twee identieke databaseservers bereikt in binaire modus of in querymodus tussen een masterknooppunt (ook wel uitgever, primair of actief genoemd) en een slaveknooppunt (abonnee, stand-by of passief). Het doel van replicatie is om een ​​realtime kopie van de masterdatabase aan de slave-zijde te bieden, waar de gegevens van master naar slave worden overgedragen, waardoor een actief-passieve opstelling wordt gevormd omdat de replicatie slechts op één manier is geconfigureerd. Aan de andere kant kan replicatie tussen twee databases op beide manieren worden geconfigureerd, zodat de gegevens ook van slave terug naar master kunnen worden overgedragen, waardoor een actief-actieve configuratie tot stand wordt gebracht. Dit alles kan worden geconfigureerd tussen twee of meer identieke databaseservers die ook een trapsgewijze replicatie kunnen bevatten. De configuratie van actief-actief of actief-passief hangt echt af van de zakelijke behoefte, de beschikbaarheid van dergelijke functies binnen de native configuratie of het gebruik van externe oplossingen om te configureren en toepasselijke afwegingen.

De bovengenoemde configuratie kan worden bereikt met diverse databaseservers, waarbij een databaseserver kan worden geconfigureerd om gerepliceerde gegevens van een andere volledig andere databaseserver te accepteren en toch een realtime momentopname te behouden van de gegevens die worden gerepliceerd. Zowel MySQL- als PostgreSQL-databaseservers bieden de meeste van de hierboven besproken configuraties in hun eigen geboorte of met behulp van extensies van derden, waaronder binaire logmethode, schijfblokmethode, op instructies gebaseerde en rijgebaseerde methoden.

De vereiste om een ​​kruisreplicatie tussen MySQL en PostgreSQL te configureren, komt echt van pas als gevolg van een eenmalige migratie-inspanning om van de ene databaseserver naar de andere te gaan. Omdat beide databases verschillende protocollen gebruiken, kunnen ze niet rechtstreeks met elkaar praten. Om die communicatiestroom te bereiken, is er een externe open source-tool zoals pg_chameleon.

Achtergrond van pg_chameleon

pg_chameleon is een MySQL naar PostgreSQL-replicatiesysteem ontwikkeld in Python 3. Het maakt gebruik van een open source-bibliotheek genaamd mysql-replicatie die ook is ontwikkeld met Python. De functionaliteit omvat het ophalen van rij-afbeeldingen van MySQL-tabellen en deze als JSONB-objecten opslaan in een PostgreSQL-database, die verder wordt gedecodeerd door een pl/pgsql-functie en die wijzigingen opnieuw afspelen met de PostgreSQL-database.

Kenmerken van pg_chameleon

• Meerdere MySQL-schema's van hetzelfde cluster kunnen worden gerepliceerd naar een enkele PostgreSQL-doeldatabase, waardoor een veel-op-een-replicatieconfiguratie ontstaat
• De namen van het bron- en doelschema kunnen niet-identiek zijn
• Replicatiegegevens kunnen worden opgehaald uit MySQL-cascadereplica
• Tabellen die niet kunnen worden gerepliceerd of die geen fouten genereren, zijn uitgesloten
• Elke replicatiefunctionaliteit wordt beheerd met behulp van daemons
• Bediend met behulp van parameters en configuratiebestanden op basis van YAML-constructie

Demo

Bereid om te beginnen de installatie voor met alle vereisten die nodig zijn om pg_chameleon te installeren. In deze demo is Python 3.6.8 geïnstalleerd, waardoor een virtuele omgeving wordt gecreëerd en deze voor gebruik wordt geactiveerd.

$> 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 altinstall

Na een succesvolle installatie van Python3.6 wordt voldaan aan verdere aanvullende vereisten zoals het creëren en activeren van een virtuele omgeving. Daarnaast is de pip-module geüpgraded naar de nieuwste versie en wordt deze gebruikt om pg_chameleon te installeren. In de onderstaande commando's is pg_chameleon 2.0.9 opzettelijk geïnstalleerd, terwijl de nieuwste versie 2.0.10 is. Dit wordt gedaan om nieuw geïntroduceerde bugs in de bijgewerkte versie te voorkomen.

$> python3.6 -m venv venv
$> source venv/bin/activate
(venv) $> pip install pip --upgrade
(venv) $> pip install pg_chameleon==2.0.9

De volgende stap is om het pg_chameleon (kameleon is de opdracht) met het argument set_configuration_files aan te roepen om pg_chameleon in staat te stellen standaardmappen en configuratiebestanden te maken.

(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.yml

Maak nu een kopie van config-example.yml als default.yml om dit het standaardconfiguratiebestand te maken. Hieronder vindt u een voorbeeldconfiguratiebestand dat voor deze demo wordt gebruikt.

$> 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:

Het configuratiebestand dat in deze demo wordt gebruikt, is het voorbeeldbestand dat bij pg_chameleon wordt geleverd, met kleine aanpassingen aan de bron- en doelomgevingen, en een samenvatting van verschillende secties van het configuratiebestand volgt.

Het default.yml-configuratiebestand heeft een sectie "algemene instellingen" die details controleert, zoals de locatie van het vergrendelingsbestand, de logboeklocaties en de bewaarperiode, enz. De sectie die daarna volgt, is de sectie "type overschrijven", een reeks regels om te negeren typen tijdens replicatie. Er wordt standaard een voorbeeldtype-override-regel gebruikt die een tinyint(1) omzet in een booleaanse waarde. Het volgende gedeelte is het gedeelte met de verbindingsdetails van de bestemmingsdatabase, in ons geval een PostgreSQL-database, aangeduid met "pg_conn". Het laatste gedeelte is het brongedeelte met alle details van de verbindingsinstellingen van de brondatabase, schematoewijzing tussen bron en bestemming, alle tabellen die moeten worden overgeslagen, inclusief time-out, geheugen en instellingen voor batchgrootte. Let op de "bronnen" die aangeven dat er meerdere bronnen naar een enkele bestemming kunnen zijn om een ​​veel-op-een replicatie-configuratie te vormen.

In deze demo wordt een "world_x"-database gebruikt, een voorbeelddatabase met 4 tabellen met voorbeeldrijen, die de MySQL-gemeenschap aanbiedt voor demo-doeleinden en die hier kan worden gedownload. De voorbeelddatabase wordt geleverd als een tar- en gecomprimeerd archief, samen met instructies om deze aan te maken en er rijen in te importeren.

Er wordt een toegewijde gebruiker gemaakt in zowel de MySQL- als de PostgreSQL-database met dezelfde naam als usr_replica, die verder aanvullende bevoegdheden op MySQL krijgt om leestoegang te hebben tot alle tabellen die worden gerepliceerd.

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;

Er wordt een database gemaakt aan de PostgreSQL-kant die wijzigingen accepteert van de MySQL-database, die wordt genoemd als "db_replica". De gebruiker "usr_replica" in PostgreSQL wordt automatisch geconfigureerd als eigenaar van twee schema's zoals "pgworld_x" en "sch_chameleon" die respectievelijk de daadwerkelijk gerepliceerde tabellen en catalogustabellen bevatten. Deze automatische configuratie wordt gedaan door het argument create_replica_schema, dat hieronder verder wordt aangegeven.

postgres=# CREATE USER usr_replica WITH PASSWORD 'pass123';
CREATE ROLE
postgres=# CREATE DATABASE db_replica WITH OWNER usr_replica;
CREATE DATABASE

De MySQL-database is geconfigureerd met een paar parameterwijzigingen om deze voor te bereiden op replicatie, zoals hieronder weergegeven, en het vereist een herstart van de databaseserver om de wijzigingen door te voeren.

$> vi /etc/my.cnf
binlog_format= ROW
binlog_row_image=FULL
log-bin = mysql-bin
server-id = 1

Op dit moment is het belangrijk om de connectiviteit met beide databaseservers te testen om er zeker van te zijn dat er geen problemen zijn wanneer pg_chameleon-opdrachten worden uitgevoerd.

Op het PostgreSQL-knooppunt:

$> mysql -u usr_replica -Ap'admin123' -h 192.168.56.102 -D world_x 

Op het MySQL-knooppunt:

$> psql -p 5433 -U usr_replica -h 192.168.56.106 db_replica

De volgende drie commando's van pg_chameleon (kameleon) is waar het de omgeving instelt, een bron toevoegt en een replica initialiseert. Het argument "create_replica_schema" van pg_chameleon creëert het standaardschema (sch_chameleon) en replicatieschema (pgworld_x) in de PostgreSQL-database, zoals al is besproken. Het argument "add_source" voegt de brondatabase toe aan de configuratie door het configuratiebestand (default.yml) te lezen, in dit geval "mysql", terwijl de "init_replica" de configuratie initialiseert op basis van de instellingen van het configuratiebestand.

$> chameleon create_replica_schema --debug
$> chameleon add_source --config default --source mysql --debug
$> chameleon init_replica --config default --source mysql --debug

De uitvoer van de bovenstaande drie opdrachten spreekt voor zich en geeft het succes van elke opdracht aan met een duidelijk uitvoerbericht. Eventuele storingen of syntaxisfouten worden duidelijk vermeld in eenvoudige en duidelijke berichten, waardoor corrigerende maatregelen worden voorgesteld en aangemoedigd.

De laatste stap is om de replicatie te starten met "start_replica", waarvan het succes wordt aangegeven door een uitvoerhint zoals hieronder weergegeven.

$> chameleon start_replica --config default --source mysql 
output: Starting the replica process for source mysql

De status van replicatie kan worden opgevraagd met het argument 'show_status', terwijl fouten kunnen worden bekeken met het argument 'show_errors'.

$> chameleon show_status --source mysql  
OUTPUT: 
  Source id  Source name    Type    Status    Consistent    Read lag    Last read    Replay lag    Last replay
-----------  -------------  ------  --------  ------------  ----------  -----------  ------------  -------------
          1  mysql          mysql   running   No            N/A                      N/A

== Schema mappings ==
Origin schema    Destination schema
---------------  --------------------
world_x          pgworld_x

== Replica status ==
---------------------  ---
Tables not replicated  0
Tables replicated      4
All tables             4
Last maintenance       N/A
Next maintenance       N/A
Replayed rows
Replayed DDL
Skipped rows
---------------------  ---
$> chameleon show_errors --config default 
output: There are no errors in the log

Zoals eerder besproken, wordt elk van de replicatiefunctionaliteit beheerd met behulp van daemons, die kunnen worden bekeken door de procestabel te doorzoeken met de Linux "ps"-opdracht, hieronder weergegeven.

$>  ps -ef|grep chameleon
root       763     1  0 19:20 ?        00:00:00 /u01/media/mysql_samp_dbs/world_x-db/venv/bin/python3.6 /u01/media/mysq l_samp_dbs/world_x-db/venv/bin/chameleon start_replica --config default --source mysql
root       764   763  0 19:20 ?        00:00:01 /u01/media/mysql_samp_dbs/world_x-db/venv/bin/python3.6 /u01/media/mysq l_samp_dbs/world_x-db/venv/bin/chameleon start_replica --config default --source mysql
root       765   763  0 19:20 ?        00:00:00 /u01/media/mysql_samp_dbs/world_x-db/venv/bin/python3.6 /u01/media/mysq l_samp_dbs/world_x-db/venv/bin/chameleon start_replica --config default --source mysql

De setup van de replicatie is pas compleet als deze wordt onderworpen aan de "real-time apply"-test, die is gesimuleerd zoals hieronder. Het omvat het maken van een tabel en het invoegen van een aantal records in de MySQL-database, vervolgens wordt het argument "sync_tables" van pg_chameleon aangeroepen om de daemons bij te werken om de tabel samen met zijn records te repliceren naar de PostgreSQL-database.

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.

De test wordt bevestigd door de tabel uit de PostgreSQL-database op te vragen om de rijen weer te geven.

$> psql -p 5433 -U usr_replica -d db_replica -c "select * from pgworld_x.t1";
 n1 |  n2
----+-------
  1 | one
  2 | two

Als het een migratieproject is, zullen de volgende pg_chameleon-opdrachten het einde van de migratie-inspanning markeren. De opdrachten moeten worden uitgevoerd nadat is bevestigd dat rijen van alle doeltabellen zijn gerepliceerd, en het resultaat is een netjes gemigreerde PostgreSQL-database zonder enige verwijzing naar de brondatabase of het replicatieschema (sch_chameleon).

$> chameleon stop_replica --config default --source mysql 
$> chameleon detach_replica --config default --source mysql --debug

Optioneel zullen de volgende opdrachten de bronconfiguratie en het replicatieschema laten vallen.

$> chameleon drop_source --config default --source mysql --debug
$> chameleon drop_replica_schema --config default --source mysql --debug

Voordelen van het gebruik van pg_chameleon

• Eenvoudig in te stellen en minder gecompliceerde configuratie
• Pijnloze probleemoplossing en detectie van afwijkingen met gemakkelijk te begrijpen foutoutput
• Extra adhoc-tabellen kunnen na initialisatie aan de replicatie worden toegevoegd, zonder enige andere configuratie te wijzigen
• Meerdere bronnen kunnen worden geconfigureerd voor een enkele doeldatabase, wat handig is bij consolidatieprojecten om gegevens uit een of meer MySQL-databases samen te voegen tot een enkele PostgreSQL-database
• Geselecteerde tabellen kunnen worden overgeslagen om te worden gerepliceerd

Nadelen van het gebruik van pg_chameleon

• Alleen ondersteund vanaf MySQL 5.5 als Origin-database en PostgreSQL 9.5 en later als bestemmingsdatabase
• Vereist dat elke tabel een primaire of unieke sleutel heeft, anders worden de tabellen geïnitialiseerd tijdens het init_replica-proces, maar kunnen ze niet worden gerepliceerd
• Replicatie in één richting, d.w.z. MySQL naar PostgreSQL. Waardoor het gebruik ervan wordt beperkt tot alleen een actief-passieve opstelling
• De brondatabase kan alleen een MySQL-database zijn, terwijl ondersteuning voor PostgreSQL-database als bron experimenteel is met verdere beperkingen (klik hier voor meer informatie)

pg_chameleon Samenvatting

De replicatieaanpak van pg_chameleon is gunstig voor een databasemigratie van MySQL naar PostgreSQL. Een van de belangrijke beperkingen van replicatie in één richting kan databaseprofessionals echter ontmoedigen om het voor iets anders dan migratie te gebruiken. Dit nadeel van unidirectionele replicatie kan worden verholpen met nog een andere open source-tool genaamd SymmetricDS.

Raadpleeg de officiële documentatie hier om het hulpprogramma meer in detail te bestuderen. De opdrachtregelreferentie kan hier worden verkregen.

Een overzicht van SymmetricDS

SymmetricDS is een open source-tool die in staat is om elke database naar elke andere database te repliceren, uit de populaire lijst met databaseservers zoals Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird en andere cloudgebaseerde database-instanties zoals Redshift en Azure enz. Sommige aanbiedingen omvatten database- en bestandssynchronisatie, multi-masterreplicatie, gefilterde synchronisatie en transformatie. De tool is ontwikkeld met Java en vereist een standaardeditie (versie 8.0 of hoger) van JRE of JDK. De functionaliteit houdt in dat gegevenswijzigingen worden vastgelegd door triggers in de brondatabase en deze als uitgaande batches naar een deelnemende bestemmingsdatabase routeren

Kenmerken van SymmetricDS

• Platformonafhankelijk, wat betekent dat twee of meer ongelijke databases met elkaar kunnen communiceren, elke database naar elke andere database
• Relationele databases bereiken synchronisatie met behulp van het vastleggen van wijzigingsgegevens, terwijl op bestandssysteem gebaseerde systemen gebruikmaken van bestandssynchronisatie
• Bidirectionele replicatie met behulp van de Push- en Pull-methode, die wordt bereikt op basis van vaste regels
• Gegevensoverdracht kan ook plaatsvinden via beveiligde netwerken met lage bandbreedte
• Automatisch herstel tijdens het hervatten van een gecrasht knooppunt en automatische conflictoplossing
• Gereed voor de cloud en bevat krachtige extensie-API's

Demo

SymmetricDS kan worden geconfigureerd in een van de twee opties:

• Een master (ouder) knooppunt dat fungeert als een gecentraliseerde tussenpersoon die gegevensreplicatie coördineert tussen twee slave (kind) knooppunten, waarbij de communicatie tussen de twee onderliggende knooppunten alleen via de bovenliggende knooppunten kan plaatsvinden.
• Een actief knooppunt (knooppunt1) kan zonder tussenpersoon repliceren van en naar een ander actief knooppunt (knooppunt 2).

In beide opties vindt de communicatie tussen de knooppunten plaats via "Push" en "Pull" -gebeurtenissen. In deze demo wordt een actief-actief configuratie tussen twee nodes uitgelegd. De volledige architectuur kan uitputtend zijn, dus de lezers worden aangemoedigd om de hier beschikbare gebruikershandleiding te raadplegen voor meer informatie over de interne onderdelen van SymmetricDS.

Het installeren van SymmetricDS is net zo eenvoudig als het downloaden van de open source-versie van het zip-bestand van hier en het uitpakken op een handige locatie. De details van de installatielocatie en versie van SymmetricDS in deze demo zijn zoals in de onderstaande tabel, samen met andere details met betrekking tot databaseversies, Linux-versies, ip-adressen en communicatiepoort voor beide deelnemende nodes.

De home-installatie is in dit geval "/usr/local/symmetric-server-3.9.20", de homedirectory van SymmetricDS, die verschillende andere subdirectory's en bestanden bevat. Twee van de subdirectories die nu van belang zijn, zijn "samples" en "engines". De map met voorbeelden bevat voorbeelden van configuratiebestanden van knooppunten en voorbeelden van SQL-scripts om een ​​snelle demo te starten.

De volgende drie configuratiebestanden voor knooppunteigenschappen zijn te zien in de map "samples" met namen die de aard van het knooppunt in een bepaalde opstelling aangeven.

corp-000.properties
store-001.properties
store-002.properties

Aangezien SymmetricDS wordt geleverd met alle benodigde configuratiebestanden om een ​​basisconfiguratie met 3 knooppunten (optie 1) te ondersteunen, is het handig om dezelfde configuratiebestanden te gebruiken om ook een installatie met 2 knooppunten (optie 2) in te stellen. Het beoogde configuratiebestand wordt gekopieerd van de map "samples" naar de "engines" op host vm1, en het ziet er als volgt uit.

$> 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=000

De naam van dit knooppunt in de SymmetricDS-configuratie is "corp-000" waarbij de databaseverbinding wordt afgehandeld met het mysql jdbc-stuurprogramma met behulp van de verbindingsreeks zoals hierboven vermeld, samen met inloggegevens. De database waarmee verbinding moet worden gemaakt is "replica_db" en de tabellen worden gemaakt tijdens het maken van een voorbeeldschema. De "sync.url" geeft de locatie aan om contact op te nemen met het knooppunt voor synchronisatie.

Het knooppunt 2 op host vm2 is geconfigureerd als "store-001" met de rest van de details zoals geconfigureerd in het bestand node.properties, hieronder weergegeven. Het knooppunt "store-001" voert een PostgreSQL-database uit, met "pgdb_replica" als de database voor replicatie. De "registration.url" stelt host "vm2" in staat om te communiceren met host "vm1" om configuratiedetails op te halen.

$> 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=001

De vooraf geconfigureerde standaarddemo van SymmetricDS bevat instellingen voor het opzetten van een bidirectionele replicatie tussen twee databaseservers (twee knooppunten). De onderstaande stappen worden uitgevoerd op host vm1 (corp-000), waarmee een voorbeeldschema met 4 tabellen wordt gemaakt. Verder zal de uitvoering van "create-sym-tables" met de opdracht "symadmin" de catalogustabellen creëren die de regels en de replicatierichting tussen knooppunten opslaan en controleren. Ten slotte worden de demotabellen geladen met voorbeeldgegevens.

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.sql

De demotabellen "item" en "item_selling_price" zijn automatisch geconfigureerd om te repliceren van corp-000 naar store-001, terwijl de verkooptabellen (sale_transaction en sale_return_line_item) automatisch worden geconfigureerd repliceren van store-001 naar corp-000. De volgende stap is het maken van het voorbeeldschema in de PostgreSQL-database op host vm2 (store-001), om het voor te bereiden op het ontvangen van gegevens van corp-000.

vm2$> cd /usr/local/symmetric-server-3.9.20/bin
vm2$> ./dbimport --engine store-001 --format XML create_sample.xml

Het is belangrijk om in dit stadium het bestaan ​​van demotabellen en SymmetricDS-catalogustabellen in de MySQL-database op vm1 te verifiëren. Let op, de SymmetricDS-systeemtabellen (tabellen met voorvoegsel "sym_") zijn op dit moment alleen beschikbaar in het corp-000-knooppunt, omdat daar de opdracht "create-sym-tables" werd uitgevoerd, wat de plaats zal zijn om de replicatie te controleren en te beheren. Daarnaast heeft de store-001 node-database slechts 4 demotabellen zonder gegevens erin.

De omgeving is nu klaar om de "sym"-serverprocessen op beide knooppunten te starten, zoals hieronder weergegeven.

vm1$> cd /usr/local/symmetric-server-3.9.20/bin
vm1$> sym 2>&1 &

De logboekvermeldingen worden zowel naar een achtergrondlogboekbestand (symmetric.log) onder een logboekmap in de SymmetricDS-installatielocatie als naar de standaarduitvoer verzonden. De "sym"-server kan nu worden gestart op store-001 node.

vm2$> cd /usr/local/symmetric-server-3.9.20/bin
vm2$> sym 2>&1 &

Het opstarten van het "sym"-serverproces op host vm2 zal ook de SymmetricDS-catalogustabellen in de PostgreSQL-database maken. Het opstarten van het "sym"-serverproces op beide knooppunten zorgt ervoor dat ze met elkaar coördineren om gegevens van corp-000 naar store-001 te repliceren. Na een paar seconden zal het bevragen van alle vier de tabellen aan weerszijden de succesvolle replicatieresultaten tonen. Als alternatief kan een initiële lading ook vanuit corp-000 naar het store-001-knooppunt worden verzonden met het onderstaande commando.

vm1$> ./symadmin --engine corp-000 reload-node 001

Op dit punt wordt een nieuw record ingevoegd in de "item" -tabel in de MySQL-database op corp-000-knooppunt (host:vm1) en kan worden geverifieerd dat het succesvol is gerepliceerd naar de PostgreSQL-database op winkel-001-knooppunt (host:vm2 ). Dit toont de "Pull"-gebeurtenis van gegevens van corp-000 naar 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)

De "Push"-gebeurtenis van gegevens van store-001 tot corp-000 kan worden bereikt door een record in de tabel "sale_transaction" in te voegen en deze te bevestigen om door te repliceren.

pgdb_replica=# insert into "sale_transaction" ("tran_id", "store_id", "workstation", "day", "seq") values (1000, '001', '3', '2007-11-01', 100);
vm1$> [[email protected] ~]#  mysql -uroot -p'admin123' -D replica_db -e "select * from sale_transaction";
+---------+----------+-------------+------------+-----+
| tran_id | store_id | workstation | day        | seq |
+---------+----------+-------------+------------+-----+
|     900 | 001      | 3           | 2012-12-01 |  90 |
|    1000 | 001      | 3           | 2007-11-01 | 100 |
|    2000 | 002      | 2           | 2007-11-01 | 200 |
+---------+----------+-------------+------------+-----+

Dit markeert de succesvolle configuratie van bidirectionele replicatie van demotabellen tussen een MySQL- en PostgreSQL-database. Terwijl de configuratie van replicatie voor nieuw gemaakte gebruikerstabellen kan worden bereikt met behulp van de volgende stappen. Er wordt een voorbeeldtabel "t1" gemaakt voor de demo en de regels voor de replicatie ervan worden geconfigureerd volgens de onderstaande procedure. De stappen configureren alleen de replicatie van corp-000 naar 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)

Hierna wordt de configuratie op de hoogte gebracht van de schemawijziging van het toevoegen van een nieuwe tabel door het symadmin-commando aan te roepen met het argument "sync-triggers", dat de triggers opnieuw zal maken om overeen te komen met tabeldefinities. Voer vervolgens "send-schema" uit om schemawijzigingen naar het winkel-001-knooppunt te verzenden, waarna de replicatie van de "t1"-tabel met succes wordt geconfigureerd.

vm1$> ./symadmin -e corp-000 --node=001 sync-triggers    
vm1$> ./symadmin send-schema -e corp-000 --node=001 t1

Voordelen van het gebruik van SymmetricDS

• Moeiteloze installatie en configuratie, inclusief een vooraf geconfigureerde set parameterbestanden om ofwel een installatie met 3 knooppunten of een installatie met 2 knooppunten te bouwen
• Cross-platform database ingeschakeld en platformonafhankelijk inclusief servers, laptops en mobiele apparaten
• Repliceer elke database naar elke andere database, of dit nu on-prem, WAN of cloud is
• In staat om een ​​aantal databases optimaal te verwerken tot enkele duizenden databases om gegevens naadloos te repliceren
• Een commerciële versie van de software biedt een GUI-gestuurde beheerconsole met een uitstekend ondersteuningspakket

Nadelen van het gebruik van SymmetricDS

• Handmatige opdrachtregelconfiguratie kan het definiëren van regels en de richting van replicatie inhouden via SQL-instructies om catalogustabellen te laden, wat onhandig kan zijn om te beheren
• Het opzetten van een groot aantal tabellen voor replicatie zal een uitputtende inspanning zijn, tenzij een of andere vorm van scripting wordt gebruikt om de SQL-instructies te genereren die regels en replicatierichting definiëren
• Veel loggegevens vervuilen het logbestand, waardoor periodiek onderhoud van het logbestand nodig is om te voorkomen dat het logbestand de schijf vol raakt

SymmetricDS-samenvatting

SymmetricDS biedt de mogelijkheid om bidirectionele replicatie in te stellen tussen 2 knooppunten, 3 knooppunten enzovoort voor enkele duizenden knooppunten om gegevens te repliceren en bestandssynchronisatie te bereiken. Het is een unieke tool die veel van de zelfherstellende onderhoudstaken uitvoert, zoals het automatisch herstellen van gegevens na langere perioden van downtime in een node, veilige en efficiënte communicatie tussen nodes met behulp van HTTPS en automatisch conflictbeheer op basis van vaste regels. , etc. The essential feature of replicating any database to any other database makes SymmetricDS ready to be deployed for a number of use cases including migration, version and patch upgrade, distribution, filtering and transformation of data across diverse platforms.

The demo was created by referring to the official quick-start tutorial of SymmetricDS which can be accessed from here. The user guide can be found here, which provides a detailed account of various concepts involved in a SymmetricDS replication setup.