 Бекап баз из кластера GALERA, Поделитесь опытом..,  flintus9, 14-Окт-21, 10:29 [смотреть все]Исходя из документации (https://galeracluster.com/library/training/tutorials/galera-...), в которой описаны четыре возможных варианта, а именно:
- физический бекап 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
|
- Бекап баз из кластера GALERA, Поделитесь опытом.., Anto Nimno, 12:54 , 19-Окт-21 (1)
На вид выглядит как: отделить процессы сетапа кластера, сетапа доступов и т.п. от процесса дампа баз. Для бекапа баз по одному процессу на базу. При восстановлении уметь отдельно создать площадку с Галерой под базы и отдельно уметь раскатать базы. Уметь это отдельными, не связанными действиями. Базы бекапить или поштучно своими скриптами, с обработками ошибок и т.д. или поискать готовое решение. Поставить на мониторинг процесс возникновения новых бекапов (добиться работоспособности процесса). Стараться не привязываться к особенностям Галеры, не добавлять зависимостей.Когда нужно задним числом посмотреть в базы, то удобно иметь возможность раскатки базы в стороне, просто возможность анализа простыми средствами. Поэтому rsync выглядит очень неудобно. Не подлезть посмотреть в бэкап, без манипуляций с специально настроенными нодами и "раскатки" обратно. Возникает возможная привязка к сетапу OS ноды, вместо сетапа просто только MSQL базы. Поэтому ценна возможность получить каждый дамп отдельно независимым tar.gz или подобное. Может не прав. Возникло подозрение о желании решения, но не обрабатывать ошибки. Чтобы решение не могло закончится с ошибкой. Ошибки нужно обрабатывать. Нужно иметь работоспособный процесс на этот случай (в т.ч. отработка оповещений из мониторинга). Всегда. > скрипт как-то не корректно завершался, вероятно не возвращая чего-то Замены слов "как-то" и "чего-то" содержат в себе ответ или вопрос о причинах. Причины могут быть в выбранной комбинации действий, что относится к обработке ошибок или выбору другой комбинации у себя. А могут быть в особенностях Марии и Галеры.
- Бекап баз из кластера GALERA, Поделитесь опытом.., flintus9, 16:29 , 19-Окт-21 (2)
> Может не прав. Возникло подозрение о желании решения, но не обрабатывать ошибки.
> Чтобы решение не могло закончится с ошибкой. Ошибки нужно обрабатывать. Нужно
> иметь работоспособный процесс на этот случай (в т.ч. отработка оповещений из
> мониторинга). Всегда.
>> скрипт как-то не корректно завершался, вероятно не возвращая чего-то
> Замены слов "как-то" и "чего-то" содержат в себе ответ или вопрос о
> причинах. Причины могут быть в выбранной комбинации действий, что относится к
> обработке ошибок или выбору другой комбинации у себя. А могут быть
> в особенностях Марии и Галеры.Желание - чем проще тем надежнее, физически не возможно бекапить базы с галеры не вводя одну из нод в рассинхронизацию, или вообще не выкидывая её из кластера на время. Так гласит их документация. Опытным путем в этом убедился. Не корректное окончание работы скрипта взятого с их сайта, выложенного для примера как пользоваться бекапом через арбитратор.
Т.е. там заведомо полурабочий вариант выложен, вероятно иначе как бы codership не начем зарабатывать =) С остальным согласен, мониторить каждый чих.. Видимо с коллективным опытом использования галеры туго. Или все кто что-то делал, сильно берегут это know-how, печалька.
- Бекап баз из кластера GALERA, Поделитесь опытом.., XXXX, 00:37 , 20-Окт-21 (3)
mydumper: https://github.com/maxbube/mydumper/releases
myloader для восстановления (сам почитаешь)mydumper -h $SQL_HOST -P $SQL_PORT -u $SQL_USER -p $SQL_PASS --regex '^(?!(mysql\.[^u].*|sys\.|sys-schema.*\.|PERCONA_SCHEMA\.))' \
--outputdir=$CUR_BACKUP_PATH \
--compress \
--threads=$(($(grep -Ec "processor" /proc/cpuinfo)+2)) \
--compress-protocol \
--triggers \
--events \
--routines \
--less-locking \
--trx-consistency-only \
--rows=500000 \
--build-empty-files \
--logfile $CUR_BACKUP_PATH/mydumper.log \
--verbose 3 >[оверквотинг удален]
> пришлось пристрелить..
> Четвертый вариант - проходили, со слейвом можно делать что угодно, но запись
> в бин лог не добавляет стремительности всему кластеру, ну и отдельная
> радость от восстановления реплики в случае чего, то еще удовольствие.
> Собственно может кто поделится опытом, как решает схожую задачу, или может урл
> какой почитать укажет, хотя гугл мне пока никак с этим не
> помог. Может кто пробовал реализовать wsrep_sst_backup_mariabackup, или еще какой вариант?
> Помогите люди добрые..
> P.S. SST и IST работают как часы, mariabackup'ом.
> P.P.S. Использую MariaDB 10.4 + galera4
- Бекап баз из кластера GALERA, Поделитесь опытом.., Аноним, 16:32 , 20-Окт-21 (5)
Если хотите PITR, то только со слейва.
|
Версия для распечатки
