Kruisreplicatie tussen PostgreSQL en MySQL

Kruisreplicatie tussen PostgreSQL en MySQL

Ik zal kruisreplicatie tussen PostgreSQL en MySQL schetsen, evenals methoden voor het opzetten van kruisreplicatie tussen de twee databaseservers. Doorgaans worden kruislings gerepliceerde databases homogeen genoemd, en het is een handige methode om van de ene RDBMS-server naar de andere te gaan.

PostgreSQL- en MySQL-databases worden over het algemeen als relationeel beschouwd, maar met extra uitbreidingen bieden ze NoSQL-mogelijkheden. Hier bespreken we replicatie tussen PostgreSQL en MySQL vanuit een relationeel DBMS-perspectief.

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

Normaal gesproken wordt replicatie tussen twee identieke databaseservers uitgevoerd in binaire modus of met behulp van query's tussen een master (ook wel uitgever, master of actief genoemd) en een slaaf (abonnee, stand-by of passief). Het doel van replicatie is het verschaffen van een real-time kopie van de masterdatabase aan de slavezijde. In dit geval worden gegevens overgedragen van master naar slave, dat wil zeggen van actief naar passief, omdat replicatie slechts in één richting wordt uitgevoerd. Maar u kunt replicatie tussen twee databases in beide richtingen instellen, zodat gegevens in een actief-actief-configuratie van slave naar master worden overgedragen. Dit alles, inclusief trapsgewijze replicatie, is mogelijk tussen twee of meer identieke databaseservers. Actief-actief of actief-passief configureren is afhankelijk van de behoefte, beschikbaarheid van dergelijke mogelijkheden in de initiële configuratie of het gebruik van externe configuratieoplossingen en bestaande afwegingen.

De beschreven configuratie is mogelijk tussen verschillende databaseservers. De server kan worden geconfigureerd om gerepliceerde gegevens van een andere databaseserver te accepteren en toch realtime momentopnamen van de gerepliceerde gegevens bij te houden. MySQL en PostgreSQL bieden de meeste van deze configuraties intern of via extensies van derden, waaronder binaire logmethoden, schijfvergrendeling en op instructies en rijen gebaseerde methoden.

Voor een eenmalige migratie van de ene databaseserver naar de andere is kruisreplicatie tussen MySQL en PostgreSQL nodig. Deze databases gebruiken verschillende protocollen, waardoor het niet mogelijk is om ze direct te koppelen. Om gegevensuitwisseling tot stand te brengen, kunt u een externe open source-tool gebruiken, bijvoorbeeld pg_chameleon.

Wat is pg_chameleon

pg_chameleon is een replicatiesysteem van MySQL naar PostgreSQL in Python 3. Het maakt gebruik van de open source mysql-replicatiebibliotheek, ook in Python. Rijafbeeldingen worden geëxtraheerd uit MySQL-tabellen en opgeslagen als JSONB-objecten in de PostgreSQL-database, en vervolgens gedecodeerd door de pl/pgsql-functie en gereproduceerd in de PostgreSQL-database.

Kenmerken van pg_chameleon

Meerdere MySQL-schema's uit hetzelfde cluster kunnen worden gerepliceerd naar een enkele PostgreSQL-doeldatabase in een één-op-veel-configuratie
De namen van het bron- en doelschema mogen niet hetzelfde zijn.
Replicatiegegevens kunnen worden opgehaald uit een trapsgewijze MySQL-replica.
Tabellen die geen fouten kunnen reproduceren of produceren, zijn uitgesloten.
Elke replicatiefunctie wordt bestuurd door daemons.
Controle via YAML-gebaseerde parameters en configuratiebestanden.

Voorbeeld

Gastheer
vm1
vm2

OS-versie
CentOS Linux 7.6 x86_64
CentOS Linux 7.5 x86_64

DB-serverversie
MySQL 5.7.26
PostgreSQL 10.5

DB-poort
3306
5433

IP-adres
192.168.56.102
192.168.56.106

Bereid om te beginnen alle benodigde componenten voor om pg_chameleon te installeren. In dit voorbeeld wordt Python 3.6.8 geïnstalleerd, waarmee de virtuele omgeving wordt gemaakt en 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

Nadat u Python3.6 succesvol hebt geïnstalleerd, moet u aan de resterende vereisten voldoen, zoals het maken en activeren van een virtuele omgeving. Bovendien wordt de pip-module bijgewerkt naar de nieuwste versie en gebruikt om pg_chameleon te installeren. Met de onderstaande opdrachten wordt opzettelijk pg_chameleon 2.0.9 geïnstalleerd, hoewel de nieuwste versie 2.0.10 is. Dit is nodig om nieuwe 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

Vervolgens roepen we pg_chameleon aan (chameleon is een commando) met het set_configuration_files argument om pg_chameleon in te schakelen en 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

Nu maken we een kopie van config-example.yml als default.yml, zodat dit het standaardconfiguratiebestand wordt. Hieronder vindt u een voorbeeldconfiguratiebestand voor dit voorbeeld.

$> 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 in dit voorbeeld is een voorbeeld van een pg_chameleon-bestand met kleine aanpassingen om aan de bron- en doelomgeving te voldoen. Hieronder vindt u een overzicht van de verschillende secties van het configuratiebestand.

In het standaard.yml-configuratiebestand bevindt zich een sectie met algemene instellingen, waar u instellingen kunt beheren zoals de locatie van het vergrendelingsbestand, de locatie van logs, de opslagperiode voor logs, enz. Vervolgens komt de sectie voor het overschrijven van typen, waar een set regels voor het overschrijven van typen tijdens replicatie. In het voorbeeld wordt standaard een type-overschrijvende regel gebruikt die tinyint(1) omzet naar een Booleaanse waarde. In de volgende sectie specificeren we de verbindingsdetails met de doeldatabase. In ons geval is dit een PostgreSQL-database, genaamd pg_conn. In de laatste sectie geven we de brongegevens aan, dat wil zeggen de verbindingsparameters van de brondatabase, het toewijzingsschema tussen de bron- en doeldatabases, tabellen die moeten worden overgeslagen, wachttijd, geheugen, pakketgrootte. Houd er rekening mee dat 'bronnen' meervoud is, wat betekent dat we meerdere brondatabases kunnen toevoegen aan een enkele doeldatabase om een ​​veel-op-een-configuratie op te zetten.

De voorbeelddatabase world_x bevat 4 tabellen met rijen die de MySQL-gemeenschap als voorbeeld aanbiedt. Het kan worden gedownload hier. De voorbeelddatabase wordt geleverd als een tar- en gecomprimeerd archief met instructies voor het maken en importeren van rijen.

In MySQL- en PostgreSQL-databases wordt een speciale gebruiker aangemaakt met dezelfde naam usr_replica. In MySQL krijgt het extra leesrechten voor alle gerepliceerde tabellen.

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-kant wordt een db_replica-database gemaakt die wijzigingen uit de MySQL-database accepteert. De gebruiker usr_replica in PostgreSQL wordt automatisch geconfigureerd als de eigenaar van twee schema's, pgworld_x en sch_chameleon, die respectievelijk de daadwerkelijk gerepliceerde tabellen en de replicatiemaptabellen bevatten. Het argument create_replica_schema is verantwoordelijk voor de automatische configuratie, zoals u 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 is geconfigureerd met enkele parameterwijzigingen om deze voor te bereiden op replicatie, zoals hieronder weergegeven. U moet de databaseserver opnieuw opstarten om de wijzigingen door te voeren.

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

Nu is het belangrijk om de verbinding met beide databaseservers te controleren, zodat er geen problemen optreden bij het uitvoeren van de pg_chameleon-opdrachten.

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 pg_chameleon-opdrachten (kameleon) bereiden de omgeving voor, voegen de bron toe en initialiseren de replica. Het create_replica_schema argument voor pg_chameleon creëert een standaardschema (sch_chameleon) en een replicatieschema (pgworld_x) in de PostgreSQL-database, zoals we al hebben besproken. Het add_source argument voegt een brondatabase toe aan de configuratie door het configuratiebestand (default.yml) te lezen, en in ons geval is dit 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 opdrachten geeft duidelijk aan dat ze met succes zijn uitgevoerd. Eventuele crashes of syntaxisfouten worden gerapporteerd in eenvoudige, duidelijke berichten met tips over hoe u het probleem kunt oplossen.

Ten slotte starten we de replicatie met start_replica en ontvangen we een succesbericht.

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

De replicatiestatus kan worden opgevraagd met behulp van het argument show_status, en fouten kunnen worden bekeken met het argument show_errors.

