Боюсь, что полноценно не смогу помочь вам с ответом, т.к. полтора года назад я сменил место работы и более с распределёнными кластерами Percona Cluster не работал.
На текущем месте видел у соседней команды Galera Cluster в рамках одного ДЦ - работает нормально, но внутренностями не интересовался.
В своих текущих реалиях могу сказать, что между ДЦ мы используем асинхронную репликацию между несколькими PostgreSQL серверами. Т.к. сервера в Новосибирске, Москве и Европе, а объёмы данных велики(>30-100 Гб на некоторые БД) - синхронная репликация для нас не позволительна. Восстановление слейвов - редко, но бывает и мы считаем это нормальной ситуацией, которая просто должна хорошо мониториться.
pashaxp: При использовании PXC в разных ДЦ, с большим пингом между ними - производительность записи/изменения данных будет очень низкой.
Синхронная репликация неплохо себя чувствует в рамках одного ДЦ.
Между разными ДЦ лучше поднимать обычный асинхронный Master-Slave у MySQL и переключаться на второй сервер - в случае проблем на первом.
Тут нужно смотреть состояние сервера во время падения. Кто наибольший потребитель памяти(возможно что это и не MySQL) ? Чьих процессов в системе больше всего и почему так произошло?
На эти вопросы поможет ответить atop или подключение системы мониторинга к серверу(мы обычно используем Zabbix).
Для чего используется сервер? Если это веб-сервер - надо смотреть нагрузку которую создают Apache или PHP-FPM, uwsgi или какие-либо другие backend-сервера(смотря что у Вас используется для этого). Веб-сервера тоже любят память.. особенно много памяти если их ничего не сдерживает :)
В целом, в RC он был уже ранее, что-то удалось обкатать раньше, что-то ещё нет. Успешные форки redis-trib.rb уже есть. Правда классов для работы с кластером не так много(один PHP, один C++ и ещё на нескольких ЯП). Но вдруг, кто-то его ещё использует с RC2.8, для некритичных задач..
Дмитрий: Жаль что fastvps.ru не поддерживает курса ЦБ по евро и около месяца назад "их евро" стоил около 85 рублей.
А так да, около 3-4к будет этот сервер, правда не факт что цена останется прежней(т.к. зависит от курса)
Юрий Петрашевич: тогда можно попробовать использовать haproxy. Насколько помню - там можно задать 'backup' сервер. На него запросы пойдут при недоступности первого сервера.
Использование обычного, асинхронного, Master-Master в MySQL можно, но надо всегда следить за состоянием репликации, т.к. в один прекрасный момент можно обнаружить что у Вас уже разные БД на обоих серверах.
Ну и интересный вопрос - а почему MySQL не смог обработать запрос на первом сервере, но должен это сделать на втором ?) (вижу ответ, что только если MySQL на первом сервере лежит, отдыхает)
На виртуалках уже развернул кластер на Percona - при простых запросах отрабатывает на "ура!", попробую более нагруженные тесты прогнать на днях.
Скажите, пожалуйста, на скольких машинах у Вас был развёрнут кластер? Ноды выходили из него без каких-либо предупреждений? Выходил из строя именно сервис Percona, или весь сервер целиком? После выхода из строя - требовалось восстанавливать данные с ноды донора?
@RicoX , спасибо за ответ!
Можете ли Вы рассказать - были ли Ваши тесты на каком-либо боевом проекте, либо это было "ручное" тестирование?
Требовалось ли как-либо подстраивать БД для их размещения в кластерах(особенно интересуют различия между Percona и MySQL-Cluster)?
Алексей, добрый вечер!
Боюсь, что полноценно не смогу помочь вам с ответом, т.к. полтора года назад я сменил место работы и более с распределёнными кластерами Percona Cluster не работал.
На текущем месте видел у соседней команды Galera Cluster в рамках одного ДЦ - работает нормально, но внутренностями не интересовался.
В своих текущих реалиях могу сказать, что между ДЦ мы используем асинхронную репликацию между несколькими PostgreSQL серверами. Т.к. сервера в Новосибирске, Москве и Европе, а объёмы данных велики(>30-100 Гб на некоторые БД) - синхронная репликация для нас не позволительна. Восстановление слейвов - редко, но бывает и мы считаем это нормальной ситуацией, которая просто должна хорошо мониториться.