En oversigt over PostgreSQL &MySQL krydsreplikering

Denne blog har til formål at forklare en oversigt over krydsreplikering mellem PostgreSQL og MySQL og yderligere diskutere metoderne til at konfigurere krydsreplikering mellem de to databaseservere. Traditionelt kaldes de databaser, der er involveret i en krydsreplikeringsopsætning, heterogene databaser, hvilket er en god tilgang til at flytte væk fra en RDBMS-server til en anden.

Både PostgreSQL- og MySQL-databaser er konventionelt RDBMS-databaser, men de tilbyder også NoSQL-kapacitet med tilføjede udvidelser for at få det bedste fra begge verdener. Denne artikel fokuserer på diskussionen om replikering mellem PostgreSQL og MySQL fra et RDBMS-perspektiv.

En udtømmende forklaring om interne dele af replikering er ikke inden for denne blogs område, dog skal nogle grundlæggende elementer diskuteres for at give publikum en forståelse af, hvordan replikering konfigureres mellem databaseservere, fordele, begrænsninger og måske nogle kendte use cases.

Generelt opnås replikering mellem to identiske databaseservere enten i binær tilstand eller forespørgselstilstand mellem en masterknude (ellers kaldet udgiver, primær eller aktiv) og en slaveknude (abonnent, standby eller passiv). Formålet med replikering er at give en realtidskopi af masterdatabasen på slavesiden, hvor dataene overføres fra master til slave, og derved dannes en aktiv-passiv opsætning, fordi replikeringen kun er konfigureret til at ske én vej. På den anden side kan replikering mellem to databaser konfigureres begge veje, så dataene også kan overføres fra slave tilbage til master, hvilket etablerer en aktiv-aktiv konfiguration. Alt dette kan konfigureres mellem to eller flere identiske databaseservere, som også kan omfatte en kaskadereplikering. Konfigurationen af ​​aktiv-aktiv eller aktiv-passiv afhænger virkelig af virksomhedens behov, tilgængeligheden af ​​sådanne funktioner i den oprindelige konfiguration eller brug af eksterne løsninger til at konfigurere og anvendelige afvejninger.

Ovennævnte konfiguration kan opnås med forskellige databaseservere, hvor en databaseserver kan konfigureres til at acceptere replikerede data fra en anden helt anden databaseserver og stadig opretholde et øjebliksbillede i realtid af de data, der replikeres. Både MySQL- og PostgreSQL-databaseservere tilbyder de fleste af de konfigurationer, der er diskuteret ovenfor, enten i deres egen oprindelse eller ved hjælp af tredjepartsudvidelser, herunder binær logmetode, diskblokmetode, sætningsbaserede og rækkebaserede metoder.

Kravet om at konfigurere en krydsreplikering mellem MySQL og PostgreSQL kommer virkelig ind som et resultat af en engangs-migreringsindsats for at flytte væk fra en databaseserver til en anden. Da begge databaser bruger forskellige protokoller, så kan de ikke direkte tale med hinanden. For at opnå det kommunikationsflow er der et eksternt open source-værktøj såsom pg_chameleon.

Baggrund for pg_chameleon

pg_chameleon er et MySQL til PostgreSQL-replikeringssystem udviklet i Python 3. Det bruger et open source-bibliotek kaldet mysql-replikering, som også er udviklet ved hjælp af Python. Funktionaliteten involverer at trække rækkebilleder af MySQL-tabeller og gemme dem som JSONB-objekter i en PostgreSQL-database, som yderligere afkodes af en pl/pgsql-funktion og afspille disse ændringer mod PostgreSQL-databasen.

Funktioner i pg_chameleon

• Flere MySQL-skemaer fra den samme klynge kan replikeres til en enkelt mål-PostgreSQL-database, der danner en mange-til-en-replikeringsopsætning
• Kilde- og målskemanavnene kan være ikke-identiske
• Replikeringsdata kan hentes fra MySQL kaskadereplika
• Tabeller, der ikke kan replikere eller generere fejl, udelukkes
• Hver replikeringsfunktionalitet styres ved hjælp af dæmoner
• Styres ved hjælp af parametre og konfigurationsfiler baseret på YAML-konstruktion

Demo

Til at begynde med skal du forberede opsætningen med alle de nødvendige forudsætninger for at installere pg_chameleon. I denne demo er Python 3.6.8 installeret, hvilket skaber et virtuelt miljø og aktiverer det til brug.

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

