Comments 5
У вариантов `like a rock-star` и binlog-server есть еще одно важное преимущество - они нормально работаю с огромными транзакциями (когда бинлог на 15G).
Связка `mysqlbinlog | mysql` к сожалению просто не способна прочитать большие транзакции из бинлога.
Да, ты прав. Пару раз видел как mysqlbinlog зависает на больших бинлогах. Но при подготовке статьи мне больше интересовала скорость наката бинлогов.
На самом деле это интересный вопрос, как MySQL работает с большими бинлогами, т.к. когда в самом бинлоге event_size и next event position это int32. Но в самом MySQL position уже int64, а с недавних пор (8.0.33) и mysqlbinlog умеет int64 position. В общем, надо будет посмотреть как они запихивают int64 в int32 =)
Спасибо за статью! Я правильно понял, что с помощью `wal-g binlog-server` можно так же получить реплику БД с "отставанием" данных, например, на сутки?
Концептуально, delayed replication это фича MySQL[1], и если ее настроить - должно работать без участия wal-g. Могу предположить единственную пользу которую может принести wal-g - не хранить бинлоги за сутки на реплике... но текущая версия wal-g так не умеет - она отдает бинлоги как можно быстрее, и только в самом конце ждет когда все транзакции применятся.
[1] https://dev.mysql.com/doc/refman/5.7/en/replication-delayed.html
Назад в прошлое: как быстро восстановить MySQL на точку во времени