Бекап баз из кластера 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, то только со слейва.
|