Компания Перкона (Percona) объявила (https://www.percona.com/about-percona/newsroom/press-release...) о выходе стабильной версии открытого продукта Percona XtraDB Cluster 5.7 (https://www.percona.com/software/mysql-database/percona-xtra...), предоставляющего решение для создания кластеров с синхронной репликаций между узлами, работающими в режиме multi-master. Система основан на наработках Percona Server 5.7 и Codership Galera Replicator 3.17. Percona XtraDB Cluster 5.7 обеспечивает высокую производительность, быстрое восстановление узла кластера после падения и полный контроль состояния кластера. Исходные тексты проекта распространяются (https://github.com/percona/percona-xtradb-cluster) под лицензией GPLv2.В новом релизе Percona XtraDB Cluster присутствуют расширенные возможности для повышения производительности и защищенности данных, продвинутого мониторинга и конфигурирования. Также предусмотрена упрощенная установка и поддержка ПО "Percona Monitoring and Management". Возможности и преимущества Percona XtraDB Cluster 5.7:
- Простота.
- Распределение нагрузки и управление трафиком на основе ProxySQL с дополнительной функциональностью для быстрой настройки и поддержки Galera-репликации.
- Поддержка NoSQL для обеспечения высокой доступности приложений.
- Удобный пакет загрузки включает все компоненты, необходимые для запуска Percona XtraDB Cluster.
- Безопасность
- Безопасный режим (Strict-Mode), блокирующий использование функциональности MySQL, не поддерживаемой Percona XtraDB Cluster, предотвращая повреждение данных.
- Поддержка шифрования хранимых, но не обрабатываемых данных (Data at Rest Encryption) для файлов физических табличных пространств.
- Производительность
- Улучшенная масштабируемость операций чтения и записи – маршрутизация запросов выполняется автоматически, любой запрос на чтение выполняется одним (любым) узлом.
- Оптимизация развёртываний в облаке – повышение доступности и сохранности данных благодаря поддержке множественных зон доступности (Multi-AZ).
- Предотвращение потери данных – синхронная репликация обеспечивает одновременную запись на все узлы кластера, либо полную отмену записи, при отказе хотя бы одного узла.
- Управляемость
- Целостность данных – автоматическая инициализация новых узлов гарантирует полную синхронизацию изменений внутри кластера.
- Минимальное время отклика - репликация на основе полноправных участников (multi-master replication) позволяет инициировать обновление данных с любого узла кластера.
- Расширенные возможности мониторинга – поддержка сбора данных через Performance Schema и интеграция с решением Percona Monitoring and Management (PMM).URL: https://www.percona.com/about-percona/newsroom/press-release...
Новость: https://www.opennet.ru/opennews/art.shtml?num=45268
И не рассыпается на хайлоад?
Split Brain
В MariaDB 10.1 это тоже из коробки реализовали, и ещё в 5.5 это реализовали в специальной версии "Галера Кластер".
> В MariaDB 10.1 это тоже из коробки реализовали, и ещё в 5.5 это реализовали в специальной версии "Галера Кластер".Только под нагрузкой оно помирает.
> Один человек считал, что поставив galera над mysql, он избавится от даунтайма. Даунтайм об этом ничего не знал и радостно вырос в разы.
> Поддержка NoSQL для обеспечения высокой доступности приложений.Вот, блджад, что бы это могло значить?
У мультимастера есть фундаментальные проблемы, готорые не решаются никакими buzzword-ами, и требуют аккуратных приложений и балансировки.
Какие?
посмелюсь высказать такую идею.
3 сервера в кластере, спрятаны за haproxy. Два помечены как бэкап один активный. те трафик гонится только на один сервер. для систем с большим количеством транзакция оно конечно не решение тк масштабирование сведено к нулю, однако для небольших как HA решение должно работать.
не ?
> посмелюсь высказать такую идею.
> 3 сервера в кластере, спрятаны за haproxy. Два помечены как бэкап один
> активный. те трафик гонится только на один сервер. для систем с
> большим количеством транзакция оно конечно не решение тк масштабирование сведено к
> нулю, однако для небольших как HA решение должно работать.
> не ?Решение вполне рабочее, плюс для read-only приложений можно в хапрокси выделить отдельный порт и указать все три ноды как равнозначные.
Как HA кластер, оно работает, и вполне устойчиво.
Со своими особенностями правда.Основная беда - общий InnoDB,а в нем исторически есть "узкие места".
Если несколько проектов на кластере, и у кого-нить пошел
множественный апдейт, или не дай Бог DDL - страдают все проекты на кластере.Для одного проекта - самое то, естественно при нормальной "обвязке" (HA proxy + vrrp) и отсутствии одиночной точки отказа.
"Железное" решение для одного проекта - дорого выходит, а
виртуализация для нагруженных БД - провал производительности,
ибо производительность данного кластера меньше чем производительность самого слабого узла (синхронная репликация).Большой плюс - отличное удобство обслуживания.
Любой узел можно в любой момент вывести из кластера, для бекапа или
обновления софта и т.д. Потом легко подключить обратно.
>>Поддержка NoSQL для обеспечения высокой доступности приложений.Так вот в чем секрет высокой доступности!
Формат XtraDB уже морально устарел, а они продолжают его протаскивать.