Först och främst, varför svarar ingen av er på den här mannens fråga? Ibland måste vi göra detta på grund av säkerhetsrestriktioner / efterlevnad / äldre system.
Det finns några alternativ jag kommer att skriva här med pseudokod. Osäker på hur realtid din databas är så detta fungerar inte i alla fall.
Krav
För att detta ska fungera måste databaserna vara i samma serverinstans. Om inte måste du konfigurera en federerad lagringsmotor för att komma åt fjärrdata. Som en annan person sa, kan MySQL-replikering fortfarande vara användbar för att åtminstone få data till samma server, vilket gör synkroniseringen snabbare utan att behöva konfigurera federerad lagring.Referens:https://dev.mysql.com/doc/refman/5.7/en/federated-storage-engine.html
Synkroniseringstid
MySQL låter dig skapa händelser enligt ett specifikt schema för att utföra ditt arbete (förutsatt att du inte har några externa verktyg för jobbschemaläggning).
Förhoppningsvis har du ett modifierat datum av något slag, du kan fråga en gång om dagen eller snävare intervall på alla fält där modified_at
>=DATE_SUB(NU( ),INTERVALL ? TIMME)
Om du kan lägga till en kolumn kan du skapa en som heter synced_at
vilket skulle vara lite mer motståndskraftigt mot skillnader i serverklockan. Sedan kan du helt enkelt fråga var synced_at
ÄR NULL eller synced_at
<=modified_at
MySQL stöder FÖRE och EFTER triggers av INFOGA / UPPDATERA / DELETE etc... du kan använda dessa för att trigga din logik. Tänk på att du kommer att ta en liten prestationsstraff för varje transaktion och detta kan lätt överväldiga mycket aktiva produktionsservrar.
Det är verkligen ingen stor skillnad mellan BEFORE och EFTER förutom att om du använder BEFORE-stiltriggarna kan du kasta en sqlstate för att förhindra infogning i källtabellen om det är viktigt att båda tabellerna är mycket synkroniserade.
Synkroniseringslogik
Detta är pseudokod 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
Samma som ovan, bara du manipulerar bara en post i taget och du speglar trigger-satsen. Till exempel:en INSERT TRIGGER på källtabellen ska bara fråga INSERT på måltabellen.
Enkelt men rekommenderas inte för något annat än kanske en rapportdatabas. Släpp hela tabellen och bygg om den från de andra posterna.