Всем привет. Меня очень интересует вопрос, сколько весят и как быстро делает свои бэкапы гугл во время очередного апдейта сервиса(ов)? Ведь у них downtime'a вообще практически наверное нет при обновлениях. Даже если у них делается снэпшот базы, накатываются на нее всякие инсерты/апдейты/тригерры, то судя по всему, это занимает довольно длительное время и если будет какой-то фейл и нужно сделать откат, то все данные после снэпшота считаются потерянными, что недопустимо для гугла. Может у них там работают какие-то маги и чародеи?=)
Хотелось бы тоже так делать, но что-то не могу додумать как сделать.
Были еще мысли вот таким образом делать:
master(m1)<->master(m2)->slave(s2)->slave(s3)
m1 - используем как резерв основной m2. В s2 накатываем все изменения для обновления и вешаем нужные триггеры на обновление новых полей, если вдруг изменится наша структура базы. s3 - резервная копия s2, которая потом промоутится и чистится от всякого мусора(лишних полей, типов и т.п., если изменилась структура бд) и используется как основная база при обновлении. Но тут все равно стоит вопрос, что теряются данные из-за лага записи в слейвы и асинхронности записи + появляются 4 лишние базы.
Уже всю голову сломал, мучаясь с этим вопросом, может кто дать совет на свежую голову, чтобы было всё без потерь данных и с минимальным downtime'ом?=)
P.S. кажись придумал выход. Нужно делать блокировку таблицы на запись в бд и на бэке/фронте продумать решение, которые бы не давала пользователю делать действия на запись/обновление чего-угодно, до того момента, пока все слейвы не догонят мастера и не будет завершен промоут слейва и переключение на него, в качестве основной базы. Но это так себе решение. При большой базе и достаточно большом количестве записей в секунду, неизвестно, сколько времени будут слейвы догонять мастера...
Простой
Средний
Средний
