文章轉載自：https://www.cnblogs.com/f-ck-need-u/p/9286922.html

配置後端節點前的說明

為了讓ProxySQL能夠找到後端的MySQL節點，需要將後端的MySQL Server加入到ProxySQL中。ProxySQL的一切配置行為都是在修改main庫中的對應的表，所以新增節點到ProxySQL中實際上也是通過修改相關表來實現的。

管理後端節點有幾個過程：

• 將後端MySQL Server的主從複製結構配置好。
• 將後端MySQL Server節點加入到ProxySQL中。相關的表為mysql_servers。
• 監控後端節點。相關的表是全域性變量表global_vairbles，相關的變數為mysql-monitor_開頭的變數。
• 配置讀、寫組。相關的表為mysql_replication_hostgroups。
• 配置MySQL使用者，用於傳送SQL語句。相關的表為mysql_users。

幾個注意點：

• (1).ProxySQL是通過監控後端節點的read_only值來自動調整節點所屬組的，例如read_only=1的節點會移動到讀組，read_only=0的節點會移動到寫組。所以，在配置讀、寫組之前，需要先監控後端節點。ProxySQL也支援手動管理後端節點，這種模式不會根據read_only的值自動調整，在後面的文章中會介紹這種模式。
• (2).對於傳統的主從複製，預設的read_only=0，所以在第一步中，各slave節點的配置檔案中需要加上read_only=1。對於組複製、Galera，因為會自動強制設定非寫節點的read_only=1，所以無需額外配置該屬性。
• (3).ProxySQL支援傳統主從複製結構(即非同步、半同步、gtid複製)的後端，讀、寫組相關的表是mysql_replication_hostgroups。還支援MySQL組複製結構的後端，相關的表是mysql_group_replication_hostgroups，還支援Galera(如percona XtraDB cluster)結構的後端，不過ProxySQL是通過scheduler排程proxysql_galera_checker.sh指令碼來支援Galera的，而且目前還沒有mysql_galera_hostgroups(ProxySQL 2.0才新增該表)。

本文暫時只解釋mysql_servers和mysql_replication_hostgroups，組複製相關的表在在後面介紹"ProxySQL+組複製"的文章中再介紹。

完成了上面的過程後，節點就一切正常了，然後就可以去配置ProxySQL的路由規則、查詢快取、SQL語句重寫等功能。這些在後面的文章會詳細介紹。

新增新節點：mysql_servers表

假如後端有3個節點，使用的是傳統的非同步複製(1 master, 2 slave)。這3個節點的IP地址為：

192.168.100.22
192.168.100.23
192.168.100.24

要加入3個後端MySQL節點，只需向mysql_servers表插入3行對應的記錄即可。以下是使用了一大堆預設值的insert語句：

insert into mysql_servers(hostgroup_id,hostname,port) 
values(10,'192.168.100.22',3306);

insert into mysql_servers(hostgroup_id,hostname,port) 
values(10,'192.168.100.23',3306);

insert into mysql_servers(hostgroup_id,hostname,port) 
values(10,'192.168.100.24',3306);

load mysql servers to runtime;
save mysql servers to disk;

上面的insert語句表示將後端MySQL節點192.168.100.xx:3306加入到hostgroup_id=10的組中。

其實mysql_servers表有很多欄位，很多欄位都有預設值，正如上面的insert語句，除了3個欄位，其它使用的全是欄位的預設值。

以下是mysql_servers表的欄位屬性。

|       欄位          | 資料型別  | 允許null  | 預設值 |
|---------------------|----------|-----------|--------|
| hostgroup_id  (pk)  | int      | not null  | 0      |
| hostname      (pk)  | varchar  | not null  | 無     |
| port          (pk)  | int      | not null  | 3306   |
| status              | varchar  | not null  | online |
| weight              | int      | not null  | 1      |
| compression         | int      | not null  | 0      |
| max_connections     | int      | not null  | 1000   |
| max_replication_lag | int      | not null  | 0      |
| use_ssl             | int      | not null  | 0      |
| max_latency_ms      | int      | not null  | 0      |
| comment             | varchar  | not null  | ''     |

可見，新新增一個節點時，唯一必須指定的欄位就是hostname值。如果不指定hostgroup_id，那麼節點將自動加入到hostgroup_id=0的組中。

各欄位的意義如下：