Het resultaat.

Zoals we al zeiden, wordt elke replicatiefunctie bestuurd door daemons. Om ze te bekijken, doorzoeken we de procestabel met de Linux ps-opdracht, zoals hieronder weergegeven.

Het resultaat.

Replicatie wordt pas als geconfigureerd beschouwd als we deze in realtime testen, zoals hieronder weergegeven. We maken een tabel, voegen een paar records in de MySQL-database in en roepen het sync_tables-argument in pg_chameleon aan om de daemons bij te werken en de tabel met de 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.

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

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

Als we een migratie uitvoeren, zullen de volgende pg_chameleon-opdrachten het einde ervan zijn. De opdrachten moeten worden uitgevoerd nadat we er zeker van zijn dat de rijen van alle doeltabellen zijn gerepliceerd, en het resultaat zal een netjes gemigreerde PostgreSQL-database zijn zonder verwijzingen naar de brondatabase of het replicatieschema (sch_chameleon).

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

Indien gewenst kunt u de volgende opdrachten gebruiken om het oorspronkelijke configuratie- en replicatieschema te 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.
Los problemen eenvoudig op en identificeer afwijkingen met duidelijke foutmeldingen.
Na de initialisatie kunnen extra speciale tabellen aan de replicatie worden toegevoegd zonder de rest van de configuratie te wijzigen.
Het is mogelijk om meerdere brondatabases te configureren voor een enkele doeldatabase, en dit is erg handig als u gegevens uit een of meer MySQL-databases combineert in een enkele PostgreSQL-database.
U hoeft de geselecteerde tabellen niet te repliceren.

Nadelen van pg_chameleon

Alleen ondersteund met MySQL 5.5 en hoger als bron en PostgreSQL 9.5 en hoger als doeldatabase.
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.
Replicatie in één richting - alleen van MySQL naar PostgreSQL. Daarom is het alleen geschikt voor het “actief-passieve” circuit.
De bron kan alleen een MySQL-database zijn, en ondersteuning voor een PostgreSQL-database als bron is alleen experimenteel en met beperkingen (meer informatie hier)

Resultaten voor pg_chameleon

De replicatiemethode in pg_chameleon is ideaal voor het migreren van een database van MySQL naar PostgreSQL. Het grote nadeel is dat replicatie slechts in één richting plaatsvindt, waardoor databaseprofessionals het waarschijnlijk niet voor iets anders dan migratie willen gebruiken. Maar het probleem van eenrichtingsreplicatie kan worden opgelost met een andere open source-tool: SymmetricDS.

Lees meer in de officiële documentatie hier. Hulp bij de opdrachtregel is te vinden hier.

Overzicht van SymmetricDS

SymmetricDS is een open source-tool die elke database repliceert naar elke andere veel voorkomende database: Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird en andere clouddatabase-instanties, bijvoorbeeld Redshift, en Azure, etc. Beschikbare functies: database- en bestandssynchronisatie, multi-master databasereplicatie, gefilterde synchronisatie, transformatie en andere. Dit is een Java-tool en vereist een standaardversie van JRE of JDK (versie 8.0 of hoger). Hier kunnen gegevenswijzigingen van triggers in de brondatabase worden geregistreerd en in de vorm van batches naar de betreffende doeldatabase worden verzonden.

SymmetricDS-functies

De tool is platformonafhankelijk, wat betekent dat twee of meer verschillende databases gegevens kunnen uitwisselen.
Relationele databases worden gesynchroniseerd met behulp van gegevenswijzigingsrecords, terwijl op bestandssysteem gebaseerde databases bestandssynchronisatie gebruiken.
Tweerichtingsreplicatie met behulp van Push- en Pull-methoden op basis van een reeks regels.
Gegevensoverdracht is mogelijk via beveiligde netwerken met een lage bandbreedte.
Automatisch herstel wanneer knooppunten de werking hervatten na een storing en automatische conflictoplossing.
Cloud-compatibele en krachtige uitbreidings-API's.

Voorbeeld

SymmetricDS kan op twee manieren worden geconfigureerd:
Een masterknooppunt (ouderknooppunt) dat de gegevensreplicatie tussen twee slaafknooppunten (onderliggend knooppunt) centraal coördineert, en communicatie tussen kindknooppunten vindt alleen plaats via het ouderknooppunt.
Een actief knooppunt (knooppunt 1) kan zonder tussenpersoon voor replicatie communiceren met een ander actief knooppunt (knooppunt 2).

