Zero downtime migracja bazy danych

Zakładajac ze np migrujemy z MYSQL do nierelacyjnej i systemu nie mozemy zatrzymac, ciagle dochodza nowe dane, stare sa zmieniane. Jak obsłużyc taka migracje?

Zakladajac, ze zaczynamy kopiowac dane ze starej do nowej bazy oraz jednoczesnie operacje modyfikacji propagujemy na nowa baze, mozemy miec sytuacje, w ktorej w nowej bazie jeszcze tych danych nie ma co moze prowadzic do problemow.

Do glowy przychodzi mi np wrzucanie wszystkich zmian na np topic i pozniej cos ala event bus zczytywanie tego do target DB, ale nie wiem czy ma sens.

Jak to sie robi porządnie ?

Jednorazowo, czy w trybie ciągłym?

@Marcin.Miga: Jednorazowo

@filemonczyk: O jakiej branży mowa? Podtrzymywanie życia czy każda sekunda to strata gigantycznej $$$? Czy teraz system pracuje w 99,9999%?
W telco, bankach są przewidziane przerwy serwisowe. zero-down time to raczej droga opcja, ale wykonalna. Trzeba zbudować parę klocków i je zintegrować.

Co jest taką encją podstawową w tym systemie migrowanym? Klient? Coś innego?

@yarel: może jakaś firma produkcyjna, a system o którym mowa nadzoruje pracę linii montażowej? Scenariuszy jest wiele.

To jest teoretyczne pytanie :D , serio. Chcemy uniknac przerwy w funkcjonowaniu apki , ale jakies rozwazania z prerwa tez sa ok , chociaz tutaj chyba wszystko staje sie proste. Chodzi mi ogolnie czy jakies podejscie z kolejka i logiem zmian jest dobre czy to kompletna glupota itp.

Ogólnie jeśli jest możliwość, to najlepszą opcją jest chwilowa przerwa techniczna. Pewnie da się to obejść, ale taka migracja na żywo jest 100x bardziej skomplikowana i masz o wiele więcej możliwości popełnienia błędu. A co gorsza - możesz wszystkich problemów nie wyłapać od razu, ale zemści się to za jakiś czas, kiedy już odkręcenie tego będzie mega problematyczne i prawdopodobnie będzie się wiązać ze znacznie dłuższą przerwą.

Jak jednorazowo, to snapshot i backup.