• hostgroup_id：該後端MySQL例項所在的主機組。注意，同一MySQL節點可屬於多個主機組。
• hostname,port：後端MySQL監聽的地址和埠。就是預設3306埠的意義
• status：
  • ONLINE：該後端MySQL節點完全正常。
  • SHUNNED：該後端MySQL節點將暫時被ProxySQL自動避開(忽略)，原因可能是一個較短時間內發生了大量連線錯誤，也可能是該slave與master的資料延遲太大(replication lag)。
  • OFFLINE_SOFT：當某後端MySQL被設定為 OFFLINE_SOFT 時，ProxySQL將不會向它傳送新的請求，但該節點正在執行的事務會繼續執行，直到所有事務執行完畢後會進入非啟用狀態。也就是說，和該後端的連線會保持到事務執行完畢。這可以實現後端節點的graceful停止、重啟。
  • OFFLINE_HARD：當某後端MySQL被設定為 OFFLINE_HARD 時，ProxySQL將不會向它傳送新的請求，該節點正在執行的事務也會立即中斷。也就是直接將該後端殺掉。等價於刪除該節點，或臨時將其移除出組(例如出於維護的目的)。
• weight：節點在組中的權重值越高，ProxySQL會發送越多請求給它們。
• compression：如果該欄位的值設定為大於0，ProxySQL和該後端新建的連線中，ProxySQL將會先壓縮資料再傳輸。
• max_connections：和該後端允許建立的最大連線數。當達到最大數量時，即使該後端的權重很大，也不會和它新建連線。預設值為1000，表示每個後端最多能同時接受1000個連線。請確保該後端的max_connections值是合理的，以避免MySQL超負荷時ProxySQL繼續向其傳送請求。
• max_replication_lag：如果值大於0，ProxySQL的Monitor模組將會定期檢查該slave的複製是否延後於master，如果延遲的值大於該欄位的值，ProxySQL將會暫時避開該節點，直到該slave趕上master。
• use_ssl：如果設定為1，則和該後端MySQL建立SSL連線。
• max_latency_ms：Monitory模組定期向該後端發起ping檢查，如果該節點的ping時間大於該欄位的值，則將其排除在連線池之外(儘管該節點仍處於ONLINE狀態)。
• comment：該表的說明資訊，可隨便定義。

以下是上面插入資料成功後的結果：

admin> select * from mysql_servers\G
*************************** 1. row ***************************
       hostgroup_id: 10
           hostname: 192.168.100.22
               port: 3306
             status: ONLINE
             weight: 1
        compression: 0
    max_connections: 1000
max_replication_lag: 0
            use_ssl: 0
     max_latency_ms: 0
            comment: 
*************************** 2. row ***************************
       hostgroup_id: 10
           hostname: 192.168.100.23
               port: 3306
             status: ONLINE
             weight: 1
        compression: 0
    max_connections: 1000
max_replication_lag: 0
            use_ssl: 0
     max_latency_ms: 0
            comment: 
*************************** 3. row ***************************
       hostgroup_id: 10
           hostname: 192.168.100.24
               port: 3306
             status: ONLINE
             weight: 1
        compression: 0
    max_connections: 1000
max_replication_lag: 0
            use_ssl: 0
     max_latency_ms: 0
            comment: 

需要注意的是，同一個節點是可以同時存在於多個組中的。最典型的情形是master既充當寫節點，也充當讀節點，這時它就同時存在於寫組和讀組。

監控後端節點

ProxySQL通過Monitor模組監控後端MySQL Server的read_only值來自動調整節點所屬的組。所以，在配置讀、寫組之前，必須先配置好監控。

3.1 Monitor模組可以監控什麼東西

首先看下Monitor庫中的表：

admin> show tables from monitor;
+------------------------------------+
| tables                             |
+------------------------------------+
| mysql_server_connect_log           |
| mysql_server_group_replication_log |
| mysql_server_ping_log              |
| mysql_server_read_only_log         |
| mysql_server_replication_lag_log   |
+------------------------------------+

Monitor監控4種指標：connect、ping、read_only和replication lag。下面稍作介紹。

1.connect監控

ProxySQL連線到各後端是否成功，成功/失敗的連線將記錄到表mysql_server_connect_log中。

2.ping監控

這是一種心跳檢測。Monitor模組向所有後端MySQL節點發起ping檢查，ping成功/失敗的情況將記錄到表mysql_server_ping_log中。當ping某後端的失敗次數達到了mysql-monitor_ping_max_failures時表示失去心跳，將傳送一個訊號給MySQL的主機組管理器來殺掉和該後端節點的所有連線。

請和connect監控區分開，connect監控是通過建立連線來檢測和後端節點連線的連通性。ping監控是心跳檢測，ProxySQL通過MySQL的一個ping API傳送給後端MySQL服務上，然後等待ping回覆，雖然是ping檢測，但也是需要建立連線的。

所以，有兩個確定連線不可用公式：

• mysql-monitor_ping_max_failures * mysql-monitor_connect_timeout
• mysql-monitor_ping_max_failures * mysql-monitor_ping_timeout

3.read_only監控

檢查mysql_replication_hostgroups表中所有節點的read_only值，並記錄到mysql_server_read_only_log。如果read_only=1，表示只讀，是一個slave，這樣的節點將會自動移入reader_hostgroup中，如果read_only=0，表示可寫，可能是master，這樣的節點將會自動移入writer_hostgroup中。

4.replication lag監控

對mysql_servers表中所有配置了max_replication_lag的後端slave節點都檢查複製延遲，通過show slave status返回結果中的Seconds_Behind_Master欄位，判斷slave和master之間的延遲程度，並記錄到mysql_server_replication_lag_log表中。

如果Seconds_Behind_Master > max_replication_lag，表示該slave延遲很嚴重，ProxySQL會自動避開這種slave節點，直到Seconds_Behind_Master < max_replication_lag。

Monitor監控上述指標時，會使用MySQL節點上的使用者連線到後端節點，所以，需要先在後端節點上建立負責監控的使用者。監控connect、ping和read_only這3項指標時，該使用者只需具有USAGE許可權，如果要監控replication lag指標，則需要replication client許可權。

3.2 配置connect和ping監控

首先，在後端節點上建立用於監控的使用者，順便為其授予replication client許可權。只需在一個寫節點(例如master)上建立即可，它會複製到其它節點上。

create user monitor@'192.168.100.%' identified by 'P@ssword1!';
grant replication client on *.* to monitor@'192.168.100.%';

然後，在ProxySQL上配置這個監控使用者，配置方式是修改全域性變數。

set mysql-monitor_username='monitor';
set mysql-monitor_password='P@ssword1!';

由於ProxySQL上所有的配置修改都是在修改main庫中對應的表，上面的變數在main.global_variables中，所以上面兩個set語句和下面兩個update語句是等價的。

update global_variables set variable_value='monitor'
 where variable_name='mysql-monitor_username';

update global_variables set variable_value='P@ssword1!'
 where variable_name='mysql-monitor_password';

在將配置load到runtime之前，可以先檢視下connect和ping對應的log表。

admin> select * from mysql_server_connect_log;
+----------------+------+------------------+-------------------------+---------------+
| hostname       | port | time_start_us    | connect_success_time_us | connect_error |
+----------------+------+------------------+-------------------------+---------------+
| 192.168.100.22 | 3306 | 1530968712977867 | 4174                    | NULL          |
| 192.168.100.23 | 3306 | 1530968712988986 | 4908                    | NULL          |
| 192.168.100.24 | 3306 | 1530968713000074 | 3044                    | NULL          |
| 192.168.100.22 | 3306 | 1530968772978982 | 3407                    | NULL          |
| 192.168.100.23 | 3306 | 1530968772989627 | 3404                    | NULL          |
| 192.168.100.24 | 3306 | 1530968773000778 | 3444                    | NULL          |
+----------------+------+------------------+-------------------------+---------------+

admin> select * from mysql_server_ping_log;
+----------------+------+------------------+----------------------+-------------+
| hostname       | port | time_start_us    | ping_success_time_us | ping_error  |
+----------------+------+------------------+----------------------+-------------+
| 192.168.100.22 | 3306 | 1530968712666540 | 452                  | NULL        |
| 192.168.100.23 | 3306 | 1530968712668779 | 458                  | NULL        |
| 192.168.100.24 | 3306 | 1530968712671541 | 324                  | NULL        |
| 192.168.100.22 | 3306 | 1530968722667071 | 1190                 | NULL        |
| 192.168.100.23 | 3306 | 1530968722669574 | 1162                 | NULL        |
| 192.168.100.24 | 3306 | 1530968722673162 | 1380                 | NULL        |
+----------------+------+------------------+----------------------+-------------+