Bij beide opties vindt de gegevensuitwisseling plaats via Push en Pull. In dit voorbeeld beschouwen we een actief-actief-configuratie. Het zou te lang duren om de hele architectuur te beschrijven, dus doe je onderzoek. руководствоvoor meer informatie over het SymmetricDS-apparaat.

Het installeren van SymmetricDS is heel eenvoudig: download de open source-versie van het zipbestand vandaar en haal hem eruit waar je maar wilt. De onderstaande tabel geeft informatie over de installatielocatie en versie van SymmetricDS in dit voorbeeld, evenals de databaseversies, Linux-versies, IP-adressen en poorten voor beide knooppunten.

Gastheer
vm1
vm2

OS-versie
CentOS Linux 7.6 x86_64
CentOS Linux 7.6 x86_64

DB-serverversie
MySQL 5.7.26
PostgreSQL 10.5

DB-poort
3306
5832

IP-adres
192.168.1.107
192.168.1.112

SymmetricDS-versie
SymmetrischeDS 3.9
SymmetrischeDS 3.9

SymmetricDS-installatiepad
/usr/local/symmetrische-server-3.9.20
/usr/local/symmetrische-server-3.9.20

SymmetricDS-knooppuntnaam
corp-000
winkel-001

Hier installeren we SymmetricDS in /usr/local/symmetrische-server-3.9.20, en verschillende submappen en bestanden zullen daar worden opgeslagen. Wij zijn geïnteresseerd in de submappen van samples en engine. De map samples bevat voorbeeldconfiguratiebestanden met knooppunteigenschappen, evenals voorbeeld-SQL-scripts waarmee u snel aan de slag kunt.

In de map samples zien we drie configuratiebestanden met knooppunteigenschappen - de naam toont de aard van het knooppunt in een bepaald schema.

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

SymmetricDS beschikt over alle benodigde configuratiebestanden voor een basisontwerp met 3 knooppunten (optie 1), en dezelfde bestanden kunnen worden gebruikt voor een ontwerp met 2 knooppunten (optie 2). Kopieer het vereiste configuratiebestand van de map samples naar de motoren op de vm1-host. Het komt zo 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

Dit knooppunt in de SymmetricDS-configuratie wordt corp-000 genoemd en de databaseverbinding wordt afgehandeld door het mysql jdbc-stuurprogramma, dat de bovenstaande verbindingsreeks en de inloggegevens gebruikt. We maken verbinding met de replica_db-database en er worden tabellen gemaakt tijdens het maken van het schema. sync.url laat zien waar u contact kunt opnemen met het knooppunt voor synchronisatie.

Knooppunt 2 op host vm2 is geconfigureerd als store-001 en de rest is gespecificeerd in het onderstaande node.properties-bestand. Knooppunt store-001 voert de PostgreSQL-database uit en pgdb_replica is de replicatiedatabase. registratie.url zorgt ervoor dat host vm2 contact kan opnemen met host vm1 en er configuratiegegevens van kan 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 voltooide SymmetricDS-voorbeeld bevat parameters voor het opzetten van tweerichtingsreplicatie tussen twee databaseservers (twee knooppunten). De onderstaande stappen worden uitgevoerd op host vm1 (corp-000), waarmee een voorbeeldschema met 4 tabellen wordt gemaakt. Door vervolgens create-sym-tables uit te voeren met de opdracht symadmin worden directorytabellen gemaakt waarin de regels en richting van replicatie tussen knooppunten 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 geconfigureerd om te repliceren van corp-000 naar winkel-001, en worden de verkooptabellen (sale_transaction en sale_return_line_item) automatisch geconfigureerd om te repliceren van winkel-001 naar corp-000. Nu maken we een schema in de PostgreSQL-database op host vm2 (store-001) om deze 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

Zorg ervoor dat u controleert of de MySQL-database op vm1 voorbeeldtabellen en SymmetricDS-catalogustabellen bevat. Merk op dat de SymmetricDS-systeemtabellen (voorafgegaan door sym_) momenteel alleen beschikbaar zijn op knooppunt corp-000, omdat we daar de opdracht create-sym-tables hebben uitgevoerd en de replicatie zullen beheren. En in de database op knooppunt store-001 zullen er slechts 4 voorbeeldtabellen zonder gegevens zijn.

