Дик-ДИ_2018_МУ. Технология построения защищенных распределенных приложений
 Скачать 0.74 Mb.
|
|
3.3.5.1 Запуск второго узла Для запуска второго узла воспользуемся командой (на машине сервера второго узла): sudo /etc/init.d/mysql start После запуска сервера mysql он должен автоматически выполнить репликацию данных (принять мгновенный снимок состояния (SST)). Для проверки статуса второго узла войдем в консоль mysql: mysql -u root –p и выполним команду mysql@pxc2> 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,192.168.1.165:3306 | | ... | ... | | wsrep_cluster_size | 2 | | wsrep_cluster_state_uuid | 7e4a3888-d451-11e7-8bf9-037f76f76cc8 | | wsrep_cluster_status | Primary | | wsrep_connected | ON | | ... | ... | | wsrep_ready | ON | +----------------------------------+-------------------------------------------------+ 67 rows in set (0.00 sec) Мы видим, что узел успешно добавлен к кластеру. Кластер содержит 2 узла, это основной компонент кластера, узел подключен к кластеру и готов к репликации данных. Если состояние узла как в примере Synced, то узел полностью принял SST, синхронизирован с кластером, и мы можем добавлять следующий узел. Если состояние Joiner это означает, что репликация снимка состояния еще не завершена. В этом случае не рекомендуется добавлять другие узлы. 44 3.3.5.2 Запуск третьего узла Для добавления третьего узла воспользуемся командой (на машине сервера третьего узла): sudo /etc/init.d/mysql start Для проверки статуса второго узла войдем в консоль mysql: mysql -u root –p и выполним команду mysql@pxc3> 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,192.168.1.166:3306,192.168.1.165:3306 | | ... | ... | | wsrep_cluster_size | 3 | | wsrep_cluster_state_uuid | 7e4a3888-d451-11e7-8bf9-037f76f76cc8 | | wsrep_cluster_status | Primary | | wsrep_connected | ON | | ... | ... | | wsrep_ready | ON | +----------------------------------+----------------------------------------------------------+ 67 rows in set (0.04 sec) Мы видим, что узел успешно добавлен к кластеру. Кластер содержит 3 узла, это основной компонент кластера, узел подключен к кластеру и готов к репликации данных. 3.3.6 Проверка работы репликации Для проверки работы репликации создадим новую базу данных на втором узле, создадим таблицу в базе третьем узле и добавим данные в таблицу на первом узле. Создадим базу данных на втором узле: mysql@pxc2> CREATE DATABASE percona; Query OK, 1 row affected (0.01 sec) Создадим таблицу на третьем узле: mysql@pxc3> USE percona; Database changed mysql@pxc3> CREATE TABLE example (node_id INT PRIMARY KEY, node_name VARCHAR(30)); Query OK, 0 rows affected (0.05 sec) Вставим запись на первом узле: mysql@pxc1> INSERT INTO percona.example VALUES (1, 'percona1'); Query OK, 1 row affected (0.02 sec) Проверим на втором узле, реплицирована ли запись: 45 mysql@pxc2> SELECT * FROM percona.example; +---------+-----------+ | node_id | node_name | +---------+-----------+ | 1 | percona1 | +---------+-----------+ 1 row in set (0.00 sec) 3.3.7 Установка ProxySQL ProxySQL это приложение для проксирования SQL-запросов к базам данных для MySQL кластера. Работает как отдельный демон, все SQL-запросы, которые необходимо проксировать, обрабатываются, затем, по заранее составленным правилам, демон подключается к необходимому MySQL-серверу и выполняет запрос, и уже после этого отдает результат приложению. Мы будем устанавливать ProxySQL на четвертый узел. Для установки воспользуемся командой (на четвертом узле): sudo apt-get install proxysql Для подключения к административному интерфейсу ProxySQL нам потребуется MySQL клиент. Мы можем использовать MySQL клиент, установленный на одном из узлов Percona XtraDB Cluster, либо установить его на узел с ProxySQL и подключаться локально. Воспользуемся вторым способом. Для этого установим на четвертый узел пакет Percona XtraDB Cluster: sudo apt-get install percona-xtradb-cluster-client-5.7 Подключимся к административному модулю ProxySQL с использованием пароля/логина по умолчанию: mysql -u admin -padmin -h 127 .0.0.1 -P 6032 mysql: [Warning] Using a password on the command line interface can be insecure. Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 1420 Server version: 5.5.30 (ProxySQL Admin Module) Copyright (c) 2009-2017 Percona LLC and/or its affiliates Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights reserved. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> 46 Посмотрим базы данных и таблицы ProxySQL: mysql@proxysql> SHOW DATABASES; +-----+---------+-------------------------------+ | seq | name | file | +-----+---------+-------------------------------+ | 0 | main | | | 2 | disk | /var/lib/proxysql/proxysql.db | | 3 | stats | | | 4 | monitor | | +-----+---------+-------------------------------+ 4 rows in set (0.00 sec) mysql@proxysql> SHOW TABLES; +--------------------------------------+ | tables | +--------------------------------------+ | global_variables | | mysql_collations | | mysql_query_rules | | mysql_replication_hostgroups | | mysql_servers | | mysql_users | | runtime_global_variables | | runtime_mysql_query_rules | | runtime_mysql_replication_hostgroups | | runtime_mysql_servers | | runtime_scheduler | | scheduler | +--------------------------------------+ 12 rows in set (0.00 sec) ProxySQL имеет несколько областей, где может размещаться конфигурация (рисунок 6). Рисунок 6 — Области хранения конфигурации ProxySQL Область времени выполнения (runtime) — непосредственно используется демоном ProxySQL и содержит всю конфигурационную информацию для проксирования запросов. Runtime Память Диск Конфигурационный файл 47 Область памяти (memory) — представляет собой SQLite3 базу данных, которая находится в памяти и используется для внесения изменений в конфигурацию. Конфигурирование осуществляется SQL-командами через стандартный MySQL-клиент. Область на дискового хранилища (disk) — представляет собой обычный SQLite3 базу на диске, в которую сохраняются данные внесенные через область памяти. Конфигурационный файл — конфигурационный файл /etc/proxysql.cnf. Используется в момент инициализации, содержит информацию о нахождении SQLite3 базы данных, информацию об административном интерфейсе, а так же начальную конфигурацию демона. Конфигурационный файл при запуске демона используется только при отсутствии базы данных на диске. Для перемещения конфигураций пользователей (MYSQL USERS) между памятью и областью времени выполнения используются команды: mysql> LOAD MYSQL USERS FROM MEMORY mysql> LOAD MYSQL USERS TO RUNTIME Из области времени выполнения в память: mysql> SAVE MYSQL USERS TO MEMORY mysql> SAVE MYSQL USERS FROM RUNTIME С дискового хранилища в память: mysql> LOAD MYSQL USERS TO MEMORY mysql> LOAD MYSQL USERS FROM DISK Из памяти в дисковое хранилище: mysql> SAVE MYSQL USERS FROM MEMORY mysql> SAVE MYSQL USERS TO DISK Из конфигурационного файла в память: LOAD MYSQL USERS FROM CONFIG Таким же образом перемещение можно осуществлять и для: MYSQL QUERY RULES (правила маршрутизации проксируемых запросов; правила также позволяют модифицировать запросы и даже кэшировать результаты); MYSQL SERVERS (сервера на которые проксируются запросы); MYSQL VARIABLES (переменные MySQL-сервера); ADMIN VARIABLES (переменные административных настроек, для данных переменных невозможно их чтение из конфигурационного файла); SCHEDULER (настройки планировщика периодических заданий, чтение их из конфигурационного файла также невозможно). 3.3.8 Добавление узлов кластера в ProxySQL Для балансировки нагрузки на узлы кластера ProxySQL использует концепцию групп узлов (hostgroups). Балансировка нагрузки осуществляется путем маршрутизации различных типов запросов на различные группы (с 48 использованием правил), при этом каждый узел может быть членом нескольких групп. Добавим наши три Percona XtraDB Cluster узла к группе по умолчанию (0). Для этого вставим записи соответствующие записи в таблицу mysql_servers . mysql@proxysql> INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (0,'192.168.1.164',3306); mysql@proxysql> INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (0,'192.168.1.165',3306); mysql@proxysql> INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (0,'192.168.1.166',3306); Посмотрим результат: mysql@proxysql> SELECT * FROM mysql_servers; 3.3.9 Создание пользования для мониторинга узлов Для мониторинга узлов кластера из-под ProxySQL создадим на узлах кластера пользователя с привилегией USAGE (без привилегий) и добавим его в конфигурацию ProxySQL Для этого на любом из узлов кластера войдем в консоль MySQL: mysql -u root –p и выполним команды mysql@pxc2> CREATE USER 'proxysql'@'%' IDENTIFIED BY 'ProxySQLPa55'; mysql@pxc2> GRANT USAGE ON *.* TO 'proxysql'@'%'; Сконфигурируем пользователя в ProxySQL (на четвертом узле): mysql@proxysql> UPDATE global_variables SET variable_value='proxysql' WHERE variable_name='mysql-monitor_username'; mysql@proxysql> UPDATE global_variables SET variable_value='ProxySQLPa55' WHERE variable_name='mysql-monitor_password'; Скопируем конфигурацию в область runtime и сохраним ее на диск: mysql@proxysql> LOAD MYSQL VARIABLES TO RUNTIME; mysql@proxysql> SAVE MYSQL VARIABLES TO DISK; Удостоверимся, что мониторинг разрешен. Для этого посмотрим лог мониторинга: mysql@proxysql> SELECT * FROM monitor.mysql_server_connect_log ORDER BY time_start_us DESC LIMIT 6; +---------------+------+------------------+-------------------------+---------------+ | hostname | port | time_start_us | connect_success_time_us | connect_error | +---------------+------+------------------+-------------------------+---------------+ | 192.168.1.166 | 3306 | 1512496502928812 | 4204 | NULL | | 192.168.1.165 | 3306 | 1512496502892833 | 2252 | NULL | | 192.168.1.164 | 3306 | 1512496502882723 | 1989 | NULL | | 192.168.1.166 | 3306 | 1512496442902784 | 1094 | NULL | | 192.168.1.165 | 3306 | 1512496442892324 | 935 | NULL | | 192.168.1.164 | 3306 | 1512496442881973 | 1285 | NULL | +---------------+------+------------------+-------------------------+---------------+ 6 rows in set (0.00 sec) 49 mysql> SELECT * FROM monitor.mysql_server_ping_log ORDER BY time_start_us DESC LIMIT 6; +---------------+------+------------------+----------------------+------------+ | hostname | port | time_start_us | ping_success_time_us | ping_error | +---------------+------+------------------+----------------------+------------+ | 192.168.1.166 | 3306 | 1512496512961262 | 357 | NULL | | 192.168.1.165 | 3306 | 1512496512958252 | 428 | NULL | | 192.168.1.164 | 3306 | 1512496512955966 | 361 | NULL | | 192.168.1.166 | 3306 | 1512496502960807 | 351 | NULL | | 192.168.1.165 | 3306 | 1512496502957332 | 255 | NULL | | 192.168.1.164 | 3306 | 1512496502955450 | 395 | NULL | +---------------+------+------------------+----------------------+------------+ 6 rows in set (0.00 sec) Разрешим мониторинг узлов, загрузив их в runtime, и сохраним настройку узлов: mysql@proxysql> LOAD MYSQL SERVERS TO RUNTIME; mysql@proxysql> SAVE MYSQL SERVERS TO DISK; 3.3.10 Создание пользователя для доступа к узлам кластера ProxySQL должен иметь пользователей, через которых будет осуществляться доступ к узлам кластера. Добавим в таблицу mysql_users конфигурации ProxySQL логин/пароль пользователя: mysql@proxysql> INSERT INTO mysql_users (username,password) VALUES ('sbuser','sbpass'); Query OK, 1 row affected (0.00 sec) Загрузим пользователя в runtime область и сохраним изменения на диск: mysql@proxysql> LOAD MYSQL USERS TO RUNTIME; mysql@proxysql> SAVE MYSQL USERS TO DISK; Проверим, что пользователь создан корректно. Для этого выйдем из консоли MySQL: mysql@proxysql>exit и войдем в нее под вновь созданным пользователем (вход осуществляется в монитор, а не административный модуль, поэтому используется другой порт): mysql -u sbuser -psbpass -h 127 .0.0.1 -P 6033 Вернемся в консоль под администратором: mysql@proxysql>exit mysql -u admin -padmin -h 127 .0.0.1 -P 6032 Для того чтобы дать ProxySQL доступ к узлам кластера на чтение/запись, создадим этого же пользователя на кластере (любом из узлов) и дадим ему необходимые права: mysql@pxc3> CREATE USER 'sbuser'@'192.168.1.167' IDENTIFIED BY 'sbpass'; mysql@pxc3> GRANT ALL ON *.* TO 'sbuser'@'192.168.1.167'; 50 3.3.11 Конфигурирование поддержки Galera По умолчанию ProxySQL не может детектировать находится ли узел кластера в состоянии Synced. Для мониторинга статуса узлов Percona XtraDB Cluster используется скрипт proxysql_galera_checker (расположен в /usr/bin/proxysql_galera_checker). Для использования данного скрипта его необходимо загрузить в планировщик ProxySQL: mysql@proxysql> INSERT INTO scheduler(id,active,interval_ms,filename,arg1,arg2,arg3,arg4,arg5) VALUES (1,'1','10000','/usr/bin/proxysql_galera_checker','0','-1','0','1', '/var/lib/proxysql/proxysql_galera_checker.log'); Активируем настройки планировщика и сохраним их: mysql@proxysql> LOAD SCHEDULER TO RUNTIME; mysql@proxysql> SAVE SCHEDULER TO DISK; Удостоверимся, что скрипт загружен, проверив таблицу runtime_scheduler: mysql@proxysql> SELECT * FROM runtime_scheduler\G *************************** 1. row *************************** id: 1 active: 1 interval_ms: 10000 filename: /usr/bin/proxysql_galera_checker arg1: 0 arg2: -1 arg3: 0 arg4: 1 arg5: /var/lib/proxysql/proxysql_galera_checker.log comment: 1 row in set (0.00 sec) Проверим статус узлов кластера: mysql@proxysql> SELECT hostgroup_id,hostname,port,status FROM mysql_servers; +--------------+---------------+------+--------+ | hostgroup_id | hostname | port | status | +--------------+---------------+------+--------+ | 0 | 192.168.1.164 | 3306 | ONLINE | | 0 | 192.168.1.165 | 3306 | ONLINE | | 0 | 192.168.1.166 | 3306 | ONLINE | +--------------+---------------+------+--------+ 3 rows in set (0.00 sec) Узел может находиться в одном из следующих состояний: ONLINE: узел полностью функционален; SHUNNED: узел временно не используется, так как за короткое время произошло слишком много ошибок подключения, или отставание репликации превысило допустимый порог; OFFLINE_SOFT: новые входящие соединения не принимаются, в то время как существующие соединения сохраняются до тех пор, пока они не 51 станут неактивными. Другими словами, соединения сохраняются до завершения текущей транзакции. Это позволяет корректно отсоединить серверный узел; OFFLINE_HARD: существующие соединения обрываются, и новые входящие соединения не принимаются. Это эквивалентно удалению узла из группы узлов или временному извлечению узла из группы узлов для обслуживания. 3.3.12 Тестирование узла с помощью sysbench Установим sysbech на четвертом узле: sudo apt-get install sysbench На любом из узлов кластера создадим базу данных, которая будет использоваться для тестирования кластера: mysql@pxc1> CREATE DATABASE sbtest; Подготовим таблицу с данными для тестирования: sysbench --report-interval=5 --threads=4 --time=20 --mysql-user='sbuser' -- mysql-password='sbpass' --table_size=10000 --mysql-host=127.0.0.1 --mysql- port=6033 oltp_read_write prepare Запустим тест: sysbench --report-interval=5 --threads=4 --time=3 --mysql-user='sbuser' -- mysql-password='sbpass' --table_size=10000 --mysql-host=127.0.0.1 --mysql- port=6033 oltp_read_write run Собранную ProxySQL статистику можно осмотреть через схему stats (через административный монитор ProxySQL): mysql@proxysql> SHOW TABLES FROM stats; +-----------------------------------+ | tables | +-----------------------------------+ | global_variables | | stats_memory_metrics | | stats_mysql_commands_counters | | stats_mysql_connection_pool | | stats_mysql_connection_pool_reset | | stats_mysql_global | | stats_mysql_processlist | | stats_mysql_query_digest | | stats_mysql_query_digest_reset | | stats_mysql_query_rules | | stats_mysql_users | | stats_proxysql_servers_checksums | | stats_proxysql_servers_metrics | | stats_proxysql_servers_status | +-----------------------------------+ 14 rows in set (0.00 sec) Например, можно посмотреть статистику команд выполненных на кластере: mysql@proxysql> SELECT * FROM stats_mysql_commands_counters; 52 3.3.13 Автоматическое обнаружение отказов ProxySQL автоматически определяет, что узел не доступен или не синхронизирован с кластером. Состояние всех доступных узлов можно проверить, выполнив следующие действия: mysql@proxysql> SELECT hostgroup_id,hostname,port,status FROM mysql_servers; +--------------+---------------+------+--------+ | hostgroup_id | hostname | port | status | +--------------+---------------+------+--------+ | 0 | 192.168.1.164 | 3306 | ONLINE | | 0 | 192.168.1.165 | 3306 | ONLINE | | 0 | 192.168.1.166 | 3306 | ONLINE | +--------------+---------------+------+--------+ 3 rows in set (0.00 sec) Для проверки работы механизма обнаружения отказов, остановим узел 3: sudo service mysql stop ProxySQL обнаруживает, что узел 3 не работает и обновляет его статус на OFFLINE_SOFT: mysql@proxysql> SELECT hostgroup_id,hostname,port,status FROM mysql_servers; +--------------+---------------+------+--------------+ | hostgroup_id | hostname | port | status | +--------------+---------------+------+--------------+ | 0 | 192.168.1.164 | 3306 | ONLINE | | 0 | 192.168.1.165 | 3306 | ONLINE | | 0 | 192.168.1.166 | 3306 | OFFLINE_SOFT | +--------------+---------------+------+--------------+ 3 rows in set (0.00 sec) 3.4 Контрольные вопросы 1 Почему при построении кластера необходимо использовать синхронную репликацию? 2 Недостатки синхронной репликации? 3 В чем заключаются особенности реализации синхронной репликации в Percona XtraDB Cluster? 4 В чем заключается проблема split-brain? 5 Для чего используется голосование и кворум? 6 Назначение ProxySQL? 53 Дик Дмитрий Иванович ТЕХНОЛОГИЯ ПОСТРОЕНИЯ ЗАЩИЩЕННЫХ РАСПРЕДЕЛЕННЫХ ПРИЛОЖЕНИЙ Методические указания к выполнению лабораторных работ для студентов направлений 10.05.03 и 10.03.01 Редактор Н.Н. Погребняк Библиотечно-издательский центр КГУ. 640020, г. Курган, ул. Советская, 63/4. Курганский государственный университет. Подписано к печати 25.06.2018 Печать цифровая Заказ 118 Формат 60 84 1/16 Усл. печ. л. 3,25 Тираж 1 3 Бумага 65 г/м 2 Уч.–изд. л. 3,25 Не для продажи |