Efter en vellykket installation af Python3.6 opfyldes yderligere yderligere krav, såsom oprettelse og aktivering af et virtuelt miljø. Ud over at pip-modulet er opgraderet til den nyeste version, og det bruges til at installere pg_chameleon. I kommandoerne nedenfor blev pg_chameleon 2.0.9 bevidst installeret, mens den seneste version er en 2.0.10. Dette gøres for at undgå nyindførte fejl i den opdaterede version.

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

Det næste trin er at påkalde pg_chameleon (chameleon er kommandoen) med set_configuration_files-argumentet for at gøre det muligt for pg_chameleon at oprette standardmapper og konfigurationsfiler.

(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

Opret nu en kopi af config-example.yml som default.yml for at gøre den til standardkonfigurationsfilen. Et eksempel på en konfigurationsfil, der bruges til denne demo, findes nedenfor.

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

Konfigurationsfilen, der bruges i denne demo, er eksempelfilen, der følger med pg_chameleon med mindre redigeringer, der passer til kilde- og destinationsmiljøerne, og en oversigt over forskellige sektioner af konfigurationsfilen følger.

Standard.yml-konfigurationsfilen har en sektion med "globale indstillinger", der kontrollerer detaljer såsom låsefilplacering, logningsplaceringer og opbevaringsperiode osv. Den næste sektion er sektionen "typetilsidesættelse", som er et sæt regler, der skal tilsidesættes typer under replikering. En prøvetypetilsidesættelsesregel bruges som standard, som konverterer en tinyint(1) til en boolesk værdi. Det næste afsnit er sektionen med destinationsdatabaseforbindelsesdetaljer, som i vores tilfælde er en PostgreSQL-database, betegnet med "pg_conn". Den sidste sektion er kildesektionen, som har alle detaljer om kildedatabaseforbindelsesindstillinger, skemamapping mellem kilde og destination, eventuelle tabeller, der skal springes over, inklusive timeout, hukommelse og batchstørrelsesindstillinger. Læg mærke til "kilderne", der angiver, at der kan være flere kilder til en enkelt destination for at danne en mange-til-en-replikeringsopsætning.

En "world_x"-database bruges i denne demo, som er en eksempeldatabase med 4 tabeller, der indeholder eksempelrækker, som MySQL-fællesskabet tilbyder til demoformål, og den kan downloades herfra. Eksempeldatabasen leveres som et tar og komprimeret arkiv sammen med instruktioner til at oprette den og importere rækker i den.

Der oprettes en dedikeret bruger i både MySQL- og PostgreSQL-databaserne med samme navn som usr_replica, der yderligere tildeles yderligere privilegier på MySQL for at få læseadgang til alle tabellerne, der replikeres.

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;

Der oprettes en database på PostgreSQL-siden, der vil acceptere ændringer fra MySQL-databasen, som er navngivet som "db_replica". "usr_replica"-brugeren i PostgreSQL konfigureres automatisk som ejer af to skemaer såsom "pgworld_x" og "sch_chameleon", der indeholder henholdsvis de faktiske replikerede tabeller og katalogtabeller for replikering. Denne automatiske konfiguration udføres af argumentet create_replica_schema, som er angivet længere nede.

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

MySQL-databasen er konfigureret med nogle få parameterændringer for at forberede den til replikering, som vist nedenfor, og det kræver en genstart af databaseserveren for at ændringerne kan træde i kraft.

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

På dette tidspunkt er det vigtigt at teste forbindelsen til begge databaseservere for at sikre, at der ikke er problemer, når pg_chameleon-kommandoer udføres.

På PostgreSQL-noden:

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

På MySQL-noden:

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

De næste tre kommandoer af pg_chameleon (chameleon) er, hvor den sætter miljøet op, tilføjer en kilde og initialiserer en replika. Argumentet "create_replica_schema" for pg_chameleon opretter standardskemaet (sch_chameleon) og replikeringsskemaet (pgworld_x) i PostgreSQL-databasen, som det allerede er blevet diskuteret. Argumentet "add_source" tilføjer kildedatabasen til konfigurationen ved at læse konfigurationsfilen (default.yml), som i dette tilfælde er "mysql", mens "init_replica" initialiserer konfigurationen baseret på indstillingerne for konfigurationsfilen.

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

Outputtet af de ovennævnte tre kommandoer er selvforklarende, hvilket indikerer succesen for hver kommando med en tydelig outputmeddelelse. Eventuelle fejl eller syntaksfejl er tydeligt nævnt i enkle og almindelige meddelelser, hvilket foreslår og anmoder om korrigerende handlinger.

Det sidste trin er at starte replikationen med "start_replika", hvis succes er angivet med et outputtip som vist nedenfor.

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

Status for replikering kan forespørges med "show_status"-argumentet, mens fejl kan ses med "show_errors"-argumentet.

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

Som diskuteret tidligere, administreres hver af replikeringsfunktionaliteterne ved hjælp af dæmoner, som kan ses ved at forespørge i procestabellen ved hjælp af Linux "ps"-kommandoen, vist nedenfor.

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

Ingen replikeringsopsætning er fuldført, før den er sat til "anvendelse i realtid", som er blevet simuleret som nedenfor. Det involverer oprettelse af en tabel og indsættelse af et par poster i MySQL-databasen, efterfølgende aktiveres "sync_tables"-argumentet for pg_chameleon for at opdatere dæmonerne for at replikere tabellen sammen med dens poster til PostgreSQL-databasen.

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.

Testen bekræftes ved at forespørge tabellen fra PostgreSQL-databasen for at afspejle rækkerne.

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

Hvis det er et migreringsprojekt, vil følgende pg_chameleon-kommandoer markere afslutningen på migreringsindsatsen. Kommandoerne skal udføres, efter det er bekræftet, at rækker af alle måltabellerne er blevet replikeret på tværs, og resultatet vil være en rent migreret PostgreSQL-database uden nogen referencer til kildedatabasen eller replikeringsskemaet (sch_chameleon).

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

Følgende kommandoer vil eventuelt slette kildekonfigurationen og replikeringsskemaet.

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

Fordele ved at bruge pg_chameleon

• Simpel at konfigurere og mindre kompliceret konfiguration
• Smertefri fejlfinding og fejlfinding med letforståeligt fejloutput
• Yderligere adhoc-tabeller kan tilføjes til replikeringen efter initialisering uden at ændre nogen anden konfiguration
• Flere kilder kan konfigureres til en enkelt destinationsdatabase, hvilket er nyttigt i konsolideringsprojekter til at flette data fra en eller flere MySQL-databaser til en enkelt PostgreSQL-database
• Udvalgte tabeller kan springes over fra at blive replikeret

Udemper ved at bruge pg_chameleon

• Understøttes kun fra MySQL 5.5 og frem som Origin-database og PostgreSQL 9.5 og fremefter for destinationsdatabase
• Kræver, at hver tabel har en primær eller unik nøgle, ellers bliver tabellerne initialiseret under init_replica-processen, men de vil ikke replikere
• Envejsreplikering, dvs. MySQL til PostgreSQL. Derved begrænses brugen til kun en aktiv-passiv opsætning
• Kildedatabasen kan kun være en MySQL-database, mens understøttelse af PostgreSQL-database som kilde er eksperimentel med yderligere begrænsninger (klik her for at lære mere)

pg_chameleon Resume

Replikeringstilgangen, der tilbydes af pg_chameleon, er gunstig for en databasemigrering af MySQL til PostgreSQL. En af de væsentlige begrænsninger ved envejsreplikering kan dog afskrække databaseprofessionelle til at bruge det til andet end migrering. Denne ulempe ved ensrettet replikering kan løses ved at bruge endnu et open source-værktøj kaldet SymmetricDS.

For at studere værktøjet mere detaljeret, se venligst den officielle dokumentation her. Kommandolinjereferencen kan hentes herfra.

En oversigt over SymmetricDS

SymmetricDS er et open source-værktøj, der er i stand til at replikere enhver database til enhver anden database, fra den populære liste over databaseservere som Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird og andre cloud-baserede databaseinstanser såsom Redshift og Azure osv. Nogle af tilbuddene omfatter database- og filsynkronisering, multi-master replikering, filtreret synkronisering og transformation. Værktøjet er udviklet ved hjælp af Java, der kræver en standardudgave (version 8.0 eller nyere) af enten JRE eller JDK. Funktionaliteten involverer dataændringer, der fanges af triggere ved kildedatabasen og dirigerer dem til en deltagende destinationsdatabase som udgående batches

Funktioner i SymmetricDS

• Platformuafhængig, hvilket betyder, at to eller flere forskellige databaser kan kommunikere med hinanden, enhver database til enhver anden database
• Relationelle databaser opnår synkronisering ved hjælp af ændringsdatafangst, mens filsystembaserede systemer anvender filsynkronisering
• Tovejsreplikering ved hjælp af Push and Pull-metoden, som udføres baseret på fastsatte regler
• Dataoverførsel kan også finde sted over sikre netværk med lav båndbredde
• Automatisk gendannelse under genoptagelsen af ​​en nedbrudt node og automatisk konfliktløsning
• Cloud klar og indeholder kraftfulde udvidelses-API'er

Demo

SymmetricDS kan konfigureres i en af ​​de to muligheder:

• En master (forælder) node, der fungerer som en centraliseret mellemmand, der koordinerer datareplikering mellem to slave (under) noder, hvor kommunikationen mellem de to underordnede noder kun kan foregå via forælderen.
• En aktiv node (node1) kan replikere til og fra en anden aktiv node (node2) uden nogen mellemmand.

I begge muligheder sker kommunikationen mellem noderne via "Push" og "Pull" hændelser. I denne demo vil en aktiv-aktiv konfiguration mellem to noder blive forklaret. Den fulde arkitektur kan være udtømmende, så læserne opfordres til at tjekke brugervejledningen, der er tilgængelig her, for at lære mere om det indre af SymmetricDS.

Installation af SymmetricDS er så simpelt som at downloade open source-versionen af ​​zip-filen herfra og udpakke den på et bekvemt sted. Oplysningerne om installationsplacering og version af SymmetricDS i denne demo er som i tabellen nedenfor, sammen med andre detaljer vedrørende databaseversioner, Linux-versioner, ip-adresser og kommunikationsport for begge de deltagende noder.

Installationshjemmet i dette tilfælde er "/usr/local/symmetric-server-3.9.20", som vil være hjemmemappen for SymmetricDS, som indeholder forskellige andre undermapper og filer. To af de undermapper, der er vigtige nu, er "samples" og "engines". Sample biblioteket indeholder eksempler på konfigurationsfil for nodeegenskaber ud over eksempler på SQL-scripts for at sætte gang i en hurtig demo.

De følgende tre konfigurationsfiler for nodeegenskaber kan ses i "samples"-mappen med navne, der angiver arten af ​​node i en given opsætning.

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

Da SymmetricDS kommer med alle de nødvendige konfigurationsfiler til at understøtte en grundlæggende 3 node opsætning (mulighed 1), er det praktisk at bruge de samme konfigurationsfiler til også at opsætte en 2 node opsætning (mulighed 2). Den tilsigtede konfigurationsfil kopieres fra "samples"-biblioteket til "engines" på vært vm1, og det ser ud som nedenfor.

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

Navnet på denne node i SymmetricDS-konfigurationen er "corp-000" med databaseforbindelsen håndteret med mysql jdbc-driveren ved hjælp af forbindelsesstrengen som angivet ovenfor sammen med login-legitimationsoplysninger. Databasen, der skal forbindes, er "replica_db", og tabellerne vil blive oprettet under oprettelsen af ​​et eksempelskema. "sync.url" angiver det sted, hvor noden skal kontaktes for synkronisering.

Node 2 på vært vm2 er konfigureret som "store-001" med resten af ​​detaljerne som konfigureret i filen node.properties, vist nedenfor. Noden "store-001" kører en PostgreSQL-database med "pgdb_replica" som databasen til replikering. "Registration.url" gør det muligt for værten "vm2" at kommunikere med værten "vm1" for at hente konfigurationsdetaljer.

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

Den forudkonfigurerede standarddemo af SymmetricDS indeholder indstillinger til opsætning af en tovejsreplikering mellem to databaseservere (to noder). Trinene nedenfor udføres på vært vm1 (corp-000), som vil skabe et eksempelskema med 4 tabeller. Ydermere vil udførelse af "create-sym-tables" med kommandoen "symadmin" skabe katalogtabellerne, der gemmer og kontrollerer reglerne og retningen for replikering mellem noder. Til sidst er demotabellerne indlæst med eksempeldata.

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

Demotabellerne "item" og "item_selling_price" er automatisk konfigureret til at replikere fra corp-000 til butik-001, mens salgstabellerne (sale_transaction og sale_return_line_item) er auto-konfigureret replikat fra butik-001 til corp-000. Det næste trin er at oprette eksempelskemaet i PostgreSQL-databasen på vært vm2 (store-001), for at forberede det til at modtage data fra corp-000.

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

Det er vigtigt at verificere eksistensen af ​​demo-tabeller og SymmetricDS-katalogtabeller i MySQL-databasen på vm1 på dette stadium. Bemærk, SymmetricDS-systemtabellerne (tabeller med præfikset "sym_") er kun tilgængelige i corp-000 noden på dette tidspunkt, fordi det er her kommandoen "create-sym-tables" blev udført, som vil være stedet at kontrollere og styre replikationen. Derudover vil butik-001 nodedatabasen kun have 4 demotabeller uden data i sig.

Miljøet er nu klar til at starte "sym"-serverprocesserne på begge noder, som vist nedenfor.

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

Logposterne sendes både til en baggrundslogfil (symmetric.log) under et logbibliotek på SymmetricDS-installationsstedet såvel som til standardoutputtet. "Sym"-serveren kan nu startes på store-001 node.

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

Opstarten af ​​"sym"-serverprocessen på vært vm2 vil også skabe SymmetricDS-katalogtabellerne i PostgreSQL-databasen. Opstarten af ​​"sym"-serverprocessen på begge noder vil få dem til at koordinere med hinanden for at replikere data fra corp-000 til store-001. Efter et par sekunder vil en forespørgsel på alle fire tabeller på hver side vise de vellykkede replikeringsresultater. Alternativt kan en indledende indlæsning også sendes til store-001 noden fra corp-000 med nedenstående kommando.

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

På dette tidspunkt indsættes en ny post i "item"-tabellen i MySQL-databasen på corp-000 node (vært:vm1), og den kan verificeres til at være blevet replikeret til PostgreSQL-databasen på store-001 node (vært:vm2) ). Dette viser "Pull"-hændelsen for data fra corp-000 til 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)

"Push"-hændelsen for data fra store-001 til corp-000 kan opnås ved at indsætte en post i "sale_transaction"-tabellen og bekræfte, at den replikeres igennem.

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

Dette markerer den vellykkede konfiguration af tovejsreplikering af demotabeller mellem en MySQL- og PostgreSQL-database. Mens konfigurationen af ​​replikering for nyoprettede brugertabeller kan opnås ved hjælp af følgende trin. Et eksempeltabel "t1" oprettes til demoen, og reglerne for dens replikering er konfigureret i henhold til proceduren nedenfor. Trinene konfigurerer kun replikeringen fra corp-000 til 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)

Herefter får konfigurationen besked om skemaændringen ved at tilføje en ny tabel ved at påkalde symadmin-kommandoen med "sync-triggers"-argumentet, som vil genskabe triggerne for at matche tabeldefinitioner. Udfør efterfølgende "send-schema" for at sende skemaændringer ud til store-001 node, hvorefter replikeringen af ​​"t1"-tabellen konfigureres med succes.

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

Fordele ved at bruge SymmetricDS

• Besværet installation og konfiguration inklusive et forudkonfigureret sæt parameterfiler til at bygge enten en 3-node eller en 2-node opsætning
• Tværplatformsdatabase aktiveret og platformsuafhængig, inklusive servere, bærbare computere og mobile enheder
• Repliker enhver database til enhver anden database, uanset om det er on-prem, WAN eller cloud
• I stand til optimalt at håndtere et par databaser til flere tusinde databaser for at replikere data problemfrit
• En kommerciel version af softwaren tilbyder GUI-drevet administrationskonsol med en fremragende supportpakke

Udemper ved at bruge SymmetricDS

• Manuel kommandolinjekonfiguration kan involvere at definere regler og retning for replikering via SQL-sætninger for at indlæse katalogtabeller, hvilket kan være ubelejligt at administrere
• Opsætning af et stort antal tabeller til replikering vil være en udtømmende indsats, medmindre en eller anden form for scripting bruges til at generere SQL-sætningerne, der definerer regler og retning for replikering
• Masser af log-information roder logfilen, og kræver derved periodisk logfilvedligeholdelse for ikke at tillade logfilen at fylde disken op

Symmetrisk DS-oversigt

SymmetricDS giver mulighed for at opsætte tovejsreplikering mellem 2 noder, 3 noder og så videre for flere tusinde noder for at replikere data og opnå filsynkronisering. Det er et unikt værktøj, der udfører mange af de selvhelbredende vedligeholdelsesopgaver såsom automatisk gendannelse af data efter længere perioder med nedetid i en node, sikker og effektiv kommunikation mellem noder ved hjælp af HTTPS og automatisk konflikthåndtering baseret på fastsatte regler , 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.