flintus
Junior Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Исходя из документации, в которой описаны четыре возможных варианта, а именно:
- физический бекап rsync'ом, c остановкой ноды на время бекапа;
- логический бекап при помощи mysqldump с отключением синхронизации ноды перед бекапом и включением после;
- логический бекап при помощи арбитратора;
- какой угодно бекап только лить будем со слейва;
Первый вариант мне не нравится тем что автоматизировать это конечно можно, но как показала практика, случаются варианты когда потушить потушили, а обратно без живого человека не запустить.
Так же не очень удобен физический бекап, особенно когда надо вытащить пару строк, а баз несколько и они не самые маленькие, (по несколько гигов).
Второй вариант тоже так себе, был на моей практике случай, десинкнули ноду, сделали бекап, а синкнуть обратно бездушному автомату не получилось, и несмотря на настроенные нотифаи, это прошляпили, сутки оно жило своей жизью. Хотя кластер отдавал честно что кол-во нод в кластере правильное, что по сути является истиной.
Третий вариант по сути это извращение на тему второго варианта, только бекап мы льем локально на ноду донор, и ровно точно так же нода десинкается. И если посмотреть в рабочий пример то льем все базы в один дамп, хотя я делал вариации на тему лить по базам, но в любом случае скрипт как-то не корректно завершался, вероятно не возвращая чего-то что ожидает сам кластер, пример:
Код:
[ERROR] WSREP: Failed to read from: wsrep_sst_backup_mysqldump
[ERROR] WSREP: Command did not run: wsrep_sst_backup_mysqldump
|
хотя бекап отработал, все сдампил и упаковал. Вероятно эти ошибки появляются в следствии того что garb запускается из командной строки, отправляет на донора команду и отваливает, не ожидая окончания процесса и какого-то результата. Это вариант не очень нравится тем что льем бекап локально. Ну и непонятки с этими ошибками не добавляют радости. Ну и отдельно у меня был вариант когда подвис сам процесс wsrep_sst_backup_mysqldump и нода зависла в десинке ожидая когда процесс завершится, а он и не думал, пришлось пристрелить..
Четвертый вариант - проходили, со слейвом можно делать что угодно, но запись в бин лог не добавляет стремительности всему кластеру, ну и отдельная радость от восстановления реплики в случае чего, то еще удовольствие.
Собственно может кто поделится опытом, как решает схожую задачу, или может урл какой почитать укажет, хотя гугл мне пока никак с этим не помог. Может кто пробовал реализовать wsrep_sst_backup_mariabackup, или еще какой вариант? Помогите люди добрые..
P.S. SST и IST работают как часы, mariabackup'ом.
P.P.S. Использую MariaDB 10.4 + galera4 |
