【20180523】ProxySQL+MHA的配置以及一些問題描述

ProxySQL+MHA的各自搭建在這裏再也不描述了。具體的搭建能夠自行谷歌，可是須要注意的是MHA在進行故障轉移的時候不須要作VIP切換操做便可。

環境配置信息

1. master: 172.16.3.5:3307
2. slave:
   • 172.16.3.6:3307
   • 172.16.3.7:3306
   • 172.16.3.6:3307
3. proxysql: 172.16.3.15

ProxySQL配置

1. 配置連接後端MySQL實例的用戶。這個用戶必定要真實存在，而且這個用戶會以rpl@172.16.3.15的身份去訪問後端的MySQL實例。

   admin@mysqldb 10:51:  [(none)]> select username,password,active,default_hostgroup from mysql_users;
   +----------+-------------+--------+-------------------+
   | username | password    | active | default_hostgroup |
   +----------+-------------+--------+-------------------+
   | rpl      | Redhat_2018 | 1      | 10                |
   +----------+-------------+--------+-------------------+
   1 row in set (0.01 sec)

   • active: 表示啓用這個用戶，這個用戶是活動用戶
   • default_hostgroup: 默認的MySQL組，如果在mysql_query_rules沒有匹配到，則全部的操做則會默認在default_hostgroup這個組中執行。
   • transaction_persistent: 同一個事務在同一個實例執行
2. 配置連接後端的MySQL實例。

   admin@mysqldb 11:48:  [(none)]> select  hostgroup_id,hostname,port,weight from  mysql_servers;
   +--------------+------------+------+--------+
   | hostgroup_id | hostname   | port | weight |
   +--------------+------------+------+--------+
   | 11           | 172.16.3.6 | 3307 | 100    |
   | 10           | 172.16.3.5 | 3307 | 100    |
   | 10           | 172.16.3.7 | 3307 | 100    |
   | 11           | 172.16.3.7 | 3306 | 100    |
   | 11           | 172.16.3.7 | 3307 | 100    |
   +--------------+------------+------+--------+
   5 rows in set (0.00 sec)

   • hostgroup_id: 根據組ID分紅不一樣類型的

3. 配置mysql_replication_hostgroups。主要目的是監控後端的MySQL實例是master仍是slave。

   admin@mysqldb 11:50:  [(none)]> select * from mysql_replication_hostgroups;
   +------------------+------------------+---------+
   | writer_hostgroup | reader_hostgroup | comment |
   +------------------+------------------+---------+
   | 10               | 11               |         |
   +------------------+------------------+---------+
   1 row in set (0.00 sec)

   • writer_hostgroup: 專門進行寫操做，會監控MySQL實例是否關閉了super_read_only和read_only。
   • reader_hostgroup: 專門進行讀操做，會監控MySQL實例是否開啓了super_read_only和read_only。
4. 配置mysql_query_rules，這個是重中之重。

   admin@mysqldb 14:28:  [(none)]> select rule_id,active,match_pattern,apply from mysql_query_rules;
   +---------+--------+-----------------------+-------+
   | rule_id | active | match_pattern         | apply |
   +---------+--------+-----------------------+-------+
   | 1       | 1      | ^SELECT .*FOR UPDATE$ | 1     |
   | 2       | 1      | ^SELECT               | 1     |
   +---------+--------+-----------------------+-------+
   2 rows in set (0.00 sec)
   admin@mysqldb 14:29:  [(none)]>

   • rule_id： 過濾規則的ID，通常都是從小往大進行匹配的，因此建議不要從1開始，最好是從中間的值開始，方便後續出現緊急狀況能夠插入在前面。
5. 配置監控用戶。這個用戶也必須真實存在，而且要有super,replication client的權限。

   set global mysql-monitor_username='username';
   set global mysql-monitor_password='new_password'

注意點

1. 路由規則越多，性能越差。
2. 經過ProxySQL連接後端的MySQL的時候，使用use schema切換數據庫的時候會花費比較長的時間。

   rpl@mysqldb 14:58:  [(none)]> use yeah
   Database changed
   rpl@mysqldb 14:58:  [yeah]> use zabbix

   • 在使用mysql登錄的時候加上參數-A，就是每次連接不會自動刷新table的緩存信息，就是不會將最新的table信息緩存在本地。
   • 遇到這種狀況前提就是在配置mysql_users表的時候插入的時候沒有指定默認的default_hostgroup，致使默認的default_hostgroup爲0，是information_schema，如果選擇了一個已經存在的hostgroup_id則不會出現這種狀況。
3. 在proxysql的表mysql_servers中插入server信息，將master的hostgroup_id設置爲10，slave的hostgroup_id設置爲11，可是發現hostgroup_id爲10這個分組出現了slave的信息。

   admin@mysqldb 15:02:  [(none)]> select * from mysql_servers;
   +--------------+------------+------+--------+--------+-------------+-----------------+---------------------+---------+----------------+---------+
   | hostgroup_id | hostname   | port | status | weight | compression | max_connections | max_replication_lag | use_ssl | max_latency_ms | comment |
   +--------------+------------+------+--------+--------+-------------+-----------------+---------------------+---------+----------------+---------+
   | 11           | 172.16.3.6 | 3307 | ONLINE | 100    | 0           | 1000            | 0                   | 0       | 0              | slave   |
   | 10           | 172.16.3.5 | 3307 | ONLINE | 100    | 0           | 1000            | 0                   | 0       | 0              | master  |
   | 10           | 172.16.3.7 | 3307 | ONLINE | 100    | 0           | 1000            | 0                   | 0       | 0              | slave   |
   | 11           | 172.16.3.7 | 3306 | ONLINE | 100    | 0           | 1000            | 0                   | 0       | 0              | slave   |
   | 11           | 172.16.3.7 | 3307 | ONLINE | 100    | 0           | 1000            | 0                   | 0       | 0              | slave   |
   +--------------+------------+------+--------+--------+-------------+-----------------+---------------------+---------+----------------+---------+
   5 rows in set (0.00 sec)
   admin@mysqldb 15:05:  [(none)]>

   能夠很明顯的看獲得在第三行172.16.3.7:3307這個實例出現了倆次，可是實際狀況是我只insert了1次，而且將其insert 到hostgroup_id爲11的組上面，可是實際狀況卻在10，11倆組分別出現了。

   • 這個是由於proxysql會主動去檢測後端的參數read_only和super_read_only，當發現這倆個參數是OFF的時候它會認爲這個MySQL實例是master，因此須要將這倆個參數開啓，在proxysql中就發現slave的信息不回出如今hostgroup_id爲10的分組裏面了。
4. 登錄以後發現沒法執行show tables,create table 之類的操做。

   rpl@mysqldb 15:19:  [yeah]> show tables;
   ERROR 9001 (HY000): Max connect timeout reached while reaching hostgroup 0 after 10000ms
   rpl@mysqldb 15:20:  [yeah]>

   • 主要是由於在表mysql_users插入用戶信息的時候沒有設置default_hostgroup,那麼在路由規則不匹配的時候它會默認去匹配hostgroup_id爲0，default_hostgroup爲information_schema。這個時候只須要將default_hostgroup設置爲10就能夠了。