Em primeiro lugar, por que nenhum de vocês responde à pergunta desse cara? Às vezes temos que fazer isso devido a restrições de segurança/conformidade/sistemas legados.
Existem algumas opções que escreverei aqui com pseudocódigo. Não tenho certeza de como seu banco de dados é em tempo real, então isso não funcionará em todos os casos.
Requisitos
Para que isso funcione, os bancos de dados terão que estar na mesma instância do servidor. Caso contrário, você precisará configurar um mecanismo de armazenamento federado para acessar os dados remotos. Como outra pessoa afirmou, a replicação do MySQL ainda pode ser útil para, pelo menos, levar os dados para o mesmo servidor, tornando a sincronização mais rápida sem a necessidade de configurar o armazenamento federado. Referência:https://dev.mysql.com/doc/refman/5.7/en/federated-storage-engine.html
Tempo de sincronização
O MySQL permitirá que você crie eventos em um agendamento específico para realizar seu trabalho (assumindo que você não tenha nenhuma ferramenta externa de agendamento de trabalho).
Espero que você tenha algum tipo de data modificada, você pode consultar uma vez por dia ou intervalos mais curtos em todos os campos onde
modified_at>=DATE_SUB(AGORA( ),INTERVALO ? HORA) Se você puder adicionar uma coluna, poderá criar uma chamada
synced_at que seria um pouco mais resistente às diferenças de clock do servidor. Então você pode simplesmente consultar onde synced_at É NULL ou synced_at <=modified_at MySQL suporta gatilhos BEFORE e AFTER de INSERT / UPDATE / DELETE etc... você pode usá-los para acionar sua lógica. Lembre-se de que você sofrerá uma pequena penalidade de desempenho para cada transação e isso pode sobrecarregar facilmente os servidores de produção muito ativos.
Realmente não há uma grande diferença entre BEFORE e AFTER, exceto que, se você usar os gatilhos de estilo BEFORE, poderá lançar um sqlstate para impedir a inserção na tabela de origem se for importante que ambas as tabelas sejam altamente sincronizadas.
Lógica de sincronização
Isso é pseudo-código, mas...
# 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
O mesmo que acima só que você está apenas manipulando um registro de cada vez e está espelhando a instrução do gatilho. Por exemplo:um INSERT TRIGGER na tabela de origem deve apenas consultar o INSERT na tabela de destino.
Simples, mas não recomendado para nada além de talvez um banco de dados de relatórios. Elimine a tabela inteira e reconstrua-a a partir dos outros registros.
