Jeg er ikke en MySQL-person, så dette kommer ud af venstre felt.
Men jeg tror, logfilerne kan være svaret.
Heldigvis behøver du kun at vide 2 ting fra loggen.
Du skal bruge posten/rækken, og du har brug for operationen.
I de fleste DB'er, og jeg antager MySQL, er der en implicit kolonne på hver række, som en rowid eller recordid eller hvad som helst. Det er det interne rækkenummer, der bruges af databasen. Dette er din "gratis" primære nøgle.
Dernæst skal du have operationen. Især om det er en indsættelses-, opdaterings- eller sletningshandling på rækken.
Du konsoliderer alle disse oplysninger i tidsmæssig rækkefølge og gennemgår dem derefter.
For hver indsættelse/opdatering vælger du rækken fra din oprindelige DB og indsætter/opdaterer den række i din destinations-DB. Hvis det er en sletning, så sletter du rækken.
Du er ligeglad med feltværdier, de er bare ikke vigtige. Gør hele rækken.
Du skulle forhåbentlig ikke skulle "parse" binære logfiler, MySQL skal allerede have rutiner for at gøre det, du skal bare finde og finde ud af, hvordan du bruger dem (der kan endda være noget praktisk "dump log"-værktøj, du kan bruge ).
Dette lader dig holde systemet ret simpelt, og det bør kun afhænge af din faktiske aktivitet i løbet af dagen, snarere end den samlede DB-størrelse. Endelig kunne du senere optimere den ved at gøre den "smartere". For eksempel kan de måske indsætte en række, derefter opdatere den og derefter slette den. Du ville vide, at du bare kan ignorere den række fuldstændigt i din replay.
Det kræver naturligvis lidt mystisk viden for rent faktisk at læse logfilerne, men resten burde være ligetil. Jeg vil gerne tro, at logfilerne også er tidsstemplede, så du kan vide, om du skal arbejde på rækker "fra i dag", eller hvilket datointerval du ønsker.