Jeg vil i grove træk fortælle om krydsgentagelse mellem PostgreSQL og MySQL, samt metoder til at konfigurere krydsgentagelse mellem disse to databaser. Database i krydsgentagelse kaldes normalt homogene, og det er en praktisk metode til at overføre fra en server af en relationel DBMS til en anden.
Databaserne PostgreSQL og MySQL betragtes som relationelle, men med ekstra udvidelser tilbyder de NoSQL-muligheder. Her vil vi diskutere gentagelse mellem PostgreSQL og MySQL set fra et relationelt DBMS-perspektiv.
Vi vil ikke beskrive hele den indre mekanisme, kun de grundlæggende principper, så du får en idé om konfigurationen af gentagelse mellem databaseservere, fordele, begrænsninger og anvendelsesscenarier.
Normalt udføres gentagelse mellem to identiske databaseservere enten i binær tilstand eller ved hjælp af forespørgsler mellem den førende node (som også er udgiver, hoved eller aktiv) og den underordnede (abonnent, ventende eller passiv). Formålet med gentagelse er at give et realtidskopi af den primære database på underordnede side. Data sendes fra den førende til den underordnede, det vil sige fra aktiv til passiv, fordi gentagelse kun udføres i én retning. Men det er muligt at konfigurere gentagelse mellem to databaser i begge retninger, så data sendes fra underordnede til førende i en 'aktiv-aktiv' konfiguration. Alt dette, herunder kaskadegensekvenser, er muligt mellem to eller flere identiske databaseservere. Konfigurationen 'aktiv-aktiv' eller 'aktiv-passiv' afhænger af behovet, tilgængeligheden af sådanne muligheder i den oprindelige konfiguration eller brugen af eksterne løsninger til konfiguration og eksisterende kompromiser.
Den beskrevne konfiguration er mulig mellem forskellige databaseservere. En server kan konfigureres til at modtage replikerede data fra en anden databaseserver og samtidig bevare snapshots af de replikerede data i realtid. MySQL og PostgreSQL tilbyder de fleste af disse konfigurationer enten selv eller ved hjælp af tredjepartsudvidelser, herunder metoder til binær log, disklåse og metoder baseret på operatorer og rækker.
Krydsreplikation mellem MySQL og PostgreSQL er nødvendig for engangs migration fra én database-server til en anden. Disse databaser bruger forskellige protokoller, så de kan ikke forbindes direkte. For at etablere datadeling kan man bruge et eksternt open source-værktøj såsom pg_chameleon.
Hvad er pg_chameleon
pg_chameleon er et replikationssystem fra MySQL til PostgreSQL baseret på Python 3. Det bruger open source-biblioteket mysql-replication, også skrevet på Python. Data fra MySQL tabeller udtrækkes og gemmes som JSONB-objekter i PostgreSQL databasen, hvorefter de dekodes af pl/pgsql-funktionen og genopbygges i PostgreSQL databasen.
Kapaciteterne i pg_chameleon
Flere MySQL-skemaer fra en enkelt klynge kan replikeres til én mål PostgreSQL-database med konfigurationen "én til mange".
Navnene på kilde- og målschemaer må ikke være ens.
Replikationsdata kan udtrækkes fra en kaskadereplik MySQL.
Tabeller, der ikke kan replikeres eller skaber fejl, ekskluderes.
Hver replikationsfunktion styres af dæmoner.
Kontrol via parametre og konfigurationsfiler baseret på YAML.
Eksempel
Vært
vm1
vm2
OS-version
CentOS Linux 7.6 x86_64
CentOS Linux 7.5 x86_64
Database server version
MySQL 5.7.26
PostgreSQL 10.5
Database port
3306
5433
IP-adresse
192.168.56.102
192.168.56.106
For at komme i gang skal du forberede alle nødvendige komponenter til installationen af pg_chameleon. I dette eksempel er Python 3.6.8 installeret, som opretter et virtuelt miljø og aktiverer det.
$> 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 altinstallEfter en vellykket installation af Python3.6 skal du opfylde de øvrige krav, såsom at oprette og aktivere det virtuelle miljø. Derudover opdateres pip-modulet til den nyeste version og bruges til at installere pg_chameleon. I kommandoerne nedenfor installeres pg_chameleon 2.0.9 bevidst, selvom den nyeste version er 2.0.10. Dette gøres for at undgå nye 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.9Derefter kalder vi pg_chameleon (chameleon er kommandoen) med argumentet set_configuration_files for at aktivere pg_chameleon og oprette standardkataloger 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/
coping configuration example in /root/.pg_chameleon/configuration//config-example.ymlNu opretter vi en kopi af config-example.yml som default.yml, så den bliver standardkonfigurationsfilen. Et eksempel på konfigurationsfilen til dette eksempel gives nedenfor.
$> cat default.yml
---
# globale indstillinger
pid_dir: '~/.pg_chameleon/pid/'
log_dir: '~/.pg_chameleon/logs/'
log_dest: fil
log_level: info
log_days_keep: 10
rollbar_key: ''
rollbar_env: ''
# type_override giver brugeren mulighed for at overskrive standard typekonvertering til en anden.
type_override:
"tinyint(1)":
override_to: boolean
override_tables:
- "*"
#postgres destinationsforbindelse
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 #spring indsætninger på tabellen delphis_mediterranea.foo
delete:
- delphis_mediterranea #spring sletninger på skemaet delphis_mediterranea
update:Konfigurationsfilen i dette eksempel er et eksempel på en fil med pg_chameleon med små ændringer i overensstemmelse med kilde- og destinationsmiljøerne, og nedenfor gives en oversigt over de forskellige sektioner i konfigurationsfilen.
I konfigurationsfilen default.yml er der en sektion for globale indstillinger, hvor du kan administrere indstillinger såsom placeringen af låsefilen, logfilerne, logopbevaringsperioden osv. Derefter følger sektionen for typeoverriding, der angiver et sæt regler for typeoverriding under replikering. I standardeksemplet anvendes en regel til typeoverriding, som konverterer tinyint(1) til en boolesk værdi. I den næste sektion angiver vi forbindelsesdetaljerne til den ønskede database. I vores tilfælde er det databasen PostgreSQL, benævnt pg_conn. I den sidste sektion angiver vi kildedataene, dvs. parametrene for forbindelsen til kilde databasen, skemaet der kortlægger kilde- og måldatabasen, de tabeller der skal undgås, timeout, hukommelse, batchstørrelse. Bemærk, at 'sources' er angivet i flertal, hvilket betyder, at vi kan tilføje flere kildedatabaser til én destination for at konfigurere en "mange-til-en" opsætning.
Database world_x in the example contains 4 tables with rows that the MySQL community offers as an example. It can be downloaded . The example database is provided as a tar and compressed archive with instructions for creating and importing rows.
In MySQL and PostgreSQL databases, a special user with the same name usr_replica is created. In MySQL, he is granted additional rights to read all replicated tables.
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;On the PostgreSQL side, a database db_replica is created that will receive changes from the MySQL database. The user usr_replica in PostgreSQL is automatically configured as the owner of two schemas pgworld_x and sch_chameleon, which contain the actual replicated tables and replication catalog tables, respectively. The automatic configuration is managed by the create_replica_schema argument, as you will see below.
postgres=# CREATE USER usr_replica WITH PASSWORD 'pass123';
CREATE ROLE
postgres=# CREATE DATABASE db_replica WITH OWNER usr_replica;
CREATE DATABASEThe MySQL database is configured with changes to certain parameters to prepare it for replication, as shown below. The database server will need to be restarted for the changes to take effect.
$> vi /etc/my.cnf
binlog_format= ROW
binlog_row_image=FULL
log-bin = mysql-bin
server-id = 1It is now important to check the connection to both database servers to avoid problems when executing pg_chameleon commands.
On the PostgreSQL node:
$> mysql -u usr_replica -Ap'admin123' -h 192.168.56.102 -D world_xOn the MySQL node:
$> psql -p 5433 -U usr_replica -h 192.168.56.106 db_replicaThe following three pg_chameleon (chameleon) commands prepare the environment, add the source, and initialize the replica. The create_replica_schema argument in pg_chameleon creates a default schema (sch_chameleon) and a replication schema (pgworld_x) in the PostgreSQL database, as we already mentioned. The add_source argument adds the source database to the configuration by reading the configuration file (default.yml), and in our case, this is mysql, while init_replica initializes the configuration based on the parameters in the configuration file.
$> chameleon create_replica_schema --debug
$> chameleon add_source --config default --source mysql --debug
$> chameleon init_replica --config default --source mysql --debugResultaterne af disse tre kommandoer indikerer tydeligt deres succesfulde udførelse. Alle fejl eller syntaksfejl vises i enkle og forståelige meddelelser med tips til at rette problemerne.
Til sidst, lad os starte replikationen med start_replica og få en meddelelse om succesfuld udførelse.
$> chameleon start_replica --config default --source mysql
output: Starter replikationsprocessen for kilde mysqlStatus for replikationen kan anmodes om med argumentet show_status, og fejl kan gennemgås med argumentet show_errors.
Som nævnt styres hver replikationsfunktion af dæmoner. For at se dem anmoder vi om proceslisten med Linux-kommandoen ps, som vist nedenfor.
Replikationen betragtes ikke som opsat, før vi tester den i realtid som vist nedenfor. Vi opretter en tabel, indsætter et par poster i MySQL-databasen og kalder argumentet sync_tables i pg_chameleon for at opdatere dæmonerne og replikere tabellen med posterne i 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 tabelprocessen for kilde mysql er startet.For at bekræfte testresultaterne anmoder vi om tabellen fra PostgreSQL-databasen og viser rækkerne.
$> psql -p 5433 -U usr_replica -d db_replica -c "select * from pgworld_x.t1";
n1 | n2
----+-------
1 | one
2 | twoHvis vi udfører en migration, vil følgende pg_chameleon-kommandoer markere dens afslutning. Kommandoerne skal udføres, efter vi har bekræftet, at alle måltabellers rækker er blevet replikeret, og resultatet vil være en pæn overført PostgreSQL-database uden henvisninger til den oprindelige database eller replikationsskemaet (sch_chameleon).
$> chameleon stop_replica --config default --source mysql
$> chameleon detach_replica --config default --source mysql --debugValgfrit kan de følgende kommandoer fjerne den oprindelige konfiguration og replikationsskemaet.
$> chameleon drop_source --config default --source mysql --debug
$> chameleon drop_replica_schema --config default --source mysql --debugFordele ved pg_chameleon
Nem opsætning og konfiguration.
Brugervenlig fejlfinding og identifikation af anomalier med klare fejlmeddelelser.
Det er muligt at tilføje yderligere specialtabeller til replikationen efter initialization, uden at ændre den øvrige konfiguration.
Det er muligt at konfigurere flere kildedatabaser til én mål database, hvilket er meget praktisk, hvis du kombinerer data fra en eller flere MySQL-databaser til én PostgreSQL-database.
Valgte tabeller kan undgås at blive replikeret.
Ulemper ved pg_chameleon
Kun understøttet med MySQL 5.5 og nyere som kilde og PostgreSQL 9.5 og nyere som mål database.
Hver tabel skal have en primær eller unik nøgle, ellers initialiseres tabellerne under init_replica-processen, men replikeres ikke.
Envejsreplikering — kun fra MySQL til PostgreSQL. Derfor er det kun egnet til et "aktivt-passiv"-skema.
Kilden kan kun være en MySQL-database, og understøttelse af PostgreSQL som kilde er kun eksperimentel og med begrænsninger (læs mere) )
Sammenfatning af pg_chameleon
Replikationsmetoden i pg_chameleon er velegnet til migrering af databaser fra MySQL til PostgreSQL. En betydelig ulempe er, at replikeringen kun er envejs, så databaseeksperter vil næppe ønske at bruge det til andet end migrering. Men problemet med envejsreplikering kan løses med et andet open source-værktøj — SymmetricDS.
Læs mere i den officielle dokumentation . CLI-dokumentationen kan findes .
Oversigt over SymmetricDS
SymmetricDS er et open source-værktøj, der replikerer enhver database til enhver anden almindelig database: Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird og andre cloud-databaseinstanser, såsom Redshift og Azure osv. Tilgængelige funktioner: databasesynkronisering og filsynkronisering, replikering af flere kildedatabaser, filtreret synkronisering, transformation og mere. Det er et Java-baseret værktøj, og standardudgaven af JRE eller JDK (version 8.0 eller nyere) er påkrævet. Her kan ændringer i data registreres via triggers i kildedatabasen og sendes til den tilsvarende måldatabase i form af pakker.
Funktioner i SymmetricDS
Værktøjet er platform-uafhængigt, hvilket betyder, at to eller flere forskellige databaser kan udveksle data.
Relationelle databaser synkroniseres ved hjælp af ændringsregistrering, mens filsystembaserede databaser bruger filsynkronisering.
To-vejsreplikering ved hjælp af Push- og Pull-metoder baseret på sæt regler.
Dataoverførsel er mulig via beskyttede netværk og netværk med lav båndbredde.
Automatisk genopretning ved genoptagelse af noder efter nedbrud og automatisk konfliktløsning.
Kompatibilitet med skyen og effektive API-udvidelser.
Eksempel
SymmetricDS kan konfigureres på en af to måder:
En førende (parent) node, der centralt koordinerer datareplication mellem to underordnede (child) noder, og dataudveksling mellem de underordnede noder finder kun sted gennem den førende.
En aktiv node (node 1) kan udveksle data til replication med en anden aktiv node (node 2) uden mellemmænd.
I begge tilfælde foregår dataudvekslingen via Push og Pull. I dette eksempel vil vi se på konfigurationen "aktiv-aktiv". At beskrive hele arkitekturen ville tage for lang tid, så se for at lære mere om SymmetricDS-enheden.
At installere SymmetricDS er meget nemt: download den opensource-version af zip-filen og ekstrakt den, hvor du vil. Tabellen nedenfor indeholder oplysninger om installationsstedet og versionen af SymmetricDS i dette eksempel, samt databasens versioner, versioner af Linux, IP-adresser og porte for begge noder.
Vært
vm1
vm2
OS-version
CentOS Linux 7.6 x86_64
CentOS Linux 7.6 x86_64
Database server version
MySQL 5.7.26
PostgreSQL 10.5
Database port
3306
5832
IP-adresse
192.168.1.107
192.168.1.112
Version af SymmetricDS
SymmetricDS 3.9
SymmetricDS 3.9
Installationssti for SymmetricDS
/usr/local/symmetric-server-3.9.20
/usr/local/symmetric-server-3.9.20
Navn på SymmetricDS-node
corp-000
store-001
Her installerer vi SymmetricDS i /usr/local/symmetric-server-3.9.20, og her vil forskellige underkataloger og filer blive opbevaret. Vi er interesseret i underkatalogerne samples og engines. I katalogen samples findes eksempelkonfigurationsfiler med nodeegenskaber samt eksempel-SQL-scripts til hurtigt at komme i gang med demonstrationer.
I katalogen samples ser vi tre konfigurationsfiler med nodeegenskaber - navnet angiver nodeligens karakter i en bestemt skema.
corp-000.properties
store-001.properties
store-002.propertiesI SymmetricDS er alle nødvendige konfigurationsfiler til en grundlæggende skema af 3 noder (variant 1), og de samme filer kan bruges til en skema med 2 noder (variant 2). Vi kopierer den nødvendige konfigurationsfil fra katalogen samples til engines på værten vm1. Sådan ser det ud:
$> 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=000Denne knude i SymmetricDS-konfigurationen hedder corp-000, og forbindelsen til databasen håndteres af mysql jdbc-driveren, der bruger den ovenfor nævnte forbindelsesstreng og legitimationsoplysninger til login. Vi opretter forbindelse til databasen replica_db, og under oprettelsen af skemaet vil tabellerne blive oprettet. sync.url angiver forbindelsespunktet til noden for synkronisering.
Node 2 på værten vm2 konfigureres som store-001, og resten er angivet i node.properties-filen, som er vist nedenfor. Nodens store-001 kører en PostgreSQL-database, mens pgdb_replica er databasen til replikering. registration.url giver værten vm2 mulighed for at kontakte værten vm1 og få konfigurationsdetaljer fra denne.
$> 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=001Det færdige eksempel på SymmetricDS indeholder parametre til at konfigurere tovejsreplikering mellem to databaseservere (to noder). De følgende trin udføres på værten vm1 (corp-000), som vil oprette et eksempel skema med 4 tabeller. Derefter opretter kommandoen create-sym-tables i symadmin tabellerne, hvor reglerne og retningen for replikering mellem noderne vil blive gemt. Endelig indlæses eksemplariske data i tabellerne.
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.sqlI eksemplet er tabellerne item og item_selling_price automatisk konfigureret til at replikere fra corp-000 til store-001, mens tabellerne sale (sale_transaction og sale_return_line_item) automatisk er konfigureret til at replikere fra store-001 til corp-000. Nu opretter vi skemaet i PostgreSQL-databasen på værten 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.xmlSørg for, at der i MySQL-databasen på vm1 er eksempler på tabeller og katalogtabeller fra SymmetricDS. Bemærk, at SymmetricDS-systemtabellerne (med præfikset sym_) i øjeblikket kun er tilgængelige på noden corp-000, da vi udførte command create-sym-tables der og vil styre replikeringen. Derudover vil der kun være 4 eksemplartabeller uden data i databasen på noden store-001.
Det er hele. Miljøet er klar til at køre serverprocesserne sym på begge noder, som vist nedenfor.
vm1$> cd /usr/local/symmetric-server-3.9.20/bin
vm1$> sym 2>&1 &Logfilerne sendes til baggrundslogfilen (symmetric.log) i logmappen i den mappe, hvor SymmetricDS er installeret, samt til standard output. Sym-serveren kan nu startes på noden store-001.
vm2$> cd /usr/local/symmetric-server-3.9.20/bin
vm2$> sym 2>&1 &Hvis serverprocessen sym køres på værten vm2, vil den oprette SymmetricDS katalogtabellerne også i PostgreSQL-databasen. Hvis serverprocessen sym køres på begge noder, vil de koordinere med hinanden for at replikere data fra corp-000 til store-001. Hvis vi efter nogle sekunder forespørger de 4 tabeller på begge sider, vil vi se, at replikationen er lykkedes. Alternativt kan vi sende en initial belastning til noden store-001 fra corp-000 med følgende kommando.
vm1$> ./symadmin --engine corp-000 reload-node 001På dette tidspunkt indsættes en ny post i item-tabellen i MySQL-databasen på noden corp-000 (vært: vm1), og vi kan kontrollere dens replikation i PostgreSQL-databasen på noden store-001 (vært: vm2). Vi ser Pull-operationen for at flytte 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)For at udføre Push-operationen for at flytte data fra store-001 til corp-000, indsætter vi en post i sale_transaction-tabellen og kontrollerer, at replikationen er udført.
Vi ser en vellykket opsætning af tovejsreplikation af eksempel-tabeller mellem MySQL- og PostgreSQL-databaser. For at konfigurere replikation for nye brugerdefinerede tabeller udfører vi følgende trin. Vi opretter tabellen t1 som eksempel og konfigurerer reglerne for dens replikation på følgende måde. Sådan opsætter vi kun replikation 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)Derefter modtager konfigurationen et notifikationssignal om ændringen af skemaet, dvs. tilføjelsen af en ny tabel, ved hjælp af kommandoen symadmin med argumentet sync-triggers, som genskaber udløsere for at matche tabeldefinitioner. send-schema udføres for at sende ændringerne i skemaet til noden store-001, og replikationen af tabel t1 er konfigureret.
vm1$> ./symadmin -e corp-000 --node=001 sync-triggers
vm1$> ./symadmin send-schema -e corp-000 --node=001 t1Fordele ved SymmetricDS
Simpel installation og konfiguration, herunder et klar til brug sæt af filer med parametre til oprettelse af skema med tre eller to noder.
Tværplatformskompatibilitet af databaser og uafhængighed af platformen, inklusive servere, bærbare computere og mobile enheder.
Replikation af enhver database til enhver anden database lokalt, i WAN eller i cloud.
Mulighed for optimal drift med et par databaser eller tusindvis for bekvem replikation.
Betalingsversion med grafisk grænseflade og fremragende support.
Ulemper ved SymmetricDS
Det er nødvendigt manuelt at definere replikationsregler og retning i kommandolinjen via SQL-operatorer for at indlæse katalogtabel, hvilket kan være besværligt.
At konfigurere mange tabeller til replikation kan være trættende, medmindre man bruger scripts til at oprette SQL-operatorer, der definerer replikationsregler og retning.
Logfilerne indeholder for meget information, og nogle gange skal man rydde op i logfilen for at undgå, at den fylder for meget.
Konklusion vedrørende SymmetricDS
SymmetricDS muliggør konfiguration af tovej replikation mellem to, tre og selv flere tusinde noder for at udføre replikation og synkronisere filer. Det er et unikt værktøj, der selv udfører mange opgaver, såsom automatisk gendannelse af data efter en længere nedetid på en node, sikker og effektiv dataudveksling mellem noder via HTTPS, automatisk konfliktstyring baseret på et regelsæt osv. SymmetricDS udfører replikation mellem alle databaser, så det kan anvendes til forskellige scenarier, herunder migration, opgradering, distribution, filtrering og datatransformation på forskellige platforme.
Eksemplet er lavet baseret på den officielle om SymmetricDS. I forskellige begreber relateret til konfiguration af replikation ved hjælp af SymmetricDS beskrives i detaljer.
Kilde: habr.com
