провёл краш тест с выключением по кнопке. Всё выжило, гипервизоры, gluster том, кроме марии дб. Бугога. Причем не только кластер сломался, она вообще не захотела стартовать.

не, ну на куй его. Я восстановить не смогу. Либо надо научится делать. но я с этим не работаю, так что учиться не у кого.

Так дел не пойдёт, это ебаная БД - ключевой компонент. А из дампа клон скуля восстанавливать несколько часов.

Что любопытно, текущая БД тоже несколько раз перегружалась, ну может не так жёстко, но аварийно, и поднималась сама.

Будем читать. Да и Деда Марию не тестировал.

Затеял поебень на свою голову и кошелёк. (

Я так понял, что переключаться на него сложнее. Если я правильно понял. Но полностью согласен, тут опытом надо обладать. Интересно, master slave - тоже ёпнутся две бд, если по кнопке ипануть? Не, ну репликация развалится, такое я чинил как-то, там вообще отлаженный механизм

Ну ос тут точно не причём, да и субд тоже. Субд -форк 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. А с учётом того, что я могу сидеть на объекте за периметром, без интернета вообще или ещё чего-нибудь, форумы могут не работать куй знает сколько времени, пока я не починю конструкцию.

Так то.

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

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

да не, планирую доделать. Вот ещё день сегодня. Просто если что сломается, оно само (как сейчас) не поднимется с вероятностью более 50%, а если поднимется то в большинстве случаев в аварийном режиме. Ну и если меня в оперативной доступности не будет, то форум может долго не работать :)

Когда доделаю - хз. До расчётного периода опять не успеваю, так что пока этот фунциклирует.

Ну надо было раньше думать. Щас поздно.

Не дешевле. Тут железки брэндовые, HP DL360 с плюшками. Жаль, что не успеваю до мая.

всё думал, что делать с mariadb

Буду делать 4 узла в galera cluster multimaster. По два на каждой физической ноде. При отвале одной физической ноды кворум будет сохранён, кластер продолжит работу. накладные расходы 75%. Жесть, конечно. То есть, 4-way replication по сути. из 2 теров емкости 512 гигов рабочих.

Запросы размажем по всем узлам при помощи, скорее всего, haproxy, но я ещё почитаю доку по sqlproxy

Другого выходя у меня нет. Классическая репликация master - slave - ну на куй он по сути. Ну есть эта копия данных, ресурсы тратятся, требует манипуляций при переключении, также шикарно отваливается при падении и требует починки.

ну.... что сказать, попробуем в такой конфигурации. Если будет все время плохо перейдём на master slave.

Я конечно понимаю, что лучше прислушаться к твоему опыту, так как у меня его нет в этом вопросе.

Спрошу:
- а давно это у тебя было? что ломалось? вроде читаю сейчас никто особо не жалуется
- что именно ломалось, в общих чертах, можешь уточнить?

Но решение же существует, им пользуются, километры документации, тонны реализаций, поисковики завалены статьями, неужели всё так плохо?

Ты не путаешь репликацию с кластером?

нет, я хочу кластер, а не репликацию.

https://mariadb.com/kb/en/what-is-mariadb-galera-cluster/

ну естсетсвенно, понимание репликации там присутствует, но это не то, что ты имеешь в виду.

Ну.... думаю, попробовать стоит. Будут труднорешаемые, постоянные проблемы - переделаем

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