Percona XtraDB Cluster

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 13:51, 28 декабря 2016.
Percona XtraDB Cluster
Logo percona xtradbcluster new.png
--
Разработчики: Percona
Платформа: x86-64
Лицензия: GPLv2
Веб-сайт https://www.percona.com

Percona XtraDB Cluster - кластерная СУБД, предоставляющая решение для создания кластеров с синхронной репликаций между узлами, работающими в режиме multi-master. Percona XtraDB Cluster обеспечивает высокую производительность, быстрое восстановление узла кластера после падения и полный контроль состояния кластера. Исходные тексты проекта распространяются под лицензией GPLv2.

Основные преимущества

  • Синхронная репликация. Транзакция проходит либо на всех нодах, либо ни на каком.
  • Режим multi-master. Писать данные можно в любой нод.
  • Параллельная репликация.
  • Высокая консистентность данных.
  • Полная совместимость с базами данных MySQL.
  • Полная совместимость с приложениями, работающими с MySQL.
  • Балансировщик нагрузки ProxySQL.
  • Легко настраиваемое зашифрованное общение между нодами.
  • Высокая масштабируемость.

Общая схема работы

Кластер состоит из нодов. Рекомендуется использовать хотя бы 3 нода, хотя ничего не мешает настроить и 2.

В каждом ноде находится обычный сервер MySQL или Precona Server. Таким образом, уже существующий сервер MySQL или Precona Server можно преобразовать в нод и добавить в кластер, и наоборот: любой нод можно отсоединить от кластера и использовать как обычный сервер. В каждом ноде находится полная копия данных.

Percona Cluster-diagram1.png

Особенности такой схемы:

Преимущества:

  • При исполнении запроса, он исполняется локально на ноде. Все данные можно найти на локальной машине, без необходимости удаленного доступа.
  • Отсутствует централизация. Любой нод можно отсоединить в любой момент, и кластер продолжит работать.
  • Отличное решения для большого количества запросов на чтение. Их можно направлять к любому ноду.

Недостатки:

  • Присоединение нового нода требует значительных ресурсов. Новый нод должен получить полную копию данных базы от одного из существующих новод. Если база составляет 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 строк. Так что большие транзакции будут разделены на серию маленьких.
  • Из-за контроля многопоточности на уровне кластера, транзакции, совершающие COMMIT, все еще могут быть прерваны на этом этапе. Могут быть две транзакции, пишущие в один и тот же ряд на разных нодах, и только одна из них будет успешно завершена. Другая будет прервана на уровне кластера (Error: 1213 SQLSTATE: 40001 (ER_LOCK_DEADLOCK)). Это еще раз подтверждает, что масштабируемость поддерживается, в основном, для большого объема чтения, но не записи.
  • XA транзакции не поддерживаются из-за возможного rollback-а на этапе коммита.
  • Способности кластера по записи ограничиваются возможностями самого слабого нода. Если один нод будет замедлен, с ним замедлится и весь кластер. Если вам необходима стабильная высокая производительность, она должна быть поддержана вашим аппаратным обеспечением.
  • Минимальный рекомендованный размер кластера - 3 ноды.
  • enforce_storage_engine=InnoDB несовместим с wsrep_replicate_myisam=OFF.
  • Переменная binlog_rows_query_log_events не поддерживается.

Установка Percona

Из пакетов

Готовые бинарники Percona XtraDB Cluster доступны для скачивания с официального сайта, включая:

  • RPM-пакеты для RHEL 5 и RHEL 6.
  • Debian-пакеты.
  • .tar.gz пакеты для общего применения.

Из репозиториев

Precona предоставляет репозитории для yum (Red Hat, CentOS, ...) и apt (Debian, Ubuntu, ...) для всех продуктов Percona: Percona Server, XtraDB, XtraBackup и Percona Toolkit. Таким образом, программное обеспечение легко устанавливать и обновлять с помощью пакетного менеджера вашей операционной системы. Именно из репозиториев рекомендуется устанавливать Percona.

С помощью yum

После настройки репозитория, используйте следующую команду:

$ yum install Percona-XtraDB-Cluster-55

С помощью apt

После настройки репозитория, используйте следующую команду:

$ sudo apt-get install percona-xtradb-cluster-55

Для корректной работы Percona XtraDB Cluster необходимо настроить межсетевой экран и разрешить соединения по следующим портам: 3306, 4444, 4567 и 4568. Percona XtraDB Cluster в настоящее время не работает с SELinux или apparmor, так что их необходимо отключить, иначе отдельные ноды не смогут общаться и образовывать кластер.

Конфигурация

Для начала использования Percona XtraDB Cluster необходимо добавить следующие опции в файл my.cnf:

[mysqld]
 wsrep_provider — a path to Galera library.
 wsrep_cluster_address — Cluster connection URL containing the IPs of other nodes in the cluster
 wsrep_sst_method - method used for the state snapshot transfer
 binlog_format=ROW - In order for Galera to work correctly binlog format should be ROW
 default_storage_engine=InnoDB - MyISAM storage engine has only experimental support
 innodb_autoinc_lock_mode=2 - This changes how InnoDB autoincrement locks are managed</tt>

Дополнительные параметры:

wsrep_sst_auth=user:password

Установка на Ubuntu

Если ранее MySQL был установлен на сервере, то может быть профиль AppArmor, который предотвратит узлы кластера Percona XtraDB от общения друг с другом. Наилучшим решением является удаление пакета AppArmor полностью:

sudo apt-get remove apparmor

Fetch пакет для конфигурирования Percona репозитория программного обеспечения:

wget https://repo.percona.com/apt/percona-release_0.1-4.$(lsb_release -sc)_all.deb

Установите загруженный пакет с dpkg:

sudo dpkg -i percona-release_0.1-4.$(lsb_release -sc)_all.deb

После того как вы установите этот пакет, хранилище Percona должно быть добавлено. Вы можете проверить конфигурацию хранилища в /etc/apt/sources.list.d/percona-release.list file.

vi /etc/apt/sources.list.d/percona-release.list

Обновление локального кэша:

sudo apt-get update

Установите пакет сервера Cluster Percona XtraDB:

sudo apt-get install percona-xtradb-cluster-57

Остановите mysql сервис:

sudo service mysql stop

Добавьте следующие переменные конфигурации в /etc/mysql/my.cnf on the first node:

wsrep_provider=/usr/lib/libgalera_smm.so

wsrep_cluster_name=pxc-cluster
wsrep_cluster_address=gcomm://192.168.70.61,192.168.70.62,192.168.70.63

wsrep_node_name=pxc1
wsrep_node_address=192.168.70.61

wsrep_sst_method=xtrabackup-v2
wsrep_sst_auth=sstuser:passw0rd

pxc_strict_mode=ENFORCING

binlog_format=ROW
defaul_storage_engine=InnoDB
innodb_autoinc_lock_mode=2

Для второго нода:

wsrep_node_name=pxc2
wsrep_node_address=192.168.70.62

Для третьего нода:

wsrep_node_name=pxc3
wsrep_node_address=192.168.70.63

Запустить первый узел с помощью следующей команды:

sudo /etc/init.d/mysql bootstrap-pxc

Чтобы убедиться в том, что кластер был инициализирован, выполните следующие действия:

mysql -uroot -p
show status like 'wsrep%';

Перед тем как добавлять другие узлы к новому кластеру, создать пользователя для SST и предоставить необходимые привилегии для него.

mysql -uroot -p
CREATE USER 'sstuser'@'localhost' IDENTIFIED BY 'passw0rd';
GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO 'sstuser'@'localhost';
FLUSH PRIVILEGES;

Запустите второй и третий ноды используя следующте команды:

/etc/init.d/mysql start

Особенности multi-master репликации

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

С Percona XtraDB Cluster можно писать в любой нод, и кластер гарантирует консистентность записи. То есть, запись либо произойдет на всех нодах, либо ни на одном. Для простоты, на этой диграмме показана работа для двух нодов, но схожим образом работает любое количество нодов:

Precona certificationbasedreplication.png

Все запросы исполняются локально на ноде, особым образом обрабатывается только COMMIT. Как только дана команда COMMIT, транзакция должна пройти верификацию на всех нодах. Если она не проходит, запрос вернет ошибку. После этого транзакция применяется в локальному ноду.

Время ответа на COMMIT состоит из следующих частей:

  • Время прохода по сети
  • Время верификации
  • Применение блокировки

Из этой архитектуры вытекают два важных следствия:

Во-первых, несколько потоков могут работать параллельно. Это и есть истинная параллельная репликация.

Во-вторых, существует небольшой период времени, когда slave не синхронизирован с master. Это происходит, потому что master может применить событие быстрее, чем slave. И если происходит чтение из slave, есть возможность прочитать данные, которые еще не изменились. Это видно из диаграммы. Впрочем, это поведение можно изменить, если использовать опцию variable wsrep_causal_reads=ON. В этом случае чтение на slave будет ожидать, пока событие не применится (это, впрочем, увеличивает время отклика чтения). Это явление - причина, почему репликация называется "почти синхронной", а не "истинно синхронной".

У такого поведения команды COMMIT есть еще одно важное следствие. Если ведется запись на два разных нода, кластер будет использовать оптимистичную модель блокировки. То есть, транзакция не будет проверять возможные конфликты блокировок во время отдельных запросов, а только лишь на стадии коммита, и можно получить ошибку при выполнении коммита. Это важно, потому что это одна из возможных несовместимостей с обычным движком InnoDB. В InnoDB ошибки вида DEADLOCK и LOCK TIMEOUT случаются в ответ на отдельные запросы, но не на коммит. Имеет смысл проверять наличие ошибок после запроса COMMIT, хотя есть приложения, которые этого не делают.

Если вы планируете пользоваться преимуществами multi-master и писать на несколько нод, озаботьтесь обрабатывать ошибки на коммите.

Балансировка нагрузки с HaProxy

Вот пример конфигурационного файла HaProxy

# this config needs haproxy-1.4.20
global
       log 127.0.0.1   local0
       log 127.0.0.1   local1 notice
       maxconn 4096
       uid 99
       gid 99
       daemon
       #debug
       #quiet
defaults
       log     global
       mode    http
       option  tcplog
       option  dontlognull
       retries 3
       redispatch
       maxconn 2000
       contimeout      5000
       clitimeout      50000
       srvtimeout      50000
listen mysql-cluster 0.0.0.0:3306
   mode tcp
   balance roundrobin
   option mysql-check user root
   server db01 10.4.29.100:3306 check
   server db02 10.4.29.99:3306 check
   server db03 10.4.29.98:3306 check

С такой конфигурацией HaProxy будет выполнять балансировку нагрузки между тремя нодами. В этом случае он проверяет только висит ли на порте 3306 сервис mysqld, но не принимает в расчет состояние нода. Вполне возможно, что он будет отсылать запросы к ноду, который находится в отсоединенном состоянии.

Литература

  1. Percona-official site [Электронный ресурс]: Официальный сайт Percona / Дата обращения: 28.12.2016. — Режим доступа: https://www.percona.com