不難發現，監控操作在load到runtime之前就已經生效了。這是有意為之的：通過這種方式，可以在節點新增到生產環境之前執行一些基本的健康檢查。

監控的節點一切正常後(error=NULL)，將配置load到runtime。

load mysql variables to runtime;
save mysql variables to disk;

3.3 配置read_only監控和讀/寫組

目前read_only和replication_lag的監控日誌還是空。

admin> select * from mysql_server_read_only_log;
Empty set (0.00 sec)

admin> select * from mysql_server_replication_lag_log;
Empty set (0.00 sec)

這是因為還沒有對ProxySQL中的節點分組：writer_hostgroup、reader_hostgroup。

設定分組資訊，需要修改的是main庫中的mysql_replication_hostgroups表(組複製則是mysql_group_replication_hostgroups)，該表只有3個欄位：第一個欄位名為writer_hostgroup，第二個欄位為reader_hostgroup，第三個欄位為註釋欄位，可隨意寫。

例如，指定寫組的id為10，讀組的id為20。

insert into mysql_replication_hostgroups values(10,20);

admin> select * from mysql_replication_hostgroups;
+------------------+------------------+----------+
| writer_hostgroup | reader_hostgroup | comment  |
+------------------+------------------+----------+
| 10               | 20               | cluster1 |
+------------------+------------------+----------+

在該配置載入到RUNTIME生效之前，先檢視下各mysql server所在的組。

admin> select hostgroup_id,hostname,port,status,weight from mysql_servers; 
+--------------+----------------+------+--------+--------+
| hostgroup_id | hostname       | port | status | weight |
+--------------+----------------+------+--------+--------+
| 10           | 192.168.100.22 | 3306 | ONLINE | 1      |
| 10           | 192.168.100.23 | 3306 | ONLINE | 1      |
| 10           | 192.168.100.24 | 3306 | ONLINE | 1      |
+--------------+----------------+------+--------+--------+

3個節點都在hostgroup_id=10的組中。

現在，將剛才mysql_replication_hostgroups表的修改載入到RUNTIME生效。

load mysql servers to runtime;
save mysql servers to disk;

一載入，Monitor模組就會開始監控後端的read_only值，當監控到read_only值後，就會按照read_only的值將某些節點自動移動到讀/寫組。

例如，此處所有節點都在id=10的寫組，slave1和slave2都是slave，它們的read_only=1，這兩個節點將會移動到id=20的組。如果一開始這3節點都在id=20的讀組，那麼移動的將是Master節點，會移動到id=10的寫組。

看結果：

admin> select hostgroup_id,hostname,port,status,weight from mysql_servers;
+--------------+----------------+------+--------+--------+
| hostgroup_id | hostname       | port | status | weight |
+--------------+----------------+------+--------+--------+
| 10           | 192.168.100.22 | 3306 | ONLINE | 1      |
| 20           | 192.168.100.23 | 3306 | ONLINE | 1      |
| 20           | 192.168.100.24 | 3306 | ONLINE | 1      |
+--------------+----------------+------+--------+--------+

配置好read_only的監控後，Monitor模組會每隔一段時間監控一次read_only值。

admin> select * from mysql_server_read_only_log;
+----------------+------+------------------+-----------------+-----------+--------+
| hostname       | port | time_start_us    | success_time_us | read_only | error  |
+----------------+------+------------------+-----------------+-----------+--------+
| 192.168.100.22 | 3306 | 1530970372197917 | 8487            | 0         | NULL   |
| 192.168.100.23 | 3306 | 1530970372198992 | 7907            | 1         | NULL   |
| 192.168.100.24 | 3306 | 1530970372199835 | 8064            | 1         | NULL   |
| 192.168.100.22 | 3306 | 1530970373698824 | 10078           | 0         | NULL   |
| 192.168.100.23 | 3306 | 1530970373699825 | 9845            | 1         | NULL   |
| 192.168.100.24 | 3306 | 1530970373700786 | 10745           | 1         | NULL   |
+----------------+------+------------------+-----------------+-----------+--------+

3.4 配置replication lag監控

Monitor模組會監控後端主機組中各slave的資料是否延遲於master，這個延遲行為稱為replication lag，俗稱拖後腿。

如果某個slave節點上的資料比master落後很多(臨界值見下文)，表示這個slave節點處理速度慢，資料較舊。ProxySQL採用一種稱為自動避開(automatic shunned)的方式，臨時避開這個落後的節點。當ProxySQL避開某節點後，ProxySQL不會把SQL語句路由給這個節點。

ProxySQL有幾種情況可能會觸發自動避開節點的行為：

• 和後端的連線斷開。
• slave落後於master過多。
• 和後端建立連線時，錯誤次數過多。
• second_behind_master=null時，即slave的SQL執行緒未執行，或者slave未連線到master。(不過這種自動避開的情況是可控的，見全域性變數mysql-monitor_slave_lag_when_null

本文介紹關於replication lag的內容。

Monitor模組會每隔一段時間(mysql-monitor_replication_lag_interval)去檢查一次拖後腿情況，檢測的方式是獲取show slave status中的Seconds_Behind_Master欄位值，然後和mysql_servers表中max_replication_lag欄位的值比較：

• Seconds_Behind_Master < max_replication_lag：表示落後程度尚在允許範圍內。
• Seconds_Behind_Master > max_replication_lag：表示落後太多，這樣的節點應該避開。

只有傳統複製結構的slave節點才需要設定max_replication_lag欄位，master無需設定，組複製和galera也無需設定，因為這兩種複製結構中show slave status的結果為空。例如，將讀組中的所有節點都設定最多落後於master 10秒鐘。

update mysql_servers set max_replication_lag=10 where hostgroup_id=20;
load mysql servers to runtime;
save mysql servers to disk;

需要注意的是，Seconds_Behind_Master的值並不總是可靠的，見 https://dev.mysql.com/doc/refman/5.7/en/show-slave-status.html 。

關於主機組和read_only

前面為了將主機組分為讀組和寫組，特地開啟了monitor模組的read_only監控功能，根據read_only的值以及mysql_replication_hostgroup表中定義的讀、寫組自動調整節點。

在簡單的環境下，這沒什麼問題。但是想要實現複雜一點的讀、寫分離，比如寫操作路由到hostgroup_id=10的組，讀操作分多種情況路由，select1語句路由到hostgroup_id=20的讀組，select2語句路由到hostgroup_id=30的組，...。這種情況，想通過monitor模組和mysql_replication_hostgroup表來實現是不可能的，因為mysql_replication_hostgroup表的writer_hostgroup欄位是主鍵，reader_hostgroup欄位具有唯一性，它們都是int型別，且不可重複。

admin> show create table main.mysql_replication_hostgroups\G
*************************** 1. row ***************************
       table: mysql_replication_hostgroups
Create Table: CREATE TABLE mysql_replication_hostgroups (
    writer_hostgroup INT CHECK (writer_hostgroup>=0) NOT NULL PRIMARY KEY,
    reader_hostgroup INT NOT NULL CHECK (reader_hostgroup<>writer_hostgroup AND reader_hostgroup>0),
    comment VARCHAR NOT NULL DEFAULT '', UNIQUE (reader_hostgroup))
1 row in set (0.00 sec)

換句話說，每一個寫組只能且必須對應單個讀組(經測試，reader_hostgroup欄位可以為空)，無法實現hg_id=10是寫組，而hg_id=20、hg_id=30同時作為讀組。

顯然ProxySQL不可能限制的這麼死。實際上，完全可以不用定義mysql_replication_hostgroup表，也不用定義monitor模組的read_only監控(如果沒有定義mysql_replication_hostgroup，read_only監控會自動停止)，這時只能人為控制不要把寫操作路由到後端的slave上。

例如：

delete from mysql_replication_hostgroup;
delete from mysql_servers;

insert into mysql_servers(hostgroup_id,hostname,port) 
values(10,'192.168.100.22',3306),
      (20,'192.168.100.23',3306),
      (30,'192.168.100.24',3306);

load mysql servers to runtime;
save mysql servers to disk;

事實上，在實現ProxySQL複雜、高階的路由功能時，都不會通過monitor模組去自動控制讀、寫組。

向ProxySQL新增MySQL使用者：mysql_users表

配置好後端MySQL節點、監控、分組後，接下來要配置的是MySQL的使用者。

需要注意，ProxySQL中有3套使用者：
1.連線Admin管理介面(預設6032埠)使用一套使用者名稱/密碼。

• 分為管理員和普通使用者，管理員使用者具有寫許可權，能配置ProxySQL，普通使用者只有幾個庫的讀許可權。
• 管理員使用者/密碼通過變數admin-admin_credentials設定，普通使用者/密碼通過變數admin-stats_credentials設定。
• 這部分使用者名稱不能出現在mysql_users表中。

2.Monitor模組監控後端時，需要使用一個MySQL使用者連線後端進行監控。

• 需要先在後端MySQL組中建立好這個使用者監控的使用者。
• 監控connect、ping和read_only時，只需USAGE許可權，監控replication lag時需要replication client許可權。
• 通過變數mysql-monitor_username和mysql-monitor_password將監控使用者加入到ProxySQL中。

3.前端連線ProxySQL(預設6033埠)、ProxySQL連線後端MySQL時使用一套使用者名稱/密碼。

• 當前端app傳送SQL請求時，需要使用這套使用者。然後ProxySQL將SQL語句路由給某後端節點，需要使用同一個使用者和後端建立連線並將SQL語句傳送出去。
• 需要現在後端MySQL組中建立好這套使用者，因為ProxySQL需要連線後端，所以一般授權所有許可權，例如root。
• 通過mysql_users表將這些使用者加入到ProxySQL中，每一行對應一個使用者。

5.1 新增MySQL users到ProxySQL

例如，使用root使用者來處理SQL請求。先在後端的寫節點(如master節點)上授權root，該操作會複製給其它節點。

grant all on *.* to root@'192.168.100.%' identified by 'P@ssword1!';

然後，向ProxySQL的mysql_users插入這個使用者即可。這個表的欄位很多，大多數字段都有預設值，以下是大部分使用預設值的插入語句：

insert into mysql_users(username,password,default_hostgroup) 
values ('root','P@ssword1!',10);

load mysql users to runtime;
save mysql users to disk;

上面指定了root使用者的使用者名稱、密碼以及該使用者預設的路由目標組。

ProxySQL有多種粒度的路由規則，每個使用者都有預設的路由目標組，當使用該使用者傳送的SQL語句沒有能夠匹配的語句級路由規則，則會將該SQL語句路由給該使用者預設的路由目標組。

例如，navicat工具使用root使用者連線到了ProxySQL，傳送了一個select語句，如果沒有配置select語句的路由規則，那麼這個select語句將預設路由給root使用者的預設組。

下面先介紹一下mysql_users表中的密碼相關內容，然後再詳細介紹mysql_users表。

5.2 mysql_users表中使用者的密碼管理

ProxySQL向mysql_users表新增使用者時，支援明文密碼和hash加密密碼。這個hash密碼和mysql的password()的演算法是一樣的。

但是，ProxySQL內部使用的是SQLite3引擎，不支援password()。所以，想要向ProxySQL中使用hash加密密碼，可以先通過mysql的password()函式建立一個hash密碼，然後copy到mysql_users表中。

例如：

[root@s4 ~]#  mysql -uroot -pP@ssword1! -e 'select password("P@ssword1!");' 
mysql: [Warning] Using a password on the command line interface can be insecure.
+-------------------------------------------+
| password("P@ssword1!")                    |
+-------------------------------------------+
| *50572A5FABC7DA9CEE5EB5977EDDE59E38967422 |
+-------------------------------------------+

然後插入到ProxySQL的mysql_users表：

insert into mysql_users(username,password,default_hostgroup) 
values ('root','*50572A5FABC7DA9CEE5EB5977EDDE59E38967422',10);

ProxySQL和MySQL對密碼的處理方式都是：以"*"開頭的密碼，表示是hash加密密碼。

在MySQL和ProxySQL中，使用SHA1(SHA1('clear_password'))對clear_password進行加密。無法根據加密的hash密碼推導回原始的明文密碼。

當客戶端連線到ProxySQL時，ProxySQL將使用該加密的密碼對使用者進行認證。如果該客戶端是第一次認證，則ProxySQL會推匯出一部分的hash密碼SHA1('clear_password')。推匯出的資訊會儲存到runtime的內部資料結構中，以便ProxySQL連線後端MySQL時使用。

從1.2.3版本開始，引入了一個布林型別的全域性變數admin-hash_passwords，預設為true。該變量表示，記憶體資料庫的mysql_users表中的明文密碼，在load mysql users to runtime時，對明文密碼進行hash加密，並儲存到runtime資料結構中。有了這個特性，可以以另一種方式儲存加密密碼：只需將其刷回記憶體資料庫即可。

例如：

Admin> SELECT username,password FROM mysql_users;
+----------+-----------+
| username | password  |
+----------+-----------+
| user1    | password1 |     # 明文密碼
| user2    | password2 |
+----------+-----------+

Admin> LOAD MYSQL USERS TO RUNTIME;    # 載入到runtime資料結構

Admin> SELECT username,password FROM mysql_users;
+----------+-----------+
| username | password  |
+----------+-----------+
| user1    | password1 |    # 還是明文密碼
| user2    | password2 |
+----------+-----------+

這個時候，runtime資料結構中的密碼是加密密碼，而記憶體資料庫中的密碼是明文密碼。

將runtime資料結構資料刷回記憶體資料庫，即可將加密密碼儲存到記憶體資料庫中，然後還可以將加密的密碼持久化到disk。

Admin> save mysql users to memory;

Admin> SELECT username,password FROM mysql_users;
+----------+-------------------------------------------+
| username | password                                  |
+----------+-------------------------------------------+
| user1    | *668425423DB5193AF921380129F465A6425216D0 |
| user2    | *DC52755F3C09F5923046BD42AFA76BD1D80DF2E9 |
+----------+-------------------------------------------+

Admin> save mysql users to disk;

唯一需要注意的是，admin-hash-passwords變數是admin-變數而非mysql-變數，這意味著修改了這個變數後(雖然基本不會去修改)，load/save操作的目標是"admin variables"，而非"mysql variables"。

load admin variables to runtime;
save admin variables to disk;

5.3 mysql_users表詳細解釋

以下是mysql_users表的屬性。

|     欄位名             | 資料型別 | 可為空?  | 預設值 |
|-----------------------|---------|----------|-------|
|username    (pk,uk)    | VARCHAR | NOT NULL |       |
|password               | VARCHAR | NULL     |       |
|active                 | INT     | NOT NULL | 1     |
|use_ssl                | INT     | NOT NULL | 0     |
|default_hostgroup      | INT     | NOT NULL | 0     |
|default_schema         | VARCHAR | NULL     |       |
|schema_locked          | INT     | NOT NULL | 0     |
|transaction_persistent | INT     | NOT NULL | 1     |
|fast_forward           | INT     | NOT NULL | 0     |
|backend      (pk)      | INT     | NOT NULL | 1     |
|frontend     (uk)      | INT     | NOT NULL | 1     |
|max_connections        | INT     | NOT NULL | 10000 |

• username, password：前端連線到ProxySQL以及ProxySQL連線到後端時使用的使用者憑據。
• active：active=0的使用者會保留在庫中，但不會載入到runtime資料結構中，只有active=1使用者才是有效使用者。該欄位預設值為1。
• default_hostgroup：如果該使用者傳送的查詢語句無法匹配任何規則，則該查詢會路由到該欄位指定的預設組中。
• default_schema：建立連線時預設將切換到該schema。
• schema_locked：目前還不支援該功能。
• transaction_persistent：如果正在和ProxySQL建立連線的客戶端使用的使用者設定了該欄位，那麼當該使用者開啟一個事務後，該客戶端後續的請求都將路由到同一主機組中(無視查詢規則)，使得事務在這個組中是持久的，避免同一事務分散到其它組，直到事務結束才可能會路由到其它主機組。注意，有些老版本中，這個欄位預設值為0，強烈建議修改為1。
• fast_forward：如果設定了該欄位，ProxySQL將繞過查詢處理層(重寫語句、快取)，直接將原請求語句轉發給後端節點。
• frontend：如果設定為1，前端將可以使用該使用者(username,password)連線到ProxySQL。
• backend：如果設定為1，ProxySQL將可以使用該使用者(username,password)連線到後端節點。
• max_connections：使用該使用者"建立到ProxySQL的連線"的最大數量。預設值為10000，所以每個使用者最多和ProxySQL建立10000個連線。注意，這是前端到ProxySQL的連線限制，ProxySQL和某個後端節點的最大連線數量是通過mysql_servers中的max_connections欄位控制的。

注意，當前版本的ProxySQL要求所有的使用者均設定frontend和backend為1(即所有使用者都可以進行frontend --> ProxySQL以及ProxySQL --> backend的連線認證)。將來版本中，ProxySQL將分離這兩部分連線的使用者憑據。這樣前端將永遠不知道後端的使用者憑據，它們只能通過中間的ProxySQL傳送請求，無法直接和後端節點建立連線，從而提高安全性。

關於快速轉發fast_forward：

• 不要求用一個不同的埠：正常的ProxySQL邏輯和"fast forward"的邏輯使用的是完全相同的程式碼/模組。
• fast forward是基於每使用者的：根據連線到ProxySQL使用者的設定，決定該使用者是否啟用、禁用fast forward功能。
• fast forward演算法的啟用是在使用者認證之後：ProxySQL仍然需要先對客戶端使用的使用者進行認證，儘管客戶端的請求會直接原樣轉發給後端，但ProxySQL仍然會和前端先建立好連線。這意味著，如果前端和ProxySQL的連線發生錯誤，也會被處理。
• fast forward不支援SSL連線。
• 如果使用壓縮功能，必須在兩端都啟用壓縮。

5.4 事務持久化：transaction_persistent

mysql_users表中的transaction_persistent欄位，當它的值為1時，表示事務持久化：當某連線使用該使用者開啟了一個事務後，那麼在事務提交/回滾之前，所有的語句都路由到同一個組中，避免語句分散到不同組。在以前的版本中，預設值為0，不知道從哪個版本開始，它的預設值為1。我們期望的值為1，所以強烈建議插入使用者後先檢查下這個欄位的值是否為1，如果為0，則執行下面的語句修改為1。

update mysql_users set transaction_persistent=1 where username='root';
update mysql_users set transaction_persistent=1 where username='sqlsender';
load mysql users to runtime;
save mysql users to disk;

總結

新增後端節點、監控後端節點、新增MySQL使用者是使用ProxySQL所必須完成的步驟。這3個步驟雖然需要操作的過程不多，但是涉及的內容還是比較多的。

強烈建議將mysql_servers、mysql_users、mysql_replication_hostgroups這3個表的所有欄位都瞭解一遍。不僅如此，要熟練使用ProxySQL，還應該對main庫中的表的各個欄位都比較熟悉，至少要知道它們什麼意思。

下面，將新增後端節點、監控後端節點、新增MySQL使用者的操作過程抽取出來，算是個步驟總結：
各欄位的意義：

######### 1.新增後端節點
#
#
insert into mysql_servers(hostgroup_id,hostname,port) values
    (10,'192.168.100.22',3306),
    (10,'192.168.100.23',3306),
    (10,'192.168.100.24',3306);

load mysql servers to runtime;
save mysql servers to disk;

# 檢視下各節點是否都是 ONLINE 
select * from mysql_servers\G


######### 2.在後端MySQL上建立監控使用者和處理SQL語句的使用者
#
# 在後端master節點上執行以下語句
#
create user monitor@'192.168.100.%' identified by 'P@ssword1!';
grant replication client on *.* to monitor@'192.168.100.%';
grant all on *.* to root@'192.168.100.%' identified by 'P@ssword1!';


######### 3.在ProxySQL中配置監控使用者
#
#
set mysql-monitor_username='monitor';
set mysql-monitor_password='P@ssword1!';

# 以上兩個set語句等價於下面兩個update：
update global_variables set variable_value='monitor'
 where variable_name='mysql-monitor_username';

update global_variables set variable_value='P@ssword1!'
 where variable_name='mysql-monitor_password';

load mysql variables to runtime;
save mysql variables to disk;

# 檢視下connect和ping的監控是否正常
select * from mysql_server_connect_log order by time_start_us desc limit 6;
select * from mysql_server_ping_log order by time_start_us desc limit 6;


######### 4.配置讀、寫組
#
#
insert into mysql_replication_hostgroups values(10,20);
load mysql servers to runtime;
save mysql servers to disk;


######### 5.在ProxySQL中配置MySQL使用者
#
#
insert into mysql_users(username,password,default_hostgroup) 
values ('root','P@ssword1!',10);
load mysql users to runtime;
save mysql users to memory;
save mysql users to disk;

update mysql_users set transaction_persistent=1 where username='root';
load mysql users to runtime;
save mysql users to disk;

在後面的文章中，我會介紹以下percona版本的ProxySQL，percona ProxySQL提供了一個管理工具，它能通過額外的配置檔案自動化配置上面一大堆的操作，大大簡化了初始搭建使用ProxySQL的過程。