Проверка работы репликации

35 
ЛАБОРАТОРНАЯ РАБОТА № 3. 
РАЗВЕРТЫВАНИЕ PERCONA XTRADB CLUSTER
3.1 Цель работы 
Цель лабораторной работы заключается в закреплении теоретических 
основ 
курса 
«Технологии 
построения 
распределенных 
защищенных приложений» и получении первоначальных навыков настройки 
кластера MySQL серверов, на основе Percona XtraDB Cluster.
3.2 Общие сведение 
3.2.1 Общая информация о Percona XtraDB Cluster 
Для гарантии целостности данных и возможности писать на все узлы 
кластера одновременно необходимо осуществление синхронной master-master 
репликации.
Для MySQL настоящее время наиболее известны следующие решения: 
 MySQL NDB Cluster; 
 Percona XtraDB Cluster; 
 MariaDB Galera Cluster. 
MySQL NDB Cluster (от производителя MySQL) в настоящее время еще 
слишком ограничен по своим возможностям. Percona XtraDB Cluster и MariaDB 
Galera Cluster построены на одном базовом решении «Galera synchronous multi-
master replication library» и очень близки по своих возможностям.
Percona XtraDB Cluster – кластерная СУБД, предоставляющая решение 
для создания кластеров с синхронной репликаций между узлами, работающими 
в режиме multi-master. Percona XtraDB Cluster обеспечивает высокую 
производительность, быстрое восстановление узла кластера после падения и 
полный 
контроль 
состояния 
кластера. 
Исходные 
тексты 
проекта 
распространяются под лицензией GPLv2. 
Основные преимущества: 
 синхронная репликация – транзакция проходит либо на всех узлах, 
либо ни на одном; 
 режим multi-master – писать данные можно в любой узел; 
 параллельная репликация; 
 высокая консистентность данных; 
 полная совместимость с базами данных MySQL; 
 полная совместимость с приложениями, работающими с MySQL; 
 балансировщик нагрузки ProxySQL; 
 легко настраиваемое зашифрованное общение между узлами; 
 высокая масштабируемость. 
 
Кластер состоит из множества узлов. Рекомендуется использовать хотя 
бы три узла, хотя возможно и использование и двух узлов. 

36 
В каждом узле находится обычный сервер MySQL или Precona Server. 
Таким образом, уже существующий сервер MySQL или Precona Server можно 
добавить в кластер, и наоборот: любой узел можно отсоединить от кластера и 
использовать как обычный сервер. В каждом узле находится полная копия 
данных. 
Преимущества такой схемы: 
 при исполнении запроса, он исполняется локально на узле. Все данные 
можно найти на локальной машине, без необходимости удаленного доступа; 
 отсутствует централизация. Любой узел можно отсоединить в любой 
момент, и кластер продолжит работать; 
 отличное решения для большого количества запросов на чтение. Их 
можно направлять к любому узлу. 
Недостатки такой схемы: 
 присоединение нового узла требует значительных ресурсов. Новый 
узел должен получить полную копию данных базы от одного из существующих 
узлов. Если база составляет 100 GB, то придется копировать все 100 GB; 
 неоптимальное масштабирование для большого количества запросов 
записи. Есть возможность увеличить производительность за счет направления 
трафика на несколько узлов, но суть проблемы от этого не меняется - все 
записи должны попадать на все узлы. 
Ограничения: 
 в настоящее время репликация работает только с движком InnoDB. 
Записи в таблицы, работающие на другом движке, не будут реплицированы. 
Впрочем, DLL-выражения реплицируются на уровне запросов, и изменения 
таблиц mysql.* все-таки будут реплицированы. Так что можно спокойно писать 
«CREATE USER...», а вот «INSERT INTO mysql.user...» реплицировано не 
будет; 
 неподдерживаемые 
запросы: LOCK/UNLOCK (принципиально 
невозможно в multi-master схеме) и сходные им функции; 
 лог запросов нельзя класть в базу. Если вы хотите логировать запросы к 
базе, лог необходимо направлять в файл; 
 максимальный 
размер 
транзакции 
определен 
значениями 
wsrep_max_ws_rows и wsrep_max_ws_size. LOAD DATA INFILE будет 
совершать коммит каждые 10 000 строк. Так что большие транзакции будут 

жүктеу/скачать 0.74 Mb.

Достарыңызбен бөлісу: