Kruisreplicatie tussen PostgreSQL en MySQL

Ik zal in grote lijnen vertellen over kruisreplicatie tussen PostgreSQL en MySQL, en ook over de methoden om kruisreplicatie tussen deze twee databaseservers in te stellen. Gewoonlijk worden databases in kruisreplicatie homogeen genoemd, hetgeen een handige methode is om van de ene relationele DBMS-server naar de andere over te stappen.

PostgreSQL en MySQL worden beschouwd als relationele databases, maar met extra extensies bieden ze NoSQL-mogelijkheden. Hier zullen we de replicatie tussen PostgreSQL en MySQL bespreken vanuit het perspectief van relationele DBMS.

We zullen niet de volledige interne werking beschrijven, alleen de basisprincipes, zodat u een idee krijgt van het instellen van replicatie tussen databaseservers, de voordelen, beperkingen en gebruiksscenario's.

Gewoonlijk wordt replicatie tussen twee identieke databaseservers uitgevoerd in binair modus of via aanvragen tussen de actieve node (deze fungeert als uitgever) en de passieve node (deze fungert als abonnee). Het doel van replicatie is om in realtime een kopie van de hoofd database beschikbaar te stellen op de passieve zijde. In dit geval worden gegevens van de actieve naar de passieve node verzonden, omdat replicatie slechts in één richting plaatsvindt. Het is echter mogelijk om replicatie tussen twee databases in beide richtingen in te stellen, zodat gegevens van de passieve naar de actieve node worden verzonden in een “actief-actief” configuratie. Dit alles, inclusief cascade-replicatie, is mogelijk tussen twee of meer identieke databaseservers. De configuratie “actief-actief” of “actief-passief” hangt af van de behoeften, de beschikbaarheid van dergelijke mogelijkheden in de oorspronkelijke configuratie of het gebruik van externe oplossingen voor de instelling en de bestaande compromissen.

De beschreven configuratie is mogelijk tussen verschillende databaseservers. Een server kan worden ingesteld om gerepliceerde gegevens van een andere databaseserver te ontvangen en tegelijkertijd snapshots van de gerepliceerde gegevens in realtime te behouden. MySQL en PostgreSQL bieden de meeste van deze configuraties zelf of met behulp van externe extensies, inclusief methoden zoals binaire logbestanden, schijfvergrendeling en operator- en rijgebaseerde methoden.

Cross-replicatie tussen MySQL en PostgreSQL is nodig voor een eenmalige migratie van de ene database server naar de andere. Deze databases gebruiken verschillende protocollen, dus je kunt ze niet rechtstreeks aan elkaar koppelen. Om data-uitwisseling mogelijk te maken, kan een externe open-source tool worden gebruikt, zoals pg_chameleon.

Wat is pg_chameleon

pg_chameleon is een replicatiesysteem van MySQL naar PostgreSQL geschreven in Python 3. Het maakt gebruik van de open-source bibliotheek mysql-replication, ook in Python. Rij-afbeeldingen worden geëxtraheerd uit MySQL-tabellen en opgeslagen als JSONB-objecten in de PostgreSQL-database, en worden vervolgens gedecodeerd met de pl/pgsql-functie en weergeven in de PostgreSQL-database.

Capaciteiten van pg_chameleon

Meerdere MySQL-schema's uit één cluster kunnen worden gerepliceerd naar één doel PostgreSQL-database met een 'een naar veel'-configuratie.
De namen van de bron- en doelschema's mogen niet gelijk zijn.
Replicatiegegevens kunnen worden geëxtraheerd uit een cascade-replicatie van MySQL.
Tabellen die niet gerepliceerd kunnen worden of fouten veroorzaken, worden uitgesloten.
Elke replicatiefunctie wordt beheerd door demons.
Controle via parameters en configuratiebestanden op basis van YAML.

Voorbeeld

Host
vm1
vm2

Versie van het besturingssysteem
CentOS Linux 7.6 x86_64
CentOS Linux 7.5 x86_64

Versie van de database server
MySQL 5.7.26
PostgreSQL 10.5

Databasepoort
3306
5433

IP-adres
192.168.56.102
192.168.56.106

Bereid eerst alle benodigde componenten voor om pg_chameleon te installeren. In dit voorbeeld is Python 3.6.8 geïnstalleerd, dat een virtuele omgeving creëert en activeert.

$> 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 Python 3.6 moeten de overige vereisten worden uitgevoerd, zoals het creëren en activeren van een virtuele omgeving. Daarnaast wordt de pip-module bijgewerkt naar de laatste versie en gebruikt voor de installatie van pg_chameleon. In de onderstaande opdrachten wordt opzettelijk pg_chameleon 2.0.9 geïnstalleerd, hoewel de laatste versie 2.0.10 is. Dit is nodig om nieuwe bugs in de bijgewerkte versie te vermijden.

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

Vervolgens roepen we pg_chameleon aan (chameleon is de opdracht) met het argument set_configuration_files om pg_chameleon in te schakelen en de standaardconfiguratiebestanden en -mappen te creëren.

(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/
copiën van de configuratievoorbeeld in /root/.pg_chameleon/configuration//config-example.yml

Nu maken we een kopie van config-example.yml als default.yml, zodat het het standaard configuratiebestand wordt. Een voorbeeld van dit configuratiebestand wordt hieronder gegeven.

$> cat default.yml
---
# globale instellingen
pid_dir: '~/.pg_chameleon/pid/'
log_dir: '~/.pg_chameleon/logs/'
log_dest: bestand
log_level: info
log_days_keep: 10
rollbar_key: ''
rollbar_env: ''

# type_override stelt de gebruiker in staat om de standaard typeconversie naar een ander type te overschrijven.
type_override:
  "tinyint(1)":
    override_to: boolean
    override_tables:
      - "*"

# postgres bestemmingsverbinding
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 dag'
    copy_max_memory: "300M"
    copy_mode: 'bestand'
    out_dir: /tmp
    sleep_loop: 1
    on_error_replay: doorgaan
    on_error_read: doorgaan
    auto_maintenance: "uit"
    gtid_enable: Nee
    type: mysql
    skip_events:
      invoegen:
        - delphis_mediterranea.foo # slaat invoegen over op de tabel delphis_mediterranea.foo
      verwijderen:
        - delphis_mediterranea # slaat verwijderen over op schema delphis_mediterranea
      bijwerken:

Het configuratiebestand in dit voorbeeld is een voorbeeldbestand van pg_chameleon met enkele kleine wijzigingen volgens de oorspronkelijke en doelomgevingen. Hieronder wordt een overzicht gegeven van de verschillende secties van het configuratiebestand.

In het configuratiebestand default.yml is er een sectie voor globale parameters (global settings), waar u instellingen zoals de locatie van het lock-bestand, de locatie van logs, de logbewaarperiode enzovoort kunt beheren. Vervolgens is er een sectie voor type-overrides (type override), waar een set regels is voor het overschrijven van types tijdens replicatie. In het standaardvoorbeeld wordt de type-overrule gebruikt die tinyint(1) omzet in een booleanwaarde. In de volgende sectie geven we de verbindingsdetails op voor de doeldatabase. In ons geval is dit een PostgreSQL-database, aangeduid als pg_conn. In de laatste sectie geven we de gegevens van de bron op, dat wil zeggen de verbindingsparameters voor de brondatabase, de schema-mapping van de brondatabase naar de doeldatabase, de tabellen die overgeslagen moeten worden, timeouts, geheugen, en de batchgrootte. Merk op dat "sources" in het meervoud is, wat betekent dat we meerdere brondatabases voor één doel kunnen toevoegen om de configuratie "veel-tot-een" in te stellen.

De world_x-database in het voorbeeld bevat 4 tabellen met rijen die de MySQL-gemeenschap ter illustratie aanbiedt. Deze kan worden gedownload hier. De voorbeelddatabase wordt geleverd in de vorm van een tar- en gecomprimeerd archief met instructies voor het aanmaken en importeren van de rijen.

In MySQL- en PostgreSQL-databases wordt een speciale gebruiker met de naam usr_replica aangemaakt. In MySQL krijgt deze extra rechten om alle gerepliceerde tabellen te lezen.

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;

Aan de PostgreSQL-zijde wordt er een database db_replica aangemaakt, die wijzigingen uit de MySQL-database zal ontvangen. De gebruiker usr_replica in PostgreSQL wordt automatisch ingesteld als eigenaar van de twee schema's pgworld_x en sch_chameleon, die respectievelijk de werkelijke gerepliceerde tabellen en de replicatiecatalogustabellen bevatten. De automatische configuratie wordt geregeld door het argument create_replica_schema, zoals je hieronder zult zien.

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

De MySQL-database wordt ingesteld met wijzigingen aan enkele parameters om deze voor replicatie voor te bereiden, zoals hieronder weergegeven. Het zal nodig zijn om de databaseserver opnieuw op te starten om de wijzigingen door te voeren.

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

Het is nu belangrijk om de verbinding met beide databaseservers te controleren, zodat er geen problemen optreden bij het uitvoeren van pg_chameleon-commando's.

Op de PostgreSQL-node:

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

Op de MySQL-node:

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

De volgende drie pg_chameleon (chameleon) commando's bereiden de omgeving voor, voegen de bron toe en initialiseren de replicatie. Het argument create_replica_schema in pg_chameleon creëert het standaardschema (sch_chameleon) en het replicatieschema (pgworld_x) in de PostgreSQL-database, zoals we al zeiden. Het argument add_source voegt de oorspronkelijke database toe aan de configuratie door het configuratiebestand (default.yml) te lezen, in ons geval is dat mysql, en init_replica initialiseert de configuratie op basis van de parameters in 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 deze drie commando's geeft duidelijk aan dat ze succesvol zijn uitgevoerd. Alle fouten of syntactische problemen worden aangegeven in eenvoudige en begrijpelijke berichten met suggesties voor het oplossen van problemen.

Laten we eindelijk de replicatie starten met behulp van start_replica en een bericht over een succesvolle uitvoering ontvangen.

$> chameleon start_replica --config default --source mysql 
output: De replica-proces voor de source mysql wordt gestart.

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

Resultaat.

Zoals we al zeiden, worden elke replicatiefunctie beheerd door demonprocessen. Om ze te bekijken, vragen we de proceslijst op met het Linux-commando ps, zoals hieronder weergegeven.

Resultaat.

Replicatie wordt niet als ingesteld beschouwd totdat we deze in realtime testen, zoals hieronder weergegeven. We maken een tabel, voegen een paar records toe aan de MySQL-database en roepen het argument sync_tables in pg_chameleon aan om de demonen bij te werken en de tabel met records in de PostgreSQL-database te repliceren.

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 proces voor de source mysql gestart.

Om de testresultaten te bevestigen, vragen we de tabel op uit de PostgreSQL-database en geven we de rijen weer.

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

Als we migreren, vormen de volgende pg_chameleon commando's de afronding. De commando's moeten worden uitgevoerd nadat we hebben bevestigd dat de rijen van alle doel-tabellen zijn gerepliceerd, met als resultaat een netjes overgedragen PostgreSQL-database zonder verwijzingen naar de oorspronkelijke database of replicatieschema (sch_chameleon).

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

Optioneel kunnen de volgende commando's de oorspronkelijke configuratie en het replicatieschema verwijderen.

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

Voordelen van pg_chameleon

Eenvoudige installatie en configuratie.
Gebruiksvriendelijke foutopsporing en anomaliedetectie met begrijpelijke foutmeldingen.
Er kunnen extra speciale tabellen aan de replicatie worden toegevoegd na de initiatie, zonder de rest van de configuratie te veranderen.
U kunt meerdere brondatabases voor één doeldatabase instellen, wat zeer handig is wanneer u gegevens uit een of meerdere MySQL-databases naar één PostgreSQL-database samenvoegt.
Geselecteerde tabellen hoeven niet te worden gerepliceerd.

Nadelen van pg_chameleon

Wordt alleen ondersteund met MySQL 5.5 en hoger als bron en PostgreSQL 9.5 en hoger als doel database.
Elke tabel moet een primaire of unieke sleutel hebben, anders worden de tabellen geïnitialiseerd tijdens het init_replica-proces, maar worden ze niet gerepliceerd.
Eensluidende replicatie — alleen van MySQL naar PostgreSQL. Het is dus alleen geschikt voor een ‘actief-passief’ schema.
Het kan alleen een MySQL-database als bron zijn, en de ondersteuning voor PostgreSQL als bron is alleen experimenteel en met beperkingen (lees meer hier)

Samenvattingen van pg_chameleon

De replicatiemethode in pg_chameleon is uitstekend voor de migratie van een database van MySQL naar PostgreSQL. Een belangrijke nadeel is dat de replicatie alleen eenzijdig is, waardoor database-experts het waarschijnlijk niet willen gebruiken voor iets anders dan migratie. Maar het probleem van eenzijdige replicatie kan worden opgelost met een ander open-source hulpmiddel — SymmetricDS.

Lees meer in de officiële documentatie hier. De hulpprogramma's voor de opdrachtregel zijn te vinden hier.

Overzicht van SymmetricDS

SymmetricDS is een open-source tool die elke database naar elke andere gangbare database repliceert: Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird en andere cloud database-instanties, zoals Redshift, Azure, enz. Beschikbare functies: database- en bestandssynchronisatie, replicatie van meerdere leidende databases, gefilterde synchronisatie, transformatie en meer. Het is een Java-tool en vereist een standaardversie van JRE of JDK (versie 8.0 of hoger). Hier kunnen gegevenswijzigingen via triggers in de brondatabase worden vastgelegd en naar de overeenkomstige doeldatabase in de vorm van batches worden gestuurd.

Functionaliteiten van SymmetricDS

De tool is platformonafhankelijk, wat betekent dat twee of meer verschillende databases gegevens kunnen uitwisselen.
Relationele databases worden gesynchroniseerd door middel van het vastleggen van gegevenswijzigingen, terwijl bestandsgebaseerde databases gebruikmaken van bestandsynchronisatie.
Tweedirectionele replicatie met behulp van Push- en Pull-methoden op basis van een set regels.
Gegevensoverdracht is mogelijk via beveiligde netwerken en netwerken met een lage bandbreedte.
Automatisch herstel bij het hervatten van de werking van nodes na een storing en automatische conflictresolutie.
Compatibiliteit met de cloud en efficiënte API-extensies.

Voorbeeld

SymmetricDS kan worden geconfigureerd in een van de twee opties:
Een hoofd (ouder) node die centraal de gegevensreplicatie coördineert tussen twee ondergeschikte (kind) nodes, en de gegevensuitwisseling tussen de kind nodes vindt uitsluitend plaats via de ouder.
Een actieve node (node 1) kan gegevens voor replicatie uitwisselen met een andere actieve node (node 2) zonder tussenpersoon.

In beide opties vindt de gegevensuitwisseling plaats via Push en Pull. In dit voorbeeld bekijken we de 'actieve-actieve' configuratie. Het is te lang om de gehele architectuur te beschrijven, dus bestudeer handboek, om meer te leren over de werking van SymmetricDS.

Het installeren van SymmetricDS is heel eenvoudig: download de open-source versie van het zip-bestand hier en pak deze uit waar je maar wilt. In de onderstaande tabel vind je informatie over de installatieplaats en versie van SymmetricDS in dit voorbeeld, evenals versies van databases, versies van Linux, IP-adressen en poorten voor beide nodes.

Host
vm1
vm2

Versie van het besturingssysteem
CentOS Linux 7.6 x86_64
CentOS Linux 7.6 x86_64

Versie van de database server
MySQL 5.7.26
PostgreSQL 10.5

Databasepoort
3306
5832

IP-adres
192.168.1.107
192.168.1.112

Versie van SymmetricDS
SymmetricDS 3.9
SymmetricDS 3.9

Installatiepad van SymmetricDS
/usr/local/symmetric-server-3.9.20
/usr/local/symmetric-server-3.9.20

Naam van de SymmetricDS node
corp-000
store-001

Hier installeren we SymmetricDS in /usr/local/symmetric-server-3.9.20, en hier zullen verschillende geneste mappen en bestanden worden opgeslagen. We zijn geïnteresseerd in de geneste mappen samples en engines. In de map samples bevinden zich voorbeeldconfiguratiebestanden met node-eigenschappen, evenals voorbeeld SQL-scripts voor een snelle start bij de demonstratie.

In de map samples zien we drie configuratiebestanden met node-eigenschappen - de naam geeft het karakter van de node in een bepaalde schema aan.

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

SymmetricDS heeft alle benodigde configuratiebestanden voor een basis schema van 3 nodes (optie 1), en dezelfde bestanden kunnen worden gebruikt voor een schema van 2 nodes (optie 2). We kopiëren het benodigde configuratiebestand van de map samples naar engines op host vm1. Dit wordt als volgt:

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

Deze node in de SymmetricDS-configuratie wordt corp-000 genoemd, en de verbinding met de database wordt beheerd door de mysql jdbc-driver, die de hierboven genoemde verbindingsstring en inloggegevens gebruikt. We verbinden met de database replica_db, en tijdens het aanmaken van het schema worden de tabellen aangemaakt. sync.url toont de verbinding met de node voor synchronisatie.

Node 2 op host vm2 wordt ingesteld als store-001, en de rest is gespecificeerd in het node.properties-bestand, dat hieronder wordt weergegeven. Node store-001 draait op een PostgreSQL-database, en pgdb_replica is de database voor replicatie. registration.url stelt host vm2 in staat om verbinding te maken met host vm1 en de configuratiedetails te ontvangen.

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

Het voorbeeld van SymmetricDS bevat parameters voor het instellen van bidirectionele replicatie tussen twee databaseservers (twee nodes). De onderstaande stappen worden uitgevoerd op host vm1 (corp-000), die een voorbeeldschema met 4 tabellen aanmaakt. Vervolgens creëert het uitvoeren van create-sym-tables met het commando symadmin de catalogustabellen, waar de regels en richting van replicatie tussen nodes worden opgeslagen. Ten slotte worden voorbeeldgegevens in de tabellen geladen.

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

In het voorbeeld zijn de tabellen item en item_selling_price automatisch ingesteld voor replicatie van corp-000 naar store-001, terwijl de tabellen sale (sale_transaction en sale_return_line_item) automatisch zijn ingesteld voor replicatie van store-001 naar corp-000. Laten we nu een schema aanmaken in de PostgreSQL-database op host vm2 (store-001) om deze voor te bereiden op de ontvangst 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

Zorg ervoor dat er in de MySQL-database op vm1 voorbeeldtabellen en de catalogustabellen van SymmetricDS aanwezig zijn. Merk op dat de systeemtabel van SymmetricDS (met het prefix sym_) momenteel alleen beschikbaar is op node corp-000, omdat daar het commando create-sym-tables is uitgevoerd en wij de replicatie zullen beheren. Bovendien zullen er in de database op node store-001 slechts 4 voorbeeldtabellen zonder gegevens zijn.

Klaar. De omgeving is klaar om de serverprocessen van sym op beide nodes uit te voeren, zoals hieronder weergegeven.

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

Logboeken worden verzonden naar het achtergrondlogbestand (symmetric.log) in de logmap in de directory waar SymmetricDS is geïnstalleerd, en ook naar de standaard uitvoer. De sym-server kan nu worden gestart op de node store-001.

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

Wanneer het serverproces sym wordt uitgevoerd op de host vm2, worden de SymmetricDS-directorytabellen ook in de PostgreSQL-database aangemaakt. Als het serverproces sym op beide nodes wordt uitgevoerd, coördineren ze met elkaar om gegevens van corp-000 naar store-001 te repliceren. Na enkele seconden, als we alle 4 tabellen aan beide zijden opvragen, zien we dat de replicatie succesvol is uitgevoerd. Of we kunnen een initiële gegevenslading naar node store-001 vanaf corp-000 verzenden met het volgende commando.

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

Op dit punt wordt er een nieuwe record in de tabel item van de MySQL-database op node corp-000 (host: vm1) ingevoegd, en we kunnen de replicatie ervan in de PostgreSQL-database op node store-001 (host: vm2) controleren. We zien een Pull-operatie om gegevens van corp-000 naar store-001 te verplaatsen.

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)

Om de Push-operatie uit te voeren voor het verplaatsen van gegevens van store-001 naar corp-000, voegen we een record toe aan de tabel sale_transaction en controleren we of de replicatie is uitgevoerd.

Resultaat.

We zien een succesvolle configuratie van tweezijdige replicatie van de voorbeeldtabellen tussen de MySQL- en PostgreSQL-databases. Om replicatie voor nieuwe klanttabellen in te stellen, voeren we de volgende stappen uit. We creëren tabel t1 voor het voorbeeld en stellen de replicatieregels als volgt in. Zo stellen we alleen de replicatie van corp-000 naar store-001 in.

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)

Vervolgens ontvangt de configuratie een melding van de wijziging in het schema, dat wil zeggen de toevoeging van een nieuwe tabel, via het commando symadmin met het argument sync-triggers, dat de triggers opnieuw aanmaakt om de tabeldefinities te matchen. send-schema wordt uitgevoerd om de schemawijzigingen naar de node store-001 te verzenden, en de replicatie van tabel t1 is ingesteld.

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

Voordelen van SymmetricDS

Eenvoudige installatie en configuratie, inclusief een kant-en-klaar pakket met bestanden met parameters voor het creëren van een schema met drie of twee nodes.
Platformonafhankelijkheid van databases en onafhankelijkheid van platformen, inclusief servers, laptops en mobiele apparaten.
Replicatie van elke database naar een andere database, lokaal, in WAN of in de cloud.
Mogelijkheid voor optimale werking met een paar databases of duizenden voor gebruiksvriendelijke replicatie.
Betaalde versie met grafische interface en uitstekende ondersteuning.

Nadelen van SymmetricDS

Regels en richting van replicatie moeten handmatig in de opdrachtregel worden gedefinieerd via SQL-operators voor het laden van catalogustabellen, wat soms ongemakkelijk is.
Het kan vermoeiend zijn om veel tabellen voor replicatie in te stellen, tenzij er scripts worden gebruikt om SQL-operators te creëren die de regels en richting van replicatie definiëren.
Er wordt te veel informatie in de logs geregistreerd, en soms moet je de logbestanden opruimen zodat ze niet te veel ruimte innemen.

Conclusies over SymmetricDS

SymmetricDS maakt het mogelijk om bidirectionele replicatie in te stellen tussen twee, drie en zelfs meerdere duizenden nodes om replicatie en bestandssynchronisatie uit te voeren. Het is een uniek instrument dat veel taken zelfstandig uitvoert, zoals het automatisch herstellen van gegevens na een lange periode van inactiviteit op een node, veilige en efficiënte gegevensuitwisseling tussen nodes via HTTPS, automatisch beheer van conflicten op basis van een set regels, enzovoort. SymmetricDS voert replicatie uit tussen elke databases, waardoor het voor verschillende scenario's kan worden gebruikt, inclusief migratie, upgrade, distributie, filtering en gegevensconversie op verschillende platforms.

Het voorbeeld is gemaakt op basis van de officiële korte handleiding voor SymmetricDS. In de gebruikershandleiding verschillende concepten die verband houden met het configureren van replicatie met behulp van SymmetricDS, worden in detail beschreven.

Bron: habr.com