Дик-ДИ_2018_МУ. Технология построения защищенных распределенных приложений
 Скачать 0.74 Mb.
|
|
2.3.8.3 Проверка работы репликации Через MySql консоль на втором мастере (бывшем ведомом) добавим новую запись в таблицу simples нашей базы данных insert into clusterdb.simples values (10); Через MySql консоль на первом мастере посмотрим содержимое таблицы и удостоверимся, что первый мастер получил изменения select * from clusterdb.simples; Контрольные вопросы 2.4 1 Что такое репликация данных? 2 В чем отличие синхронной и асинхронной репликации? 3 В чем заключается master-slave репликация? 4 В чем заключается master-master репликация? 5 Недостатки асинхронной репликации? 6 Области применения асинхронной репликации? 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 строк. Так что большие транзакции будут разделены на серию маленьких; из-за контроля многопоточности на уровне кластера, транзакции, совершающие COMMIT, все еще могут быть прерваны на этом этапе. Могут быть две транзакции, пишущие в одну и туже запись разных узлах, и только одна из них будет успешно завершена. Другая будет прервана на уровне кластера (Error: 1213 SQLSTATE: 40001 (ER_LOCK_DEADLOCK)). Это еще раз подтверждает, что масштабируемость поддерживается, в основном, для большого объема чтения, но не записи; XA транзакции не поддерживаются из-за возможного rollback-а на этапе коммита; 37 способности кластера по записи ограничиваются возможностями самого слабого узла. Если один узел будет замедлен, с ним замедлится и весь кластер. Если вам необходима стабильная высокая производительность, она должна быть поддержана вашим аппаратным обеспечением. 3.2.2 Проблема split-brain и использование кворума Минимальный рекомендованный размер кластера – 3 узла, что связано с проблемой split-brain. Рассмотрим подробнее данную проблему. Допустим, в нашей системе ровно два совершенно одинаковых узла — A и B. Каждый из них хранит копию данных второго и может независимо обрабатывать запросы извне. Каждый, обрабатывая запрос, уведомляет второго об изменениях, чтобы данные оставались согласованы. В случае аварии возможно два варианта: 1 Узел A выходит из строя. Система продолжает работать как ни в чем не бывало — B продолжает обрабатывать запросы. Когда A приведут в чувство, он первым делом синхронизируется с B и они вдвоем продолжат работать дальше. Ни доступность, ни согласованность не страдают. 2 Потеряна связь между A и B. При этом каждый из них продолжает принимать запросы извне, но не может уведомить второго об изменениях. Для каждого узла все выглядит так, будто второй узел «умер» и он действует в одиночку. Эту ситуацию часто называют «split-brain» — мозг разделился на два полушария, каждое из которых считает себя единственным хозяином ситуации. Если в этот момент на A был обработан запрос на удаление некой записи R, а на B был обработан запрос на модификацию той же самой записи, то данные стали не согласованы. Когда связь между A и B восстановится, при синхронизации всплывет конфликт — удалить R или оставить модифицированную версию? Согласованность данных утеряна. Для решения данной проблемы Percona XtraDB Cluster в конфигурации с двумя узлами работает до тех пор, пока не пропадет связь между узлами. В случае исчезновения связи кластер полностью блокируется. Теперь посмотрим, как ведет себя кластер из трех узлов. Будем считать, что все узлы имеют одинаковый вес, что является значением по умолчанию. Что произойдет, если узел 1 штатно остановлен (выполнена остановка сервиса MySQL)? При завершении работы узел 1 сообщит, что он покидает кластер. Теперь у нас есть кластера из двух узлов, на оставшихся членов кластера приходится 2/2 = 100% голосов. Кластер продолжает работать нормально. Что произойдет, если и узел 2 штатно будет остановлен? Теперь узел 3 знает, что узел 2 больше не является частью кластера. Узел 3 теперь имеет 1/1 = 100% голосов и кластер с одним узлом может продолжать работать. В этих сценариях нет необходимости в достижении кворума при голосовании, так как остальные узлы всегда знают, что произошло с узлами, покидающими кластер. 38 Теперь рассмотрим другую ситуацию. На том же 3-узловом кластере, где запущены все 3 узла, если узел 1 аварийно завершит работу. На этот раз узлы 2 и 3 должны провести голосование, чтобы определить, имеют ли они кворум и могут ли безопасно продолжить работу. Они имеют 2/3 голосов, 2/3 > 50%, так что оставшиеся 2 узла имеют кворум и продолжают работать нормально. Необходимо иметь в виду, что голосование происходит не сразу, когда узлы 2 и 3 не могут присоединиться к узлу 1. Голосование происходит только после достижения тайм-аута (равного по умолчанию 5 секундам). Это позволяет кластеру быть устойчивым к кратковременным сбоям сети и может быть весьма полезны при работе кластера через глобальную сеть. Следствием является то, что в случае сбоя узла операции записи останавливаются на время тайм-аута. Что произойдет, если узел 2 также выйдет из строя? Опять же необходимо провести голосование. На этот раз узел 3 имеет только 1/2 голосов, что не превышает 50% голосов. Узел 3 не имеет кворума, поэтому он прекращает обработку чтения и записи. Если посмотреть в этом случае на переменную состояния wsrep_cluster_status на оставшемся узле, она покажет значение NON_PRIMARY. Это означает, что узел не является частью основного компонента. 3.2.3 Особенности репликации в Percona XtraDB Cluster В Percona XtraDB Cluster можно выполнять запись на любом узле и при этом кластер гарантирует консистентность записи. То есть, запись либо произойдет на всех узлах, либо ни на одном. Все запросы исполняются локально на узле, особым образом обрабатывается только коммит (commit). Как только дана команда коммит, транзакция должна пройти верификацию (подтверждение коммита) на всех узлах. Транзакция подтверждается только, если верификация проходит успешно, в противном случае происходит откат транзакции. Из этой архитектуры вытекают два важных следствия: во-первых, существует небольшой период времени, когда slave не синхронизирован с master. Это происходит, потому что master может зафиксировать коммит быстрее, чем slave. И если в этот момент происходит чтение из slave, есть вероятность прочитать еще не изменившиеся данные. Впрочем, это поведение можно изменить, если установив переменную настройки wsrep_causal_reads=ON. В этом случае чтение на slave будет ожидать, пока коммита не будет зафиксирован, что впрочем, увеличивает время отклика на операцию чтения. во-вторых, если ведется запись на два разных узла, кластер будет использовать оптимистичную модель блокировки. То есть, транзакция не будет проверять возможные конфликты блокировок между узлами во время отдельных запросов, а только лишь на стадии коммита. Таким образом, можно 39 получить ошибку при выполнении коммита, что в обычном InnoDB MySQL не возможно. В InnoDB MySQL ошибки вида DEADLOCK и LOCK TIMEOUT могут возникать только в ответ на отдельные запросы, но не на коммит. Поэтому приложения, использующее Percona XtraDB Cluster, должны в обязательном порядке проверять ошибку коммита. 3.3 Порядок выполнения работы 3.3.1 Установка операционной системы В качестве операционной системы для нашего кластера будем использовать Ubuntu Server 16.04.3 LTS. Все узлы будут работать на VirtualBox. Выставим следующие системные настройки для виртуальной машины: 10 GB пространства для жёсткого диска, два ядра и 512 Мб памяти. Виртуальную машину можно оснастить двумя сетевыми адаптерами: один NAT, а другой для внутренней сети. После того, как была скачена и установлена операционная система, необходимо обновиться и установить ssh и rsync: sudo apt-get update && sudo apt-get upgrade sudo apt-get install ssh sudo apt-get install rsync Для редактирования файлов с консоли будем использовать редактор nano. Для его установки введем команду: sudo apt-get install nano Для запуска: nano файл или если нужно редактировать системные файлы (с root правами), то sudo nano файл Для удобства также можно поставит оболочку Midnight Commander sudo apt-get install mc для ее запуска mc или если хотите редактировать системные файлы (с root правами), то sudo mc 3.3.2 Добавление репозитария Percona Скачаем пакет репозитария: wget https://repo.percona.com/apt/percona-release_0.1-4.$(lsb_release - sc)_all.deb Инсталлируем скачанный пакет командой sudo dpkg -i percona-release_0.1-4.$(lsb_release -sc)_all.deb 40 Обновим локальный apt кэш: sudo apt-get update Удостоверимся, что пакеты Percona стали доступными: sudo apt-cache search percona Вы увидите что-то подобное нижеследующему: percona-xtrabackup-dbg - Debug symbols for Percona XtraBackup percona-xtrabackup-test - Test suite for Percona XtraBackup percona-xtradb-cluster-client - Percona XtraDB Cluster database client percona-xtradb-cluster-server - Percona XtraDB Cluster database server percona-xtradb-cluster-testsuite - Percona XtraDB Cluster database regression test suite percona-xtradb-cluster-testsuite-5.5 - Percona Server database test suite Теперь у нас есть готовый образ, который послужит основой для создания кластера. Далее создадим четыре копии нашего образа. Три будут использоваться для серверов кластера и четвертая для приложения проксирования SQL- запросов к базам данных. При клонировании образов необходимо сгенерировать новые MAC- адреса для сетевых интерфейсов и выдать им необходимые IP-адреса. 3.3.3 Настройка статического IP адреса Для дальнейшей работы нам потребуются IP-адреса серверов. Для того чтобы узнать IP-адрес, можно воспользоваться командой ifconfig Вместо использования динамически выделенных адресов более удобным может оказаться использование статических адресов. Для настройки статического IP-адреса замените в файле /etc/network/interfaces для соответствующего интерфейса «dhcp» на «static» и укажите значения адреса, маски сети, шлюза и адрес DNS сервера для соответствия требованиям вашей сети: auto enp0s3 iface enp0s3 inet static address 192.168.0.1 netmask 255.255.255.0 gateway 192.168.0.254 dns-nameservers 192.168.0.254 В приведенных далее примерах для серверов используются адреса вида 192.168.1.X (таблица 1). 41 Таблица 1 – IP-адреса серверов кластера Узел Имя узла IP-адрес 1 pxc1 192.168.1.164 2 pxc2 192.168.1.165 3 pxc3 192.168.1.166 4 proxysql 192.168.1.167 Первые три узла будут использоваться для Percona XtraDB Cluster, а четвертый для ProxySQL. 3.3.4 Установка Percona XtraDB Cluster Установим пакет Percona XtraDB Cluster sudo apt-get install percona-xtradb-cluster-57 Остановим сервис mysql: sudo service mysql stop Добавим на первом узле в конфигурационный файл /etc/mysql/percona- xtradb-cluster.conf.d/wsrep.cnf следующие переменные: wsrep_provider=/usr/lib/libgalera_smm.so wsrep_cluster_name=pxc-cluster wsrep_cluster_address=gcomm://192.168.1.164,192.168.1.165,192.168.1.166 wsrep_node_name=pxc1 wsrep_node_address=192.168.1.164 wsrep_sst_method=xtrabackup-v2 wsrep_sst_auth=sstuser:passw0rd pxc_strict_mode=ENFORCING binlog_format=ROW default_storage_engine=InnoDB innodb_autoinc_lock_mode=2 На остальных узлах добавим те же конфигурационные значения за исключением переменных wsrep_node_name и wsrep_node_address. На втором узле установим значения переменных wsrep_node_name и wsrep_node_address в: wsrep_node_name=pxc2 wsrep_node_address=192.168.1.165 На третьем узле: wsrep_node_name=pxc3 wsrep_node_address=192.168.1.166 42 После конфигурирования узлов, инициализируем кластер развернув первый узел. Первый узел должна быть единственной содержащей реплицируемые данные на момент инициализации кластера. Развертывание подразумевает запуск узла с пустой конфигурационнной переменной wsrep_cluster_address (без указания адресов машин входящих в кластер). Чтобы не менять конфигурационный файл, можно воспользоваться командой: sudo /etc/init.d/mysql bootstrap-pxc При выполнении данной команды узел запускается в режиме развертывания с wsrep_cluster_address=gcomm://. После добавления остальных узлов можно перезапустить узел в нормальном режиме с использованием стандартной конфигурации. Удостоверимся что кластер был успешно инициализирован. Для этого войдем в консоль mysql: mysql -u root –p и выполним команду mysql@pxc1> show status like 'wsrep%'; +----------------------------------+--------------------------------------+ | Variable_name | Value | +----------------------------------+--------------------------------------+ | wsrep_local_state_uuid | 7e4a3888-d451-11e7-8bf9-037f76f76cc8 | | ... | ... | | wsrep_local_state | 4 | | wsrep_local_state_comment | Synced | | ... | ... | | wsrep_incoming_addresses | 192.168.1.164:3306 | | ... | ... | | wsrep_cluster_size | 1 | | wsrep_cluster_state_uuid | 7e4a3888-d451-11e7-8bf9-037f76f76cc8 | | wsrep_cluster_status | Primary | | wsrep_connected | ON | | ... | ... | | wsrep_ready | ON | +----------------------------------+--------------------------------------+ 67 rows in set (0.01 sec) Результат выполнения команды показывает, что кластер содержит 1 узел, это основной компонент кластера, узел находится в синхронизированном состоянии, подключен к кластеру и готов к репликации данных. Перед добавлением других узлов создадим пользователя для передачи мгновенных снимков состояния (SST) и предоставим ему необходимые привилегии: mysql@pxc1> CREATE USER 'sstuser'@'localhost' IDENTIFIED BY 'passw0rd'; mysql@pxc1> GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO 'sstuser'@'localhost'; mysql@pxc1> FLUSH PRIVILEGES; 43 3.3.5 Добавление узлов в кластер Корректно сконфигурированные новые узлы добавляются к кластеру автоматически. При запуске узла с адресом, по крайней мере, одного запущенного узла в переменной wsrep_cluster_address он автоматически добавляется к кластеру и синхронизируется с ним. Все данные и настройки будут перезаписаны в соответствии с конфигурацией и данными узла донора. Не рекомендуется одновременно присоединять несколько узлов из-за возможных высоких накладных расходов на репликацию данных на новый узел. |