Alle. De omgeving is klaar om sym-serverprocessen op beide knooppunten uit te voeren, zoals hieronder weergegeven.

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

Logboekvermeldingen worden verzonden naar een achtergrondlogbestand (symmetrisch.log) in de map logs in de map waarin SymmetricDS is geïnstalleerd, evenals naar de standaarduitvoer. De sym-server kan nu worden gestart op knooppunt store-001.

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

Als u het sym-serverproces op de vm2-host uitvoert, worden er ook SymmetricDS-catalogustabellen in de PostgreSQL-database gemaakt. Als u het Sym Server-proces op beide knooppunten uitvoert, coördineren ze met elkaar om gegevens van corp-000 naar store-001 te repliceren. Als we na een paar seconden alle vier de tabellen aan beide kanten doorzoeken, zullen we zien dat de replicatie succesvol is geweest. Of u kunt de bootstrap vanaf corp-4 naar knooppunt store-001 sturen met de volgende opdracht.

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

Op dit punt wordt een nieuw record ingevoegd in de itemtabel in de MySQL-database op knooppunt corp-000 (host: vm1), en u kunt de replicatie ervan naar de PostgreSQL-database op knooppunt 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 een ​​Push-bewerking uit te voeren om gegevens van store-001 naar corp-000 te verplaatsen, voegen we een record in de sale_transaction-tabel in en verifiëren we dat de replicatie succesvol is.

Het resultaat.

We zien de succesvolle opzet van tweerichtingsreplicatie van de voorbeeldtabellen tussen MySQL- en PostgreSQL-databases. Volg deze stappen om replicatie voor nieuwe gebruikerstabellen in te stellen: We maken bijvoorbeeld tabel t1 en configureren de replicatieregels als volgt. Op deze manier configureren we alleen 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)

De configuratie wordt vervolgens op de hoogte gebracht van de schemawijziging, dat wil zeggen de toevoeging van een nieuwe tabel, met behulp van de opdracht symadmin met het sync-triggers-argument, dat de triggers opnieuw creëert om de tabeldefinities in kaart te brengen. send-schema wordt uitgevoerd om schemawijzigingen naar knooppunt store-001 te verzenden, en replicatie van tabel t1 wordt geconfigureerd.

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-klare set bestanden met parameters voor het maken van een circuit met drie of twee knooppunten.
Platformonafhankelijke databases en platformonafhankelijkheid, inclusief servers, laptops en mobiele apparaten.
Repliceer elke database naar een andere database, lokaal, op het WAN of in de cloud.
Mogelijkheid om optimaal te werken met een paar databases of enkele duizenden voor gemakkelijke replicatie.
Betaalde versie met GUI en uitstekende ondersteuning.

Nadelen van SymmetricDS

U moet de regels en richting van replicatie handmatig definiëren op de opdrachtregel via SQL-instructies om catalogustabellen te laden, wat lastig kan zijn.
Het opzetten van veel tabellen voor replicatie kan vervelend zijn, tenzij u scripts gebruikt om SQL-instructies te maken die de regels en richting van replicatie definiëren.
Er wordt te veel informatie vastgelegd in de logbestanden en soms moet u het logbestand opschonen, zodat het niet te veel ruimte in beslag neemt.

Resultaten voor SymmetricDS

Met SymmetricDS kunt u tweerichtingsreplicatie tussen twee, drie of zelfs enkele duizenden knooppunten instellen om bestanden te repliceren en te synchroniseren. Dit is een unieke tool die zelfstandig veel taken uitvoert, zoals automatisch dataherstel na een lange periode van downtime op een node, veilige en efficiënte data-uitwisseling tussen knooppunten via HTTPS, automatisch conflictbeheer op basis van een set regels, etc. SymmetricDS voert replicatie tussen alle databases en daarom kan het worden gebruikt voor een breed scala aan scenario's, waaronder migratie, migratie, distributie, filtering en transformatie van gegevens tussen platforms.

Het voorbeeld is gebaseerd op de ambtenaar Snelgids van SymmetricDS. IN handleiding Beschrijft in detail de verschillende concepten die betrokken zijn bij het opzetten van replicatie met SymmetricDS.

Bron: www.habr.com

Voeg een reactie