En primer lugar, ¿por qué ninguno de ustedes responde la pregunta de este tipo? A veces tenemos que hacer esto debido a restricciones de seguridad/cumplimiento/sistemas heredados.
Hay algunas opciones que escribiré aquí con pseudocódigo. No estoy seguro de cuán en tiempo real es su base de datos, por lo que esto no funcionará en todos los casos.
Requisitos
Para que esto funcione, las bases de datos deberán estar en la misma instancia del servidor. De lo contrario, deberá configurar un motor de almacenamiento federado para acceder a los datos remotos. Como dijo otra persona, la replicación de MySQL aún podría ser útil al menos para llevar los datos al mismo servidor, lo que hace que la sincronización sea más rápida sin la necesidad de configurar el almacenamiento federado. Referencia:https://dev.mysql.com/doc/refman/5.7/en/federated-storage-engine.html
Tiempo de sincronización
MySQL le permitirá crear eventos en un horario específico para realizar su trabajo (suponiendo que no tenga ninguna herramienta externa de programación de trabajos).
Con suerte, tiene una fecha de modificación de algún tipo, puede consultar una vez al día o intervalos más cortos en todos los campos donde modified_at>=FECHA_SUB(AHORA( ),INTERVALO ? HORA)
Si puede agregar una columna, puede crear una llamada synced_at que sería un poco más resistente a las diferencias de reloj del servidor. Entonces simplemente puede consultar dónde synced_at ES NULO o synced_at <=modified_at
MySQL admite activadores ANTES y DESPUÉS de INSERTAR / ACTUALIZAR / ELIMINAR, etc. Puede usarlos para activar su lógica. Tenga en cuenta que recibirá una pequeña penalización de rendimiento por cada transacción y esto puede abrumar fácilmente a los servidores de producción muy activos.
Realmente no hay una gran diferencia entre ANTES y DESPUÉS, excepto que si usa los disparadores de estilo ANTES, puede lanzar un sqlstate para evitar la inserción en la tabla de origen si es importante que ambas tablas estén altamente sincronizadas.
Lógica de sincronización
Esto es pseudocódigo pero...
# new and updated records
INSERT ... ON DUPLICATE KEY UPDATE ...
SELECT FROM source_table
JOIN target_table.id
WHERE target_table.id IS NULL or modified_at > DATE_SUB(NOW(), INTERVAL ..)
# deleted records
Igual que arriba, solo que está manipulando un registro a la vez y está reflejando la declaración de activación. Por ejemplo:un INSERT TRIGGER en la tabla de origen solo debe consultar INSERT en la tabla de destino.
Simple pero no recomendado para nada más que tal vez una base de datos de informes. Suelte toda la tabla y reconstruya a partir de los otros registros.
