Декабрь 11th, 2015 
Evgeniy Kamenev Разработчик продукта рекомендует использовать минимум 3 ноды для создания кластера(причины описаны в статье). С целью знакомства с этим продуктом использовалось две ноды на виртуальных машинах.
1.Установка Percona XtraDB Cluster
Centos
|
1 |
# yum install http://www.percona.com/downloads/percona-release/redhat/0.1-3/percona-release-0.1-3.noarch.rpm |
Подключаем EPEL-репозитарий(если он еще не был подключен)
|
1 |
# rpm -Uvh http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-5.noarch.rpm |
Устанавливаем пакет, необходимій для Percona XtraDB Cluster
|
1 |
# yum install socat |
Устанавливаем PXC
|
1 |
# yum install Percona-XtraDB-Cluster-56 |
Отклчаем SELinux, если он включен
|
1 |
# nano /etc/selinux/config |
|
1 |
SELINUX=disabled |
|
1 |
# setenforce 0 |
|
1 |
# getenforce |
|
1 |
Disabled |
Ubuntu
|
1 |
# apt-key adv --keyserver keys.gnupg.net --recv-keys 1C4CBDCDCD2EFD2A |
|
1 2 3 |
# nano /etc/apt/sources.list deb http://repo.percona.com/apt trusty main deb-src http://repo.percona.com/apt trusty main |
|
1 |
# apt-get update |
|
1 |
# apt-get install percona-xtradb-cluster-56 |
Отключаем Apparmor для mysql
Порты,которые используются по умолчанию
Открываем в iptables следующие порты 3306, 4444, 4567 and 4568
3306 – подключение клиентов к MySQL-серверу (если клиенты подключаются удаленно, а не локально)
4567 – порт для групповой коммуникации — может быть изменен опцией
|
1 |
wsrep_provider_options ="gmcast.listen_addr=tcp://0.0.0.0:4010; " |
4444 – порт для State Snapshot Transfer (SST) — может быть изменен опцией
|
1 |
wsrep_sst_receive_address=<IP-address-node>:5555 |
4568 – порт для Incremental State Transfer(IST) – по умолчанию его значение выбирается, как значение порта для групповой коммуникации(4567) + 1 т.е 4568
Может быть изменен опцией
|
1 |
wsrep_provider_options = "ist.recv_addr=<IP-address-node>:7777; " |
В качестве метода State Snapshot Transfer (SST) используется xtrabackup.
При добавлении новой ноды в кластер она будет подключаться к существующей/донорской ноде в кластере и снимать с нее бекап с помощью xtrabackup и копировать этот бекап к себе с помощью socat
Нода получает изменения от донорской ноды через механизм SST(state snapshot transfer)или IST(incremental snapshot transfer). Если добавляется новая нода в кластер, то применяется SST-создается полная копия с существующей ноды. Существует три способа получения такой копии
Mysqldump, rsync, xtrabackup.
Недостатком mysqldump и rsync является то, что на время снятия бекапа с донорской ноды, все таблицы донорской ноды блокируются на запись (SST использует FLUSH TABLES WITH READ LOCK).
В отличии от mysqldump и rsync, Xtrabackup не накладывает такую блокировку(за исключением,когда снимает бекап таблиц schemas и НЕ InnoDB таблиц)
IST-инкрементный бекап используется тогда, когда нода отсутствовала в кластере непродолжительное время — state UUID добавляемой ноды такой же, как и на донорской ноде И все пропущенные/недостающие изменения (write-set) доступны в кеше донорской ноды. Количество изменений, которое донорская нода хранит в своем кеше определяется параметром gcache.size – размером системной памяти, выделяемой для хранения таких изменений(параметр настраивается в конфигурационном файле). Т.е донорская нода определенное кол-во изменений сохраняет у себя в буфере и способна отдать эти изменения на недолго отсутствующую в кластере ноду из этого кеша/буфера. Если размер таких изменений превосходит размер, определенный параметром gcache.size, то снимается с донорской ноды полный бекап.
Например, на добавляемой ноде состояние, на котором остановилась нода
|
1 |
5a76ef62-30ec-11e1-0800-dba504cf2aab:197222 |
А на донорской ноде/всех остальных нодах
|
1 |
5a76ef62-30ec-11e1-0800-dba504cf2aab:201913 |
Т.е state UUID одинаковы 5a76ef62-30ec-11e1-0800-dba504cf2aab
(выполняется первое условие для IST)
Теперь донорская нода проверяет свой кеш на наличие write-set с номером(sequence number – seqno 197223). Если он обнаруживается, значит использует инкрементный бекап(IST). Если не обнаруживается – полный (SST)
Нода считается недоступной и будет выброшена с кластера, если она не отвечает в течение времени, установленного параметром
|
1 |
evs.suspect_timeout |
(по умолчанию 5 секунд)
Этот параметр можно узнать из вывода всех настроек командой
|
1 |
# mysql -e "show variables like '%wsrep_provider_options%'" |
Если в кластере используется только 2 ноды и одна из них теряет связь с другой нодой, то обе ноды переходит в режим No-Primary — перестают принимать запросы для предотвращения нарушения консистентности данных(split-brain)
Т.к в случае использования двух нод и недоступности их друг друга, кворум на этих нодах будет ½ (50%) – ОДИНАКОВЫМ на обеих нодах, что не позволяет выбрать первичную(главную) ноду
Если, например, используется кластер из трех нод и при этом одна нода теряет связь с остальными, то у оставшихся двух нодах, которые доступны между собой кворум будет 2/3(66%), а у проблемной ноды 1/3(33%). Нода, которая имеет наименьший кворум перестанет обрабатывать запросы — проблемная нода перестанет принимать запросы
Например, на второй ноде добавим правило для блокировки трафика между этими нодами
|
1 |
# iptables -I INPUT -s 192.168.1.82 -d 192.168.1.83 -j DROP |
До добавления правила
|
1 2 3 4 5 6 7 8 9 |
mysql> show status like '%wsrep_cluster%'; +--------------------------+--------------------------------------+ | Variable_name | Value | +--------------------------+--------------------------------------+ | wsrep_cluster_conf_id | 4 | | wsrep_cluster_size | 2 | | wsrep_cluster_state_uuid | a10a9bf4-9626-11e5-8152-e35928b8c96c | | wsrep_cluster_status | Primary | +--------------------------+--------------------------------------+ |
После добавления правила и истечения 5 секунд(evs.suspect_timeout) статус ОБОИХ нод изменится на non-Primary
|
1 2 3 4 5 6 7 8 9 |
mysql> show status like '%wsrep_cluster%'; +--------------------------+--------------------------------------+ | Variable_name | Value | +--------------------------+--------------------------------------+ | wsrep_cluster_conf_id | 18446744073709551615 | | wsrep_cluster_size | 1 | | wsrep_cluster_state_uuid | a10a9bf4-9626-11e5-8152-e35928b8c96c | | wsrep_cluster_status | non-Primary | +--------------------------+--------------------------------------+ |
После чего использование mysql становится невозможным
|
1 |
mysql> use kamaok; |
|
1 |
ERROR 1047 (08S01): WSREP has not yet prepared node for application use |
Теоретически можно изменить пару параметров
По умолчанию они имеют такие значения
|
1 2 |
pc.ignore_quorum = false - НЕ игнорировать подсчет кворума pc.ignore_sb = false – НЕ игнорировать split brain |
Но это может привесте к рассогласованию/неконсистенции данных на нодах
https://www.percona.com/blog/2012/07/25/percona-xtradb-cluster-failure-scenarios-with-only-2-nodes/
Поэтому при использовании только двух нод для репликации рекомендуется использовать Galera Arbitrator
http://galeracluster.com/documentation-webpages/arbitrator.html
Если при использовании двух нод запись происходит только на одну ноду (вторая просто реплицирует на себе все, что записано на первую и будет использоваться в случае выхода со строя первой ноды) и при выходе со строя любой ноды нужно разрешить обрабатывать запросы на оставшейся ноде, то необходимо выполнить команду на оставшейся ноде
|
1 |
mysql> SET GLOBAL wsrep_provider_options='pc.bootstrap=true'; |
После чего эта нода сможет обрабатывать все подключения.
После добавления бывшей проблемной ноды в кластер она вытянет все изменения с текущего донора (на котором устанавливали SET GLOBAL wsrep_provider_options=’pc.bootstrap=true’; )
Мониторинг кластера
Состояние ноды в кластере
|
1 |
# mysql -e "show status like 'wsrep_cluster_status'" |
Состояние ноды
|
1 |
# mysql -e "show status like 'wsrep_connected'" |
Конфликты репликации
|
1 |
# mysql -e "show status like 'wsrep_local_cert_failures'" |
|
1 |
# mysql -e "show status like 'wsrep_local_bf_aborts'" |
Сообщения управления
|
1 |
# mysql -e "show status like 'wsrep_flow_control_sent'" |
|
1 |
# mysql -e "show status like 'wsrep_flow_control_recv'" |
Большие очереди репликации
|
1 |
# mysql -e "show status like 'wsrep_local_recv_queue'" |
Метрики
Размеры очереди
|
1 |
# mysql -e "show status like 'wsrep_local_recv_queue'" |
|
1 |
# mysql -e "show status like 'wsrep_local_send_queue'" |
Управление потоком
|
1 |
# mysql -e "show status like 'wsrep_flow_control_sent'" |
|
1 |
# mysql -e "show status like 'wsrep_flow_control_recv'" |
Количество входящих и исходящих транзакций на ноде
|
1 |
# mysql -e "show status like 'wsrep_replicated'" |
|
1 |
# mysql -e "show status like 'wsrep_received'" |
Количество байт входящих и исходящих транзакций
|
1 |
# mysql -e "show status like 'wsrep_replicated_bytes'" |
|
1 |
# mysql -e "show status like 'wsrep_received_bytes'" |
Конфликты репликации
|
1 |
# mysql -e "show status like 'wsrep_local_cert_failures'" |
|
1 |
# mysql -e "show status like 'wsrep_local_bf_aborts'" |
Настройка первой/донорской ноды(192.168.1.82)
|
1 |
# nano /etc/my.cnf |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 |
[mysqld] # method used for the state snapshot transfer wsrep_sst_method = xtrabackup-v2 #wsrep_sst_method = rsync # MyISAM storage engine has only experimental support default_storage_engine = InnoDB # Authentication data for SST. It isn't necessery to set up this iption if you use rsync as SST wsrep_sst_auth = "sstuser:sstpassword" # In order for Galera to work correctly binlog format should be ROW binlog_format = ROW innodb_buffer_pool_size = 100M innodb_flush_log_at_trx_commit = 0 innodb_flush_method = O_DIRECT innodb_log_files_in_group = 2 innodb_log_file_size = 128M innodb_file_per_table = 1 datadir = /var/lib/mysql #Cluster connection URL containing the IPs of other nodes in the cluster #wsrep_cluster_address = gcomm:// wsrep_cluster_address = gcomm://192.168.1.82,192.168.1.83 # Path to Galera library wsrep_provider = /usr/lib64/galera3/libgalera_smm.so # Количество потоков репликации wsrep_slave_threads = 2 # XtraDB Cluster Name wsrep_cluster_name = My_mysql_cluster # IP address this node wsrep_node_name = 192.168.1.82 innodb_locks_unsafe_for_binlog = 1 # This changes how InnoDB autoincrement locks are managed innodb_autoinc_lock_mode = 2 |
Если используется xtrabackup в качестве метода SST, То создаем пользователя с необходимыми правами.
Если используется mysqldump в качестве SST/IST, то необходимо указывать пользователя/пароль root mysql в параметре wsrep_sst_auth
Если используется метод rsync, то этот метод не требует указания логина/пароля в параметре wsrep_sst_auth
Создаем пользователя с необходимымы правами
|
1 2 3 |
mysql> create user 'sstuser'@'localhost' IDENTIFIED BY 'sstpassword'; mysql> grant reload, lock tables, replication client on *.* to 'sstuser'@'localhost'; mysql> flush privileges; |
Основная/Донорская нода запускается командой
Centos
|
1 |
# systemctl startmysql@bootstrap.service |
В дальнейшем все ноды запускаются через
|
1 |
# systemctl start mysql.service |
Ubuntu
|
1 |
# nano /etc/mysql/my.cnf |
Все параметры аналогично параметрам в Centos за исключением нахождения библиотеки Galera
|
1 |
wsrep_provider = /usr/lib/libgalera_smm.so |
Основная/Донорская нода запускается командой
|
1 |
# /etc/init.d/mysql bootstrap-pxc |
В дальнейшем все ноды запускаются через
|
1 |
# service mysql start |
Если необходимо остановить уже запущенную службу MySQL
|
1 |
# /etc/init.d/mysql stop |
Вывод всех переменных
|
1 |
mysql> show status like 'wsrep%'; |
Самые важные параметры
|
1 2 3 4 5 6 7 8 |
wsrep_local_state_uuid a10a9bf4-9626-11e5-8152-e35928b8c96c wsrep_local_state 4 wsrep_local_state_comment Synced wsrep_cluster_size 1 wsrep_cluster_state_uuid a10a9bf4-9626-11e5-8152-e35928b8c96c wsrep_cluster_status Primary wsrep_connected ON wsrep_ready ON |
Настройка второй ноды(192.168.1.83)
|
1 |
# nano /etc/my.cnf |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 |
[mysqld] # method used for the state snapshot transfer wsrep_sst_method = xtrabackup-v2 #wsrep_sst_method = rsync # MyISAM storage engine has only experimental support default_storage_engine = InnoDB # Authentication data for SST. It isn't necessary to set up this option if you use rsync as SST wsrep_sst_auth = "sstuser:sstpassword" binlog_format = ROW innodb_buffer_pool_size = 100M innodb_flush_log_at_trx_commit = 0 innodb_flush_method = O_DIRECT innodb_log_files_in_group = 2 innodb_log_file_size = 128M innodb_file_per_table = 1 datadir = /var/lib/mysql #Cluster connection URL containing the IPs of other nodes in the cluster #wsrep_cluster_address = gcomm:// wsrep_cluster_address = gcomm://192.168.1.82,192.168.1.83 # Path to Galera library wsrep_provider = /usr/lib64/galera3/libgalera_smm.so # Количество потоков репликации wsrep_slave_threads = 2 # XtraDB Cluster Name wsrep_cluster_name = My_mysql_cluster # IP address this node wsrep_node_name = 192.168.1.83 innodb_locks_unsafe_for_binlog = 1 # This changes how InnoDB autoincrement locks are managed innodb_autoinc_lock_mode = 2 [mysqld_safe] pid-file = /run/mysqld/mysql.pid syslog !includedir /etc/my.cnf.d |
Запуск второй ноды
|
1 |
# systemctl start mysql |
После подключения второй ноды смотрим параметры(они одинаковы на всех нодах кластера)
Например, на второй ноде
|
1 2 3 4 5 6 7 8 |
wsrep_local_state_uuid a10a9bf4-9626-11e5-8152-e35928b8c96c wsrep_local_state 4 wsrep_local_state_comment Synced wsrep_cluster_size 2 wsrep_cluster_state_uuid a10a9bf4-9626-11e5-8152-e35928b8c96c wsrep_cluster_status Primary wsrep_connected ON wsrep_ready ON |
|
1 2 3 4 5 6 7 |
# mysql -e "show global status like 'wsrep_cluster_size';" +--------------------+-------+ | Variable_name | Value | +--------------------+-------+ | wsrep_cluster_size | 2 | +--------------------+-------+ |
Проверяем репликацию
На второй ноде создаем пустую базу
|
1 |
mysql> create database kamaok |
Проверем ее наличие на первой
|
1 2 |
# mysql -e "show databases" | grep kamaok kamaok |
На первой ноде вливаем дамп в вновь созданную базу
|
1 |
# mysql kamaok < kamaok.sql |
В логах на первой ноде видно, что репликация для myisam таблиц выключена
|
1 |
[Note] WSREP: Cannot replicate MyISAM DDL for kamaok.wp_comments with wsrep_replicate_myisam OFF |
Включаем репликация myisam на обоих нодах
|
1 |
wsrep_replicate_myisam = ON |
Останавливаем вторую ноду
|
1 |
# systemctl stop mysql |
Перезапускаем первую ноду
|
1 |
# systemctl restart mysql@bootstrap |
После чего запускаем вторую ноду
|
1 |
# systemctl start mysql |
Проверка текущего состояния ноды
|
1 2 3 4 5 6 |
# mysql -e "show status like 'wsrep_local_state_comment'" +---------------------------+--------+ | Variable_name | Value | +---------------------------+--------+ | wsrep_local_state_comment | Synced | +---------------------------+--------+ |
Больше по мониторингу статистики Percona XtraDB Cluster
Источник:
https://www.percona.com/doc/percona-xtradb-cluster/5.6/index.html
https://www.percona.com/blog/2012/07/25/percona-xtradb-cluster-failure-scenarios-with-only-2-nodes/
http://habrahabr.ru/post/152969/
Опубликовано в рубрике 
Метки: