Parlaré breument de la replicació creuada entre PostgreSQL i MySQL, així com dels mètodes per configurar la replicació creuada entre aquests dos servidors de bases de dades. Les bases de dades replicades creuades s'anomenen habitualment bases de dades homogènies, i aquest és un mètode convenient per migrar d'un servidor RDBMS a un altre.
Les bases de dades PostgreSQL i MySQL es consideren tradicionalment relacionals, però amb extensions addicionals ofereixen capacitats NoSQL. Aquí parlarem de la replicació entre PostgreSQL i MySQL des d'una perspectiva de gestió de bases de dades relacionals.
No descriurem tots els elements interns, només els principis bàsics, de manera que us feu una idea de la configuració de rèplica entre servidors de bases de dades, avantatges, limitacions i casos d'ús.
Normalment, la replicació entre dos servidors de bases de dades idèntics es fa en mode binari o mitjançant consultes entre un mestre (també conegut com a editor, mestre o actiu) i un esclau (subscriptor, en espera o passiu). L'objectiu de la replicació és proporcionar una còpia en temps real de la base de dades mestra al costat d'espera. En aquest cas, les dades es transfereixen de mestre a esclau, és a dir, d'actiu a passiu, perquè la replicació només es realitza en una direcció. Però podeu configurar la replicació entre les dues bases de dades en ambdues direccions, de manera que les dades es transfereixen de l'esclau al mestre en una configuració actiu-actiu. Tot això, inclosa la rèplica en cascada, és possible entre dos o més servidors de bases de dades idèntics. La configuració actiu-actiu o actiu-passiu depèn de la necessitat, la disponibilitat d'aquestes capacitats en la configuració inicial o l'ús de solucions de sintonització externes i el comerç existent. - apagats.
La configuració descrita és possible entre diferents servidors de bases de dades. El servidor es pot configurar per rebre dades replicades d'un altre servidor de bases de dades i encara conservar instantànies en temps real de les dades replicades. MySQL i PostgreSQL ofereixen la majoria d'aquestes configuracions de manera nativa o mitjançant extensions de tercers, inclosos mètodes de registre binaris, bloquejos de disc i mètodes basats en declaracions i files.
La replicació creuada entre MySQL i PostgreSQL és necessària per a una migració única d'un servidor de bases de dades a un altre. Aquestes bases de dades utilitzen protocols diferents, de manera que no les podeu enllaçar directament. Per facilitar l'intercanvi de dades, podeu utilitzar una eina externa de codi obert, com ara pg_chameleon.
Què és pg_chameleon
pg_chameleon és un sistema de replicació de MySQL a PostgreSQL a Python 3. Utilitza la biblioteca de codi obert mysql-replication, també a Python. Les imatges de fila es recuperen de les taules MySQL i s'emmagatzemen com a objectes JSONB a la base de dades PostgreSQL, i després es descodifiquen mitjançant la funció pl/pgsql i es reprodueixen a la base de dades PostgreSQL.
Característiques de pg_chameleon
Es poden replicar diversos esquemes MySQL del mateix clúster en una única base de dades de destinació PostgreSQL amb una configuració d'un a molts
Els noms d'esquema d'origen i de destinació no poden ser els mateixos.
Les dades de replicació es poden recuperar d'una rèplica en cascada de MySQL.
S'exclouen les taules que no poden replicar ni generar errors.
Cada funció de replicació està controlada per dimonis.
Control amb paràmetres i fitxers de configuració basats en YAML.
Exemple
Amfitrió
vm1
vm2
versió del sistema operatiu
CentOS Linux 7.6 x86_64
CentOS Linux 7.5 x86_64
Versió del servidor de bases de dades
MySQL 5.7.26
PostgreSQL 10.5
Port de base de dades
3306
5433
Adreça IP
192.168.56.102
192.168.56.106
Primer, prepareu tots els components necessaris per instal·lar pg_chameleon. Aquest exemple té instal·lat Python 3.6.8, que crea un entorn virtual i l'activa.
$> 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 altinstallUn cop instal·lat Python3.6 correctament, s'han de completar la resta de requisits, com ara crear i activar un entorn virtual. A més, el mòdul pip s'actualitza a la darrera versió i s'utilitza per instal·lar pg_chameleon. Les ordres següents instal·len intencionadament pg_chameleon 2.0.9, tot i que l'última versió és la 2.0.10. Això és necessari per evitar nous errors en la versió actualitzada.
$> python3.6 -m venv venv
$> source venv/bin/activate
(venv) $> pip install pip --upgrade
(venv) $> pip install pg_chameleon==2.0.9A continuació, cridem a pg_chameleon (chameleon és una ordre) amb l'argument set_configuration_files per habilitar pg_chameleon i crear els directoris i fitxers de configuració per defecte.
(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.ymlAra fem una còpia de config-example.yml com a default.yml perquè es converteixi en el fitxer de configuració predeterminat. A continuació es proporciona un fitxer de configuració d'exemple per a aquest exemple.
$> 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:El fitxer de configuració d'aquest exemple és un fitxer pg_chameleon de mostra amb modificacions menors per coincidir amb els entorns d'origen i de destinació, i a continuació es mostra una visió general de les diferents seccions del fitxer de configuració.
El fitxer de configuració default.yml té una secció de paràmetres globals (configuració global) on podeu controlar paràmetres com ara la ubicació del fitxer de bloqueig, la ubicació dels registres, el període d'emmagatzematge dels registres, etc. A continuació ve la substitució del tipus. secció, on s'estableixen les regles per anul·lar els tipus durant la replicació. L'exemple per defecte utilitza una regla de substitució de tipus que converteix tinyint(1) en un booleà. A la següent secció, especifiquem els detalls de la connexió a la base de dades de destinació. En el nostre cas, es tracta d'una base de dades PostgreSQL, denotada com a pg_conn. En l'últim apartat, especifiquem les dades d'origen, és a dir, els paràmetres de connexió de la base de dades d'origen, l'esquema de mapatge de les bases de dades d'origen i de destinació, taules que s'han d'ometre, temps d'espera, memòria, mida del paquet. Tingueu en compte que "fonts" és plural, el que significa que podem afegir diverses bases de dades d'origen al mateix objectiu per configurar una configuració de molts a un.
La base de dades world_x de l'exemple conté 4 taules amb files que la comunitat MySQL suggereix per a l'exemple. Es pot descarregar . La base de dades de mostra es presenta com un arxiu tar i comprimit amb instruccions per crear i importar cadenes.
Es crea un usuari especial amb el mateix nom usr_replica a les bases de dades MySQL i PostgreSQL. MySQL li concedeix accés de lectura addicional a totes les taules replicades.
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;Al costat de PostgreSQL, es crea una base de dades db_replica que acceptarà els canvis de la base de dades MySQL. L'usuari usr_replica a PostgreSQL es configura automàticament com a propietari dels dos esquemes pgworld_x i sch_chameleon, que contenen les taules replicades reals i les taules del catàleg de rèplica, respectivament. L'argument create_replica_schema és responsable de la configuració automàtica, com veureu a continuació.
postgres=# CREATE USER usr_replica WITH PASSWORD 'pass123';
CREATE ROLE
postgres=# CREATE DATABASE db_replica WITH OWNER usr_replica;
CREATE DATABASELa base de dades MySQL està configurada amb alguns canvis per preparar-la per a la replicació, tal com es mostra a continuació. Haureu de reiniciar el servidor de bases de dades perquè els canvis tinguin efecte.
$> vi /etc/my.cnf
binlog_format= ROW
binlog_row_image=FULL
log-bin = mysql-bin
server-id = 1Ara és important comprovar la connexió amb els dos servidors de bases de dades perquè no hi hagi problemes en executar les ordres pg_chameleon.
Al node PostgreSQL:
$> mysql -u usr_replica -Ap'admin123' -h 192.168.56.102 -D world_xAl node MySQL:
$> psql -p 5433 -U usr_replica -h 192.168.56.106 db_replicaLes tres ordres pg_chameleon (camaleó) següents preparen l'entorn, afegeixen la font i inicialitzen la rèplica. L'argument create_replica_schema per a pg_chameleon crea un esquema predeterminat (sch_chameleon) i un esquema de replicació (pgworld_x) a la base de dades PostgreSQL, com hem dit. L'argument add_source afegeix una base de dades d'origen a la configuració llegint el fitxer de configuració (default.yml), que en el nostre cas és mysql, i init_replica inicialitza la configuració en funció de la configuració del fitxer de configuració.
$> chameleon create_replica_schema --debug
$> chameleon add_source --config default --source mysql --debug
$> chameleon init_replica --config default --source mysql --debugLa sortida d'aquestes tres ordres indica clarament el seu èxit. Tots els errors o errors de sintaxi s'indiquen en missatges senzills i entenedors amb consells sobre com solucionar els problemes.
Finalment, comencem la replicació amb start_replica i obtenim un missatge d'èxit.
$> chameleon start_replica --config default --source mysql
output: Starting the replica process for source mysqlL'estat de la rèplica es pot consultar amb l'argument show_status i els errors es poden veure amb l'argument show_errors.
Com ja hem dit, els dimonis gestionen totes les funcions de replicació. Per visualitzar-los, consulteu la taula de processos amb l'ordre Linux ps, tal com es mostra a continuació.
La replicació no es considera configurada fins que la provem en temps real, tal com es mostra a continuació. Creem una taula, inserim un parell de registres a la base de dades MySQL i cridem a l'argument sync_tables a pg_chameleon per actualitzar els dimonis i replicar la taula amb els registres a la base de dades PostgreSQL.
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.Per validar els resultats de la prova, consultem la taula des de la base de dades PostgreSQL i donem sortida a les files.
$> psql -p 5433 -U usr_replica -d db_replica -c "select * from pgworld_x.t1";
n1 | n2
----+-------
1 | one
2 | twoSi estem migrant, les ordres pg_chameleon següents seran el final de la migració. Les ordres s'han d'executar després d'haver verificat que les files de totes les taules de destinació s'han replicat, donant lloc a una base de dades PostgreSQL perfectament migrada sense referències a la base de dades d'origen ni a l'esquema de replicació (sch_chameleon).
$> chameleon stop_replica --config default --source mysql
$> chameleon detach_replica --config default --source mysql --debugOpcionalment, podeu suprimir la configuració original i l'esquema de rèplica amb les ordres següents.
$> chameleon drop_source --config default --source mysql --debug
$> chameleon drop_replica_schema --config default --source mysql --debugBeneficis de pg_chameleon
Fàcil configuració i configuració.
Solució de problemes convenient i detecció d'anomalies amb missatges d'error clars.
Es poden afegir taules especials addicionals a la rèplica després de la inicialització sense canviar la resta de la configuració.
És possible configurar diverses bases de dades d'origen per a una base de dades de destinació, i això és molt útil si fusioneu dades d'una o més bases de dades MySQL en una base de dades PostgreSQL.
Podeu optar per no replicar les taules seleccionades.
Desavantatges de pg_chameleon
Només és compatible amb MySQL 5.5 i superior com a font i PostgreSQL 9.5 i posterior com a base de dades de destinació.
Cada taula ha de tenir una clau primària o única, en cas contrari, les taules s'inicialitzen al procés init_replica però no es repliquen.
Replicació unidireccional: només de MySQL a PostgreSQL. Per tant, només és adequat per a l'esquema actiu-passiu.
La font només pot ser una base de dades MySQL i el suport per a una base de dades PostgreSQL com a font només és experimental i limitada (més informació )
Totals de pg_chameleon
El mètode de replicació a pg_chameleon és ideal per migrar una base de dades de MySQL a PostgreSQL. El gran inconvenient és que la replicació només és unidireccional, de manera que és poc probable que els professionals de la base de dades la vulguin utilitzar per a qualsevol altra cosa que no sigui la migració. Però el problema de la replicació unidireccional es pot resoldre amb una altra eina de codi obert: SymmetricDS.
Llegeix més a la documentació oficial . Es pot trobar ajuda de la línia d'ordres .
Visió general de SymmetricDS
SymmetricDS és una eina de codi obert que replica qualsevol base de dades a qualsevol altra base de dades comuna: Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird i altres instàncies de bases de dades al núvol, per exemple Redshift, i Azure, etc. Funcions disponibles: sincronització de bases de dades i fitxers, rèplica de bases de dades multimaster, sincronització filtrat, transformació i altres. Aquesta és una eina Java i requereix la versió estàndard JRE o JDK (versió 8.0 o superior). Aquí podeu registrar els canvis de dades dels activadors de la base de dades d'origen i enviar-los a la base de dades de destinació adequada com a lots.
Capacitats SymmetricDS
L'eina és independent de la plataforma, és a dir, dues o més bases de dades diferents poden intercanviar dades.
Les bases de dades relacionals es sincronitzen registrant els canvis de dades, i les bases de dades basades en sistemes de fitxers utilitzen la sincronització de fitxers.
Replicació bidireccional mitjançant mètodes push i pull basats en un conjunt de regles.
La transmissió de dades és possible a través de xarxes segures i xarxes amb baix ample de banda.
Recuperació automàtica quan els nodes es reprenen després d'una fallada i resolució automàtica de conflictes.
API d'extensió eficients i compatibles amb el núvol.
Exemple
SymmetricDS es pot configurar de dues maneres:
Un node mestre (parent) que coordina centralment la replicació de dades entre dos nodes esclaus (fills) i l'intercanvi de dades entre nodes fill només es realitza a través del pare.
Un node actiu (node 1) pot comunicar-se per a la replicació amb un altre node actiu (node 2) sense intermediari.
En ambdues opcions, l'intercanvi de dades es fa mitjançant Push i Pull. En aquest exemple, considerarem la configuració actiu-actiu. És massa llarg per descriure tota l'arquitectura, així que estudia per obtenir més informació sobre l'aparell SymmetricDS.
Instal·lar SymmetricDS és fàcil: descarregueu el fitxer zip de codi obert i extreu-lo allà on vulgueu. La taula següent enumera la ubicació i la versió d'instal·lació de SymmetricDS en aquest exemple, així com les versions de la base de dades, les versions de Linux, les adreces IP i els ports dels dos nodes.
Amfitrió
vm1
vm2
versió del sistema operatiu
CentOS Linux 7.6 x86_64
CentOS Linux 7.6 x86_64
Versió del servidor de bases de dades
MySQL 5.7.26
PostgreSQL 10.5
Port de base de dades
3306
5832
Adreça IP
192.168.1.107
192.168.1.112
Versió SymmetricDS
SymmetricDS 3.9
SymmetricDS 3.9
Camí d'instal·lació de SymmetricDS
/usr/local/symmetric-server-3.9.20
/usr/local/symmetric-server-3.9.20
Nom d'amfitrió SymmetricDS
corp-000
botiga-001
Aquí instal·lem SymmetricDS a /usr/local/symmetric-server-3.9.20 i hi emmagatzemaran diversos subdirectoris i fitxers. Estem interessats en els subdirectoris mostres i motors. El directori de mostres conté fitxers de configuració d'exemple amb propietats de nodes, així com scripts SQL d'exemple per iniciar ràpidament la demostració.
Al directori de mostres, veiem tres fitxers de configuració amb propietats del node: el nom mostra la naturalesa del node en un esquema particular.
corp-000.properties
store-001.properties
store-002.propertiesSymmetricDS té tots els fitxers de configuració necessaris per a un esquema bàsic de 3 nodes (opció 1) i els mateixos fitxers es poden utilitzar per a un esquema de 2 nodes (opció 2). Copieu el fitxer de configuració necessari del directori de mostres als motors de l'amfitrió vm1. Resulta així:
$> 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=000Aquest node s'anomena corp-000 a la configuració de SymmetricDS i la connexió a la base de dades la gestiona el controlador mysql jdbc que utilitza la cadena de connexió anterior i les credencials d'inici de sessió. Ens estem connectant a la base de dades replica_db i les taules es crearan durant la creació de l'esquema. sync.url mostra l'enllaç al node a sincronitzar.
El node 2 de l'amfitrió vm2 està configurat com a store-001 i la resta s'especifica al fitxer node.properties següent. El node store-001 executa la base de dades PostgreSQL i pgdb_replica és la base de dades a replicar. registration.url permet a l'amfitrió vm2 contactar amb l'amfitrió vm1 i obtenir-ne els detalls de configuració.
$> 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=001L'exemple de SymmetricDS completat conté opcions per configurar la rèplica bidireccional entre dos servidors de bases de dades (dos nodes). Els passos següents es realitzen a l'amfitrió vm1 (corp-000) que crearà un esquema de mostra amb 4 taules. A continuació, executant create-sym-tables amb l'ordre symadmin es crea taules de directoris on s'emmagatzemaran les regles i la direcció de replicació entre nodes. Finalment, les dades de mostra es carreguen a les taules.
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.sqlA l'exemple, les taules article i item_selling_price es configuren automàticament per replicar-se de corp-000 a store-001, i les taules de venda (sale_transaction i sale_return_line_item) es configuren automàticament per replicar-se de store-001 a corp-000. Ara creem un esquema a la base de dades PostgreSQL a l'amfitrió vm2 (store-001) per preparar-lo per rebre dades de corp-000.
vm2$> cd /usr/local/symmetric-server-3.9.20/bin
vm2$> ./dbimport --engine store-001 --format XML create_sample.xmlAssegureu-vos de comprovar que la base de dades MySQL a vm1 té taules de mostra i una taula de catàleg SymmetricDS. Tingueu en compte que les taules del sistema SymmetricDS (prefixades amb sym_) actualment només estan disponibles al node corp-000, perquè és on vam executar l'ordre create-sym-tables i gestionarem la replicació. I a la base de dades del node store-001 només hi haurà 4 taules d'exemple sense dades.
Tots. L'entorn està preparat per executar processos del servidor sym als dos nodes, tal com es mostra a continuació.
vm1$> cd /usr/local/symmetric-server-3.9.20/bin
vm1$> sym 2>&1 &Les entrades de registre s'envien al fitxer de registre de fons (symmetric.log) a la carpeta de registre del directori on està instal·lat SymmetricDS, així com a la sortida estàndard. El servidor sym ara es pot iniciar al node store-001.
vm2$> cd /usr/local/symmetric-server-3.9.20/bin
vm2$> sym 2>&1 &Si executeu el procés del servidor sym a l'amfitrió vm2, també crearà les taules de catàleg SymmetricDS a la base de dades PostgreSQL. Si executeu el procés del servidor sym als dos nodes, es coordinaran entre ells per replicar les dades de corp-000 a store-001. Si al cap d'uns segons consultem les 4 taules a banda i banda, veurem que la replicació ha estat correcta. O podeu enviar el bootstrap a store-001 des de corp-000 amb l'ordre següent.
vm1$> ./symadmin --engine corp-000 reload-node 001En aquest punt, s'insereix un registre nou a la taula d'elements de la base de dades MySQL al node corp-000 (amfitrió: vm1) i es pot comprovar si hi ha rèplica a la base de dades PostgreSQL al node store-001 (amfitrió: vm2). Veiem una operació Pull per moure dades de corp-000 a 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)Per dur a terme una operació push per moure dades de store-001 a corp-000, inserim un registre a la taula sale_transaction i verifiquem que la replicació s'ha completat.
Veiem una configuració exitosa de la replicació bidireccional de les taules d'exemple entre les bases de dades MySQL i PostgreSQL. Per configurar la rèplica per a taules d'usuari noves, seguiu els passos següents. Creem la taula t1 per exemple i configurem les seves regles de replicació de la següent manera. Així que vam configurar només la replicació de corp-000 a 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)A continuació, es notifica a la configuració el canvi d'esquema, és a dir, l'addició d'una taula nova, mitjançant l'ordre symadmin amb l'argument sync-triggers, que recrea els activadors per coincidir amb les definicions de la taula. Send-schema s'executa per enviar canvis d'esquema a store-001 i es replica la taula t1.
vm1$> ./symadmin -e corp-000 --node=001 sync-triggers
vm1$> ./symadmin send-schema -e corp-000 --node=001 t1Beneficis de SymmetricDS
Fàcil instal·lació i configuració, inclòs un conjunt ja fet de fitxers amb paràmetres per crear un esquema amb tres o dos nodes.
Bases de dades multiplataforma i independència de la plataforma, inclosos servidors, ordinadors portàtils i dispositius mòbils.
Replica qualsevol base de dades a qualsevol altra base de dades localment, a la WAN o al núvol.
Capacitat de treballar de manera òptima amb un parell de bases de dades o diversos milers per a una fàcil replicació.
Versió de pagament amb GUI i excel·lent assistència.
Inconvenients de SymmetricDS
Heu de definir manualment les regles i la direcció de replicació a la línia d'ordres mitjançant instruccions SQL per carregar les taules de catàleg, cosa que pot ser inconvenient.
Configurar moltes taules per a la replicació pot ser tediós tret que utilitzeu scripts per crear sentències SQL que defineixin les regles i la direcció de la replicació.
Hi ha massa informació als registres i, de vegades, cal netejar el fitxer de registre perquè no ocupi massa espai.
Resum de SymmetricDS
SymmetricDS us permet configurar una rèplica bidireccional entre dos, tres o fins i tot diversos milers de nodes per tal de replicar i sincronitzar fitxers. És una eina única que realitza moltes tasques per si sola, com ara la recuperació automàtica de dades després d'un llarg temps d'inactivitat en un node, una comunicació segura i eficient entre nodes a través d'HTTPS, una gestió automàtica de conflictes basada en un conjunt de regles, etc. SymmetricDS replica. entre qualsevol base de dades, per tant, es pot utilitzar per a una gran varietat d'escenaris, com ara la migració, l'actualització, la distribució, el filtratge i la transformació de dades entre plataformes.
L'exemple es basa en l'oficial per SymmetricDS. EN Descriu amb detall els diferents conceptes implicats en la configuració de la replicació amb SymmetricDS.
Font: www.habr.com