Jag är inte en MySQL-person, så det här kommer från vänster fält.
Men jag tror att loggfilerna kan vara svaret.
Tack och lov behöver du egentligen bara veta två saker från loggen.
Du behöver posten/raden, och du behöver operationen.
I de flesta DB:er, och jag antar MySQL, finns det en implicit kolumn på varje rad, som en rowid eller recordid, eller vad som helst. Det är det interna radnumret som används av databasen. Detta är din "fria" primärnyckel.
Därefter behöver du operationen. Särskilt om det är en infogning, uppdatering eller radering på raden.
Du konsoliderar all denna information i tidsordning och går sedan igenom den.
För varje infogning/uppdatering väljer du raden från din ursprungliga DB, och infogar/uppdaterar den raden i din destinations-DB. Om det är en radering tar du bort raden.
Du bryr dig inte om fältvärden, de är bara inte viktiga. Gör hela raden.
Du ska förhoppningsvis inte behöva "tolka" binära loggfiler, MySQL måste redan ha rutiner för att göra det, du behöver bara hitta och ta reda på hur du använder dem (det kan till och med finnas något praktiskt "dumplogg"-verktyg du kan använda ).
Detta låter dig hålla systemet ganska enkelt, och det bör bara bero på din faktiska aktivitet under dagen, snarare än den totala DB-storleken. Slutligen kan du senare optimera den genom att göra den "smartare". Till exempel kanske de infogar en rad, uppdaterar den och raderar den. Du skulle veta att du bara kan ignorera den raden helt i din repris.
Uppenbarligen kräver detta lite mysig kunskap för att faktiskt läsa loggfilerna, men resten borde vara okomplicerat. Jag skulle vilja tro att loggfilerna också är tidsstämplade, så att du kan veta att arbeta på rader "från och med idag", eller vilket datumintervall du vill.