Describiré la replicación cruzada entre PostgreSQL y MySQL, así como los métodos para configurar la replicación cruzada entre estos dos servidores de bases de datos. Por lo general, las bases de datos de replicación cruzada se denominan homogéneas, y este es un método conveniente para pasar de un servidor de base de datos relacional a otro.
Las bases de datos PostgreSQL y MySQL se consideran relacionales, pero con extensiones adicionales ofrecen funciones NoSQL. Aquí discutiremos la replicación entre PostgreSQL y MySQL, en términos de DBMS relacional.
No describiremos toda la cocina interior, solo los principios básicos, para que tenga una idea de cómo configurar la replicación entre servidores de bases de datos, las ventajas, limitaciones y escenarios de uso.
Por lo general, la replicación entre dos servidores de bases de datos idénticos se realiza en modo binario o mediante solicitudes entre el nodo maestro (es el editor, maestro o activo) y el esclavo (suscriptor, pendiente o pasivo). El propósito de la replicación es proporcionar una copia en tiempo real de la base de datos maestra en el lado esclavo. En este caso, los datos se transfieren del maestro al esclavo, es decir, de activo a pasivo, porque la replicación se realiza solo en una dirección. Pero puede configurar la replicación entre dos bases de datos en ambas direcciones, de modo que los datos se transfieran del esclavo al maestro en la configuración activo-activo. Todo esto, incluida la replicación en cascada, posiblemente entre dos o más servidores de bases de datos idénticos. La configuración activo-activo o activo-pasivo depende de la necesidad, la disponibilidad de tales características en la configuración inicial o el uso de soluciones de configuración externas y compensaciones existentes. .
La configuración descrita es posible entre diferentes servidores de bases de datos. El servidor se puede configurar para recibir datos replicados de otro servidor de bases de datos y aún así guardar instantáneas en tiempo real de los datos replicados. MySQL y PostgreSQL ofrecen la mayoría de estas configuraciones por sí mismas o con extensiones de terceros, incluidos los métodos de registro binario, bloqueos de disco y métodos basados en sentencias y cadenas.
La replicación cruzada entre MySQL y PostgreSQL es necesaria para una única migración de un servidor de base de datos a otro. Estas bases de datos utilizan diferentes protocolos, por lo que no pueden conectarse directamente. Para establecer el intercambio de datos, puede usar una herramienta externa de código abierto, por ejemplo pg_chameleon.
¿Qué es pg_chameleon?
pg_chameleon es un sistema de replicación de MySQL a PostgreSQL en Python 3. Utiliza la biblioteca de código abierto mysql-replication, también en Python. Las imágenes de cadena se extraen de las tablas MySQL y se almacenan como objetos JSONB en la base de datos PostgreSQL, y luego se descifran mediante la función pl / pgsql y se reproducen en la base de datos PostgreSQL.
Pg_chameleon características
Se pueden replicar múltiples esquemas MySQL del mismo clúster en la misma base de datos de destino PostgreSQL con una configuración de uno a muchos
Los nombres de los esquemas de origen y destino no pueden coincidir.
Los datos de replicación se pueden recuperar de una réplica en cascada de MySQL.
Se excluyen las tablas que no pueden replicarse o generar errores.
Cada función de replicación está controlada por demonios.
Control utilizando parámetros y archivos de configuración basados en YAML.
Ejemplo
Para comenzar, prepare todos los componentes necesarios para instalar pg_chameleon. En este ejemplo, se instala Python 3.6.8, que crea un entorno virtual y lo 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 altinstall
Después de instalar con éxito Python3.6, debe cumplir con los otros requisitos, por ejemplo, crear y activar un entorno virtual. Además, el módulo pip se actualiza a la última versión y se utiliza para instalar pg_chameleon. En los comandos a continuación, pg_chameleon 2.0.9 se instala intencionalmente, aunque la última versión es 2.0.10. Esto es necesario para evitar nuevos errores en la versión actualizada.
$> python3.6 -m venv venv $> source venv/bin/activate (venv) $> pip install pip --upgrade (venv) $> pip install pg_chameleon==2.0.9
Luego llamamos a pg_chameleon (chameleon es un comando) con el argumento set_configuration_files para habilitar pg_chameleon y crear directorios y archivos de configuración predeterminados.
(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
Ahora creamos una copia de config-example.yml como default.yml para que se convierta en el archivo de configuración predeterminado. A continuación se muestra un archivo de configuración de muestra para este ejemplo.
$> 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 archivo de configuración en este ejemplo es un archivo de muestra con pg_chameleon con cambios menores de acuerdo con los entornos de origen y destino, y la siguiente es una descripción general de las diversas secciones del archivo de configuración.
En el archivo de configuración default.yml, hay una sección de configuración global donde puede controlar configuraciones como la ubicación del archivo de bloqueo, la ubicación de los registros, el período de almacenamiento de registros, etc. La siguiente sección es la sección de anulación de tipo, donde el conjunto reglas para anular tipos durante la replicación. El ejemplo predeterminado usa una regla de redefinición de tipo que convierte tinyint (1) en un valor booleano. En la siguiente sección, indicamos los detalles de la conexión a la base de datos de destino. En nuestro caso, esta es una base de datos PostgreSQL designada como pg_conn. En la última sección, indicamos los datos de origen, es decir, los parámetros de conexión de la base de datos de origen, el esquema de mapeo de las bases de datos de origen y destino, las tablas a omitir, el tiempo de espera, la memoria y el tamaño del paquete. Tenga en cuenta que "fuentes" se indica en plural, es decir, podemos agregar varias bases de datos de origen para el mismo objetivo para configurar la configuración de muchos a uno.
La base de datos world_x en el ejemplo contiene 4 tablas con filas que la comunidad MySQL ofrece para el ejemplo. Se puede descargar aquí . La base de datos de muestra viene en forma de tar y un archivo comprimido con instrucciones para crear e importar cadenas.
Se crea un usuario especial en las bases de datos MySQL y PostgreSQL con el mismo nombre usr_replica. En MySQL, se le otorgan derechos adicionales para leer todas las tablas replicadas.
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;
En el lado de PostgreSQL, se crea la base de datos db_replica, que aceptará cambios de la base de datos MySQL. El usuario usr_replica de PostgreSQL se configura automáticamente como el propietario de dos esquemas pgworld_x y sch_chameleon que contienen tablas replicadas reales y tablas con directorios de replicación respectivamente. El argumento create_replica_schema es responsable de la configuración automática, como verá a continuación.
postgres=# CREATE USER usr_replica WITH PASSWORD 'pass123'; CREATE ROLE postgres=# CREATE DATABASE db_replica WITH OWNER usr_replica; CREATE DATABASE
La base de datos MySQL está configurada con algunos cambios para prepararla para la replicación, como se muestra a continuación. Deberá reiniciar el servidor de la base de datos para que los cambios surtan efecto.
$> vi /etc/my.cnf binlog_format= ROW binlog_row_image=FULL log-bin = mysql-bin server-id = 1
Ahora es importante verificar la conexión a ambos servidores de bases de datos para que no haya problemas al ejecutar los comandos pg_chameleon.
En el nodo PostgreSQL:
$> mysql -u usr_replica -Ap'admin123' -h 192.168.56.102 -D world_x
En el nodo MySQL:
$> psql -p 5433 -U usr_replica -h 192.168.56.106 db_replica
Los siguientes tres comandos pg_chameleon (chameleon) preparan el entorno, agregan la fuente e inicializan la réplica. El argumento create_replica_schema en pg_chameleon crea el esquema predeterminado (sch_chameleon) y el esquema de replicación (pgworld_x) en la base de datos PostgreSQL, como ya dijimos. El argumento add_source agrega la base de datos original a la configuración leyendo el archivo de configuración (default.yml), y en nuestro caso es mysql, y init_replica inicializa la configuración en función de los parámetros en el archivo de configuración.
$> chameleon create_replica_schema --debug $> chameleon add_source --config default --source mysql --debug $> chameleon init_replica --config default --source mysql --debug
La salida de estos tres comandos obviamente indica su ejecución exitosa. Todos los bloqueos o errores de sintaxis se indican en mensajes simples y claros con consejos para la solución de problemas.
Finalmente, inicie la replicación con start_replica y obtenga un mensaje de éxito.
$> chameleon start_replica --config default --source mysql output: Starting the replica process for source mysql
El estado de replicación se puede solicitar usando el argumento show_status, y los errores se pueden ver usando el argumento show_errors.
Resultado
Como dijimos antes, cada función de replicación está controlada por demonios. Para verlos, consultamos la tabla de proceso con el comando ps de Linux, como se muestra a continuación.
Resultado
La replicación no se considera configurada hasta que la probamos en tiempo real, como se muestra a continuación. Creamos una tabla, insertamos un par de registros en la base de datos MySQL y llamamos al argumento sync_tables en pg_chameleon para actualizar los demonios y replicar la tabla con los registros en la base de datos 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.
Para confirmar los resultados de la prueba, consultamos la tabla de la base de datos PostgreSQL y mostramos las filas.
$> psql -p 5433 -U usr_replica -d db_replica -c "select * from pgworld_x.t1"; n1 | n2 ----+------- 1 | one 2 | two
Si realizamos la migración, los siguientes comandos pg_chameleon serán su final. Los comandos deben ejecutarse después de asegurarnos de que las filas de todas las tablas de destino se hayan replicado, y el resultado será una base de datos PostgreSQL perfectamente migrada sin referencia a la base de datos de origen o al esquema de replicación (sch_chameleon).
$> chameleon stop_replica --config default --source mysql $> chameleon detach_replica --config default --source mysql --debug
Si lo desea, los siguientes comandos pueden eliminar la configuración original y el esquema de replicación.
$> chameleon drop_source --config default --source mysql --debug $> chameleon drop_replica_schema --config default --source mysql --debug
Beneficios de pg_chameleon
Fácil instalación y configuración.
Solución de problemas y detección de anomalías con mensajes de error claros.
Puede agregar tablas especiales adicionales a la replicación después de la inicialización sin cambiar el resto de la configuración.
Puede configurar varias bases de datos de origen para un destino, y esto es muy conveniente si combina datos de una o varias bases de datos MySQL en una base de datos PostgreSQL.
No puede replicar tablas seleccionadas.
Desventajas de pg_chameleon
Solo es compatible con MySQL 5.5 y superior como fuente y PostgreSQL 9.5 y superior como base de datos de destino.
Cada tabla debe tener una clave primaria o única; de lo contrario, las tablas se inicializan en el proceso init_replica, pero no se replican.
Replicación unidireccional: solo de MySQL a PostgreSQL. Por lo tanto, es adecuado solo para el esquema activo-pasivo.
Solo la base de datos MySQL puede ser la fuente y el soporte para la base de datos PostgreSQL ya que la fuente es solo experimental y con limitaciones (obtenga más información aquí )
Pg_chameleon resultados
El método de replicación en pg_chameleon es excelente para migrar una base de datos de MySQL a PostgreSQL. Una desventaja significativa es que la replicación es solo unidireccional, por lo que es poco probable que los expertos en bases de datos quieran usarla para otra cosa que no sea la migración. Pero el problema de la replicación unidireccional puede resolverse con otra herramienta de código abierto: SymmetricDS.
Lea más en la documentación oficial aquí . Puede encontrar ayuda en la línea de comando aquí .
Descripción general de SymmetricDS
SymmetricDS es una herramienta de código abierto que replica cualquier base de datos a cualquier otra base de datos común: Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird y otras instancias de bases de datos en la nube, por ejemplo Redshift y Azure, etc. Funciones disponibles: sincronización de bases de datos y archivos, replicación de varias bases de datos líderes, sincronización filtrada, conversión y otras. Esta es una herramienta de Java y requiere una versión estándar de JRE o JDK (versión 8.0 o superior). Aquí puede registrar los cambios de datos en los desencadenantes en la base de datos de origen y enviarlos a la base de datos de destino correspondiente en forma de paquetes.
Características de SymmetricDS
La herramienta es independiente de la plataforma, es decir, dos o más bases de datos diferentes pueden intercambiar datos.
Las bases de datos relacionales se sincronizan escribiendo cambios de datos, y las bases de datos basadas en el sistema de archivos utilizan la sincronización de archivos.
Replicación bidireccional utilizando los métodos Push y Pull basados en un conjunto de reglas.
La transmisión de datos es posible a través de redes seguras y redes con bajo ancho de banda.
Recuperación automática cuando los nodos se reanudan después de una falla y resolución automática de conflictos.
API de extensión potente y compatible con la nube.
Ejemplo
SymmetricDS se puede configurar de una de dos maneras:
Un nodo maestro (padre) que coordina centralmente la replicación de datos entre dos nodos esclavos (hijo), y el intercambio de datos entre nodos hijos se realiza solo a través del padre.
El nodo activo (nodo 1) puede intercambiar datos para la replicación con otro nodo activo (nodo 2) sin un intermediario.
En ambos casos, los datos se intercambian mediante Push y Pull. En este ejemplo, veremos la configuración activo-activo. Describa toda la arquitectura durante demasiado tiempo, así que consulte la guía para obtener más información sobre SymmetricDS.
Instalar SymmetricDS es muy simple: descargue la versión de código abierto del archivo zip desde aquí y extráigala donde desee. La siguiente tabla proporciona información sobre la ubicación de instalación y la versión de SymmetricDS en este ejemplo, así como las versiones de la base de datos, las versiones de Linux, las direcciones IP y los puertos para ambos nodos.
Aquí instalamos SymmetricDS en /usr/local/symmetric-server-3.9.20, y allí se almacenarán diferentes subdirectorios y archivos. Estamos interesados en los directorios y ejemplos de directorios anidados. El directorio de muestras contiene archivos de configuración de muestra con propiedades de host, así como scripts SQL de muestra para comenzar rápidamente la demostración.
En el directorio de ejemplos, vemos tres archivos de configuración con propiedades de nodo: el nombre muestra la naturaleza del nodo en un esquema particular.
corp-000.properties store-001.properties store-002.properties
SymmetricDS tiene todos los archivos de configuración necesarios para un esquema base de 3 nodos (opción 1), y los mismos archivos se pueden usar para un esquema de 2 nodos (opción 2). Copie el archivo de configuración deseado del directorio de muestras a los motores en el host vm1. Resulta así:
$> 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
Este nodo en la configuración de SymmetricDS se llama corp-000, y la conexión de la base de datos es procesada por el controlador mysql jdbc, que utiliza la cadena de conexión especificada anteriormente y las credenciales de inicio de sesión. Nos conectamos a la base de datos replica_db, y las tablas se crearán durante la creación del esquema. sync.url muestra el sitio de comunicación con el nodo para la sincronización.
El nodo 2 en el host vm2 está configurado como store-001, y el resto se especifica en el archivo node.properties a continuación. El nodo store-001 ejecuta la base de datos PostgreSQL y pgdb_replica es la base de datos para la replicación. registration.url permite que el host vm2 se ponga en contacto con el host vm1 y obtenga detalles de configuración de este.
$> 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
El ejemplo precompilado de SymmetricDS contiene opciones para configurar la replicación bidireccional entre dos servidores de bases de datos (dos nodos). Los pasos a continuación se realizan en el host vm1 (corp-000), que creará un esquema de ejemplo con 4 tablas. Luego, la ejecución de create-sym-tables con el comando symadmin crea tablas de directorio donde se almacenarán las reglas y la dirección de replicación entre los nodos. Finalmente, los datos de muestra se cargan en las tablas.
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
En el ejemplo, las tablas item y item_selling_price se configuran automáticamente para replicar de corp-000 a store-001, y las tablas de venta (sale_transaction y sale_return_line_item) se configuran automáticamente para replicar de store-001 a corp-000. Ahora cree el esquema en la base de datos PostgreSQL en el host vm2 (store-001) para prepararlo para recibir datos de corp-000.
vm2$> cd /usr/local/symmetric-server-3.9.20/bin vm2$> ./dbimport --engine store-001 --format XML create_sample.xml
Asegúrese de verificar que la base de datos MySQL en vm1 tenga tablas de muestra y tablas de directorio SymmetricDS. Tenga en cuenta que las tablas del sistema SymmetricDS (con el prefijo sym_) ahora están disponibles solo en el host corp-000, porque allí ejecutamos el comando create-sym-tables y gestionaremos la replicación. Y en la base de datos en el nodo store-001 solo habrá 4 tablas de ejemplo sin datos.
Eso es todo. El entorno está listo para ejecutar procesos del servidor sym en ambos nodos, como se muestra a continuación.
vm1$> cd /usr/local/symmetric-server-3.9.20/bin vm1$> sym 2>&1 &
Las entradas de registro se envían al archivo de registro de fondo (symmetric.log) en la carpeta de registro en el directorio donde está instalado SymmetricDS, así como a la salida estándar. El servidor sym ahora se puede iniciar en el nodo store-001.
vm2$> cd /usr/local/symmetric-server-3.9.20/bin vm2$> sym 2>&1 &
Si ejecuta el proceso del servidor sym en el host vm2, también creará las tablas del catálogo SymmetricDS en la base de datos PostgreSQL. Si ejecuta el proceso del servidor sym en ambos nodos, se coordinan entre sí para replicar los datos de corp-000 a store-001. Si después de unos segundos consultamos las 4 tablas en ambos lados, veremos que la replicación es exitosa. O puede enviar el bootstrap a store-001 desde corp-000 con el siguiente comando.
vm1$> ./symadmin --engine corp-000 reload-node 001
En este punto, se inserta un nuevo registro en la tabla de elementos en la base de datos MySQL en el host corp-000 (host: vm1), y puede verificar su replicación en la base de datos PostgreSQL en el host store-001 (host: vm2). Vemos una operación Pull para mover datos 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)
Para realizar una operación Push para mover datos desde store-001 a corp-000, inserte un registro en la tabla sale_transaction y verifique que la replicación se haya completado.
Resultado
Vemos una configuración exitosa de la replicación bidireccional de tablas de muestra entre las bases de datos MySQL y PostgreSQL. Para configurar la replicación para nuevas tablas de usuario, haga lo siguiente: Creamos la tabla t1 como ejemplo y configuramos las reglas para su replicación de la siguiente manera. Por lo tanto, solo configuramos la replicación 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)
Luego se notifica a la configuración un cambio de esquema, es decir, la adición de una nueva tabla, utilizando el comando symadmin con el argumento sync-triggers, que recrea los activadores para que coincidan con las definiciones de la tabla. Send-schema se ejecuta para enviar los cambios de esquema al nodo store-001 y se configura la replicación de la tabla t1.
vm1$> ./symadmin -e corp-000 --node=001 sync-triggers vm1$> ./symadmin send-schema -e corp-000 --node=001 t1
Beneficios de SymmetricDS
Fácil instalación y configuración, que incluye un conjunto de archivos listos para usar con parámetros para crear un circuito con tres o dos nodos.
Bases de datos multiplataforma e independencia de plataforma, incluidos servidores, portátiles y dispositivos móviles.
Replicar cualquier base de datos a cualquier otra base de datos localmente, en una WAN o en la nube.
La capacidad de trabajar de manera óptima con un par de bases de datos o varios miles para una fácil replicación.
Versión de pago con interfaz gráfica y excelente soporte.
Desventajas de SymmetricDS
Es necesario determinar manualmente las reglas y la dirección de replicación a través de las instrucciones SQL en la línea de comando para cargar tablas de directorio, lo cual es inconveniente.
La configuración de muchas tablas para la replicación puede ser tediosa si no utiliza scripts para crear sentencias SQL que definan las reglas y la dirección de la replicación.
Se ingresa demasiada información en los registros, y a veces necesita limpiar el archivo de registro para que no ocupe demasiado espacio.
Resumen de SymmetricDS
SymmetricDS le permite configurar la replicación bidireccional entre dos, tres o incluso varios miles de nodos para replicar y sincronizar archivos. Esta es una herramienta única que realiza de forma independiente muchas tareas, por ejemplo, recuperación automática de datos después de un largo tiempo de inactividad en un nodo, intercambio seguro y eficiente de datos entre nodos a través de HTTPS, gestión automática de conflictos basada en un conjunto de reglas, etc. SymmetricDS se replica entre cualquier base de datos, por lo tanto, se puede usar para una variedad de escenarios, incluida la migración, actualización, distribución, filtrado y conversión de datos en todas las plataformas.
La muestra se basa en la Guía oficial de inicio rápido de SymmetricDS. La guía del usuario detalla varios conceptos relacionados con la configuración de la replicación usando SymmetricDS.