Comments 10
Сейчас в mysql появилась групповая репликация. Благодаря Вашей статье просмотрел материал по ней. Говоря о репликации и базе данных больше всего интересует два момента: производительность и разрешение конфликты. В конце концов сейчас появились новые кластерные базы совместимые по протоколу с mysql и postgresql. И даже не одна. Проблема только что кластер из 10 таких совместимых баз работает по производительности как одна база mysql.
Хорошо бы еще добавить в статью про использование GTID при репликации — довольно давно появилось уже, и реально полезно и удобно в большинстве случаев.
И это всё отлично автоматизируется: https://github.com/ip1981/nixsap/blob/master/modules/apps/mariadb/replicate.nix
И все это льется в один поток. Если у вас большой трафик на запись (например, собираете телеметрию), то возможна ситуация, когда мастер справляется, а слейвы отстают безнадежно и вылечить это конфигурируя репликацию невозможно. Для понимания границ применимости.
Но в целом согласен, что в случае, если используемая производительность на мастере выше, чем максимальная производительность слейва, он будет отставать, и никакой параллелизм не спасет.
Slave_IO_State — собственно, состояние репликации.
Нет, не верно написано. Это состояние IO потока, отвечающего за прием бинарного лога с мастера.
Есть еще Slave_SQL_State — это состояние потока применяющего релей лог.
Только наличие обоих работающих потоков говорит нам, что репликация работает.
Репликация баз данных MySQL. Введение