Ну ос тут точно не причём, да и субд тоже. Субд -форк mysql когда-то, отзываются хорошо, так что тут я виноват, а не кто-то.

Самая большая БД из набора - скуль. Где-то 100+ Гигов ну и старый дедофорум + новый. Не помню сколько может под 25 гигов все вместе.

Я выделил диски по 500 гигов для БД.

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

В качестве третего для galera arbitrator используют, как я почитал, кто не может 3 сделать.

По поводу виртуального ip haproxy + keepalive ( деда дал )

Есть ещё популярное proxysql.

Но! Это все гладко на бумаге и в инструкции, надо иметь опыт. А краш тест показал, что galera кластер я восстановить не смог. А это никуда не годится. Это длительный простой.

Вообще, это же не совсем репликация то.

В конечном итоге 100+ гигов.

Но это из текстового дампа долго восстанавливать. Так-то можно другими методами пойти на новом хостинге.

Да. На текущем хостинге, на этом. А он, сравнительно быстрый. Может пров что-то подрезает. Поглядим на новом с физическими серверами. Так-то обхем маленький, но не для стандартного хостинга.

Давно уже я делал через снэпшоты LVM. Механизм в слайдах Оракла нашёл
Суть:
- flush tables with read lock; create snapshot; exit. Не обращайте внимание на блокировку, снэпшот создаётся быстрее, чем что-то успевает записаться, при выходе тут же снимается.
- архивируем директорию с данными, изменения пишутся в снэпшот.
- удаляем снэпшот, изменения сбрасываются в данные

Но так я делал с заббиксом, там терабайт с чем-то был, обычный дамп - очень долго. Всё корректно восстанавливалось + я переносил такой архив на слейв, чтобы репликацию настроить.

Но критиковали этот способ многие.

Я тут ещё вычитал про mariabackup. Это не аналог xtrabckup?

Тут 99% я плохо доку изучил ))

Вчера потыкался, выключал, включал, удавалось провести процедуру восстановления по доке. Пробовал разные варианты. Ладно, потыкаем ещё.

Сейчас, наверное, нет. На этом хостинге. Для этого нет ресурсов, вернее они стоят денег.. Даже ALTER TABLE таблицы с постами потребует в 2 раза больше места, места сейчас мало.

На физических серверах будет всё получше, там места ощутимо больше.

Блять, один Деда помнит, как я ебался с восстановлением на ноутбуке, на котором ещё меньше места )))

Касательно бэкапов самой БД мне знаком вышеозвученный способ с LVM снэпшотами. Он быстрый. Не знаю, насколько он будет корректен по отношению к форумной БД и тем более в кластере. Надо проверять.

Просто Трёп [игнорируется] 

ещё выше мегабайт озвучил xtrabackup. Слышал, но никогда не делал.

Ну вот тут подробно описано про озвученный мной метод, я про него читал ещё в слайдах оракла, поэтому решил довериться. Я бэкапил сравнительно большую БД заббикс, там терабайт примерно, которую в те времена дампить и сосать - это анрил полный. Да и бредово.

https://www.percona.com/blog/using-lvm-for-mysql-backup-and-replication-setup/

Если эта схема продемонстрирует себя приемлимо, то можно забить на этот кластер, настроить master-slave репликацию и бэкапить со слейва.

Правда тут есть некий нюанс, дамп - текстовый файл, бзип, например, его сжимает в больше чем 10 раз. А тут будут бинарные файлы и большой архив, который надо выгружать и хранить

Нашёл скрипт бэкапа, древнющийСмысл вше озвучен
- логинится в БД
- делает блокировку (блокировка не снимается до выхода)
- тут же создаёт снэпшот, прямо из mysql
- вылогинивается (блокировка тут же снимается)
- данные пишутся в снэпшот, пока делается бэкап, тупо архивируется директория
- после окончания снэпшот удаляется, данные сбрасываются в нормальный путь средствами LVM

Но наверное, будет правильнее воспользоваться, как мегабайт советовал

https://habr.com/ru/articles/520458/

в марии это уже своя программа, аналогичная

https://mariadb.com/kb/en/percona-xtrabackup-overview/

InnoDB.

Ещё моменты:
- вся конструкция стартует примерно минут 30 до возможности предоставления сервиса
- при старте требуется вмешательство администратора, то есть, порядок запуска

Что-то можно автоматизировать, но в некоторых случаях вмешательство всё-таки может потребоваться. Так вот, для галеры, как известно нужно три узла для нормального состояния работы и два узла чтобы СУБД обрабатывала запросы, ну то есть это аварийное состояние, практически, пока не войдёт в работы третий узел. Да, можно решить проблему арбитром, как я выше писал, то есть фейковая нода только для оркестрации. Решение применяется, популярно, в доке описано. Всё бы хорошо, но у нас физически два узла, то есть, арбитр и одну ноду субд нужно разместить на одном физическом узле. Если узел перезагрузиться и останется одна рабочая нода - кластер развалится и самостоятельно не соберётся. он вообще развливается если всё выключить, надо заново инициализировать.

Но и в том случае, если просто одна нода субд или репликация мастер-слэйв и епнется нода с мастером, тоже ни куя работать не будет.

Что всё это значит.

При нештатной перезагрузке хотя бы одного физического узла кластера - неработоспособность форумов. 50 на 50. А с учётом того, что я могу сидеть на объекте за периметром, без интернета вообще или ещё чего-нибудь, форумы могут не работать куй знает сколько времени, пока я не починю конструкцию.

Так то.

Сейчас просто виртуалка у хостера автоматом стартует если что вдруг и всё ок. Может, конечно, что-нибудь отвалится, но пока всё норм было.

В общем, объективно я затеял хуйню. Для этой конструкции нужна оперативная поддержка, которую я предоставить не могу.