Først og fremmest, hvorfor svarer ingen af jer på denne fyrs spørgsmål? Nogle gange er vi nødt til at gøre dette på grund af sikkerhedsrestriktioner / compliance / ældre systemer.
Der er nogle muligheder, jeg vil skrive her med pseudokode. Ikke sikker på, hvor realtid din database er, så dette vil ikke fungere i alle tilfælde.
Krav
For at dette skal virke, skal databaserne være i samme serverinstans. Hvis ikke, skal du konfigurere en forbundslagringsmotor for at få adgang til fjerndataene. Som en anden person sagde, kan MySQL-replikering stadig være nyttig til i det mindste at få dataene til den samme server, hvilket gør synkroniseringen hurtigere uden at skulle konfigurere fødereret lagring. Reference:https://dev.mysql.com/doc/refman/5.7/en/federated-storage-engine.html
Synkroniser timing
MySQL giver dig mulighed for at oprette begivenheder efter en bestemt tidsplan for at udføre dit arbejde (forudsat at du ikke har nogen eksterne jobplanlægningsværktøjer).
Forhåbentlig har du en ændret dato af en slags, du kan forespørge en gang om dagen eller strammere intervaller på alle felter, hvor modified_at>=DATE_SUB(NU( ),INTERVAL ? TIME)
Hvis du er i stand til at tilføje en kolonne, kan du oprette en kaldet synced_at hvilket ville være lidt mere modstandsdygtigt over for forskelle på serverens ur. Så kan du blot spørge, hvor synced_at ER NULL eller synced_at <=modified_at
MySQL understøtter FØR og EFTER triggere af INSERT / UPDATE / DELETE osv... du kan bruge disse til at udløse din logik. Husk, at du vil tage en lille ydeevnestraf for hver transaktion, og dette kan nemt overvælde meget aktive produktionsservere.
Der er virkelig ikke den store forskel mellem FØR og EFTER, bortset fra at hvis du bruger BEFORE-stil-triggerne, kan du smide en sqlstate for at forhindre indsættelse i kildetabellen, hvis det er vigtigt for begge tabeller at være meget synkroniserede.
Synkroniseringslogik
Dette er pseudokode, men...
# 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
Samme som ovenfor, kun du manipulerer én post ad gangen, og du spejler trigger-sætningen. For eksempel:en INSERT TRIGGER på kildetabellen skal bare forespørge INSERT på måltabellen.
Enkel, men anbefales ikke til andet end måske en rapporteringsdatabase. Slip hele tabellen og genopbyg den fra de andre poster.