The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



"Бекап баз из кластера GALERA, Поделитесь опытом.."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Открытые системы на сервере (Резервное копирование / Другая система)
Изначальное сообщение [ Отслеживать ]

"Бекап баз из кластера GALERA, Поделитесь опытом.."  +/
Сообщение от flintus9 (ok), 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

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Бекап баз из кластера GALERA, Поделитесь опытом.."  +/
Сообщение от Anto Nimno (?), 19-Окт-21, 12:54 
На вид выглядит как: отделить процессы сетапа кластера, сетапа доступов и т.п. от процесса дампа баз. Для бекапа баз по одному процессу на базу. При восстановлении уметь отдельно создать площадку с Галерой под базы и отдельно уметь раскатать базы. Уметь это отдельными, не связанными действиями. Базы бекапить или поштучно своими скриптами, с обработками ошибок и т.д. или поискать готовое решение. Поставить на мониторинг процесс возникновения новых бекапов (добиться работоспособности процесса). Стараться не привязываться к особенностям Галеры, не добавлять зависимостей.

Когда нужно задним числом посмотреть в базы, то удобно иметь возможность раскатки базы в стороне, просто возможность анализа простыми средствами. Поэтому rsync выглядит очень неудобно. Не подлезть посмотреть в бэкап, без манипуляций с специально настроенными нодами и "раскатки" обратно. Возникает возможная привязка к сетапу OS ноды, вместо сетапа просто только MSQL базы. Поэтому ценна возможность получить каждый дамп отдельно независимым tar.gz или подобное.

Может не прав. Возникло подозрение о желании решения, но не обрабатывать ошибки. Чтобы решение не могло закончится с ошибкой. Ошибки нужно обрабатывать. Нужно иметь работоспособный процесс на этот случай (в т.ч. отработка оповещений из мониторинга). Всегда.

> скрипт как-то не корректно завершался, вероятно не возвращая чего-то

Замены слов "как-то" и "чего-то" содержат в себе ответ или вопрос о причинах. Причины могут быть в выбранной комбинации действий, что относится к обработке ошибок или выбору другой комбинации у себя. А могут быть в особенностях Марии и Галеры.

Ответить | Правка | Наверх | Cообщить модератору

2. "Бекап баз из кластера GALERA, Поделитесь опытом.."  +/
Сообщение от flintus9 (ok), 19-Окт-21, 16:29 
> Может не прав. Возникло подозрение о желании решения, но не обрабатывать ошибки.
> Чтобы решение не могло закончится с ошибкой. Ошибки нужно обрабатывать. Нужно
> иметь работоспособный процесс на этот случай (в т.ч. отработка оповещений из
> мониторинга). Всегда.
>> скрипт как-то не корректно завершался, вероятно не возвращая чего-то
> Замены слов "как-то" и "чего-то" содержат в себе ответ или вопрос о
> причинах. Причины могут быть в выбранной комбинации действий, что относится к
> обработке ошибок или выбору другой комбинации у себя. А могут быть
> в особенностях Марии и Галеры.

Желание - чем проще тем надежнее, физически не возможно бекапить базы с галеры не вводя одну из нод в рассинхронизацию, или вообще не выкидывая её из кластера на время. Так гласит их документация. Опытным путем в этом убедился.

Не корректное окончание работы скрипта взятого с их сайта, выложенного для примера как пользоваться бекапом через арбитратор.
Т.е. там заведомо полурабочий вариант выложен, вероятно иначе как бы codership не начем зарабатывать =)

С остальным согласен, мониторить каждый чих.. Видимо с коллективным опытом использования галеры туго. Или все кто что-то делал, сильно берегут это know-how, печалька.

Ответить | Правка | Наверх | Cообщить модератору

3. "Бекап баз из кластера GALERA, Поделитесь опытом.."  +/
Сообщение от XXXX (?), 20-Окт-21, 00:37 
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

Ответить | Правка | Наверх | Cообщить модератору

4. "Бекап баз из кластера GALERA, Поделитесь опытом.."  +/
Сообщение от flintus9 (ok), 20-Окт-21, 14:13 
>  mydumper: https://github.com/maxbube/mydumper/releases
> myloader  для восстановления (сам почитаешь)

Видимо это как раз то что я искал, рассинхра происходит на очень короткий момент, сам процесс проходит гораздо быстрее т.к. в несколько потоков. Спасибо за подсказку, она прям в тему оказалась.


Ответить | Правка | Наверх | Cообщить модератору

5. "Бекап баз из кластера GALERA, Поделитесь опытом.."  +/
Сообщение от Аноним (5), 20-Окт-21, 16:32 
Если хотите PITR, то только со слейва.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру