MySQL-ProxySQL中間件（一）| ProxySQL基本概念

目錄

     MySQL-ProxySQL中間件（一）| ProxySQL基本概念：　http://www.javashuo.com/article/p-fnplpdym-k.html

    MySQL-ProxySQL中間件（二）| Admin Schemas介紹：http://www.javashuo.com/article/p-wuxjnuam-e.html

ProxySQL

    ProxySQL做爲一款強大的中間件爲MySQL的架構提供了有力的支持。

    目前能夠很好的支持 Master Slave\ MGR \ PXC等，並提供鏈接池、讀寫分離、日誌記錄等功能，固然還有不少其餘實用功能，這裏不一一列舉了。

    本文都是基礎概念，基本出自官方文檔，官方已經解釋的很是清晰，我就不太多加工，彙總一些實用的分享給你們。

 

安裝

    ProxySQL安裝很是簡單

    

 

鏈接ProxySQL

    ProxySQL默認管理端口6032，默認須要127.0.0.1來進入，進入方式和鏈接MySQL方式一致： 

    

ProxySQL 運行機制

RUNTIME

    RUNTIME表示處理請求的線程使用的ProxySQL的內存數據結構。

    runtime variables 包含了：

        1.    Global variables的實際值

        2.    將後端的服務器列表分組到hostgroup中。

        3.    讓MySQL 的User們能夠鏈接proxysql

注意：runntime層數據，誰都不能直接修改，必須經過下一層來提交修改。

MEMORY

    MEMORY（有時也稱爲main）表示經過MySQL兼容接口公開的內存數據庫。 用戶能夠將MySQL客戶端鏈接到此接口，並查詢各類ProxySQL配置表/數據庫。   

    經過此接口可用的配置表是：

mysql_servers - ProxySQL鏈接到的後端服務器列表

mysql_users - 鏈接到ProxySQL的用戶及其憑據列表。 請注意，ProxySQL也將使用相同的憑據鏈接到後端服務器！

mysql_query_rules - 將流量路由到各類後端服務器時評估的查詢規則列表。 這些規則還能夠重寫查詢，甚至能夠緩存已執行查詢的結果。

global_variables - 代理配置使用的全局變量列表，可在運行時調整。

DISK 和 CONFIG FILE

    DISK表示磁盤上的SQLite3數據庫，默認位置爲$（DATADIR）/proxysql.db。 在從新啓動時，未保留的內存中配置將丟失。 所以，將配置保留在DISK中很是重要。   

    

啓動過程

    若是找到數據庫文件（proxysql.db），ProxySQL將從proxysql.db初始化其內存中配置。 所以，磁盤被加載到MEMORY中，而後加載到RUNTIME中。 

    若是找不到數據庫文件（proxysql.db）且存在配置文件（proxysql.cfg），則解析配置文件並將其內容加載到內存數據庫中，而後將其保存在proxysql.db中並在加載到RUNTIME。 

    請務必注意，若是找到proxysql.db，則不會解析配置文件。 也就是說，在正常啓動期間，ProxySQL僅從持久存儲的磁盤數據庫初始化其內存配置。

    配置文件有4個變量，即便存在proxysql.db，也始終會從配置文件裏去解析：

        1.    datadir：

               定義了ProxySQL datadir的路徑，其中存儲了數據庫文件，日誌和其餘文件

        2.    restart_on_missing_heartbeats（1.4.4中的新增內容）：

               若是MySQL線程錯過了restart_on_missing_heartbeats心跳，則proxysql將引起SIGABRT信號並從新啓動。 默認值爲10。 

                詳情請見：https://github.com/sysown/proxysql/wiki/Watchdog。

        3.    execute_on_exit_failure（1.4.4中的新增內容）：

               若是設置，ProxySQL父進程將在每次ProxySQL崩潰時執行定義的腳本。 建議使用此設置生成警報或記錄事件。 

                請注意，在崩潰的狀況下，proxysql可以在幾毫秒內從新啓動，所以其餘監視工具可能沒法檢測到正常故障。

        4.    errorlog（2.0.0中的新增內容）：

               若是設置，ProxySQL將使用定義的文件做爲錯誤日誌。 若是未傳遞此類變量，則errolog將位於datadir / proxysql.log中

   

初始化啓動過程（或--initial）

    在初始啓動時，將從配置文件中填充內存和運行時配置。 此後，配置將保留在ProxySQL的嵌入式SQLite數據庫中。 

    經過使用--initial標誌運行proxysql能夠強制從新發生初始配置，這會將SQLite數據庫文件重置爲其原始狀態（即配置文件中定義的狀態）並重命名現有的SQLite數據庫文件 

    若是須要回滾（若是須要，檢查已定義的數據目錄中的舊文件）。

 

從新加載啓動（或--reload）

    若是使用--reload標誌執行proxysql，它會嘗試將配置文件中的配置與數據庫文件的內容合併。 以後，ProxySQL將繼續啓動程序。

    若是配置文件和數據庫文件的參數存在衝突，則沒法保證ProxySQL將成功管理合並，用戶應始終驗證合併結果是否符合預期。

 

核心配置表

    在運行時修改配置是經過ProxySQL的MySQL管理端口（默認爲6032）完成的。 

    鏈接到它後，您將看到一個與MySQL兼容的接口，用於查詢各類與ProxySQL相關的表：

mysql> show tables;
+-------------------+
| tables            |
+-------------------+
| mysql_servers     |
| mysql_users       |
| mysql_query_rules |
| global_variables  |
| mysql_collations  |
| debug_levels      |
+-------------------+

 

    每一個這樣的表都有明確的定義：

        mysql_servers：        包含要鏈接的ProxySQL的後端服務器列表

        mysql_users：           包含ProxySQL將用於向後端服務器進行身份驗證的用戶列表

        mysql_query_rules:    包含用於緩存，路由或重寫發送到ProxySQL的SQL查詢的規則

        global_variables:        包含在服務器初始配置期間定義的MySQL變量和管理變量

        debug_levels:             僅用於調試ProxySQL的手動構建

 

在不一樣層級間移動配置信息

    爲了將配置持久化到磁盤或將配置加載到運行時，可使用一組不一樣的管理命令，這些命令能夠經過管理界面執行。 

    一旦理解了三層中的每一層的使用方式，語義都應該清楚。 

    連同每一個命令的說明，每一個命令旁邊都有一個編號選項。 該數字對應於下圖中列出的箭頭

    

 

    

要從新配置MySQL用戶，請執行如下命令之一：

 

[1]    LOAD MYSQL USERS FROM MEMORY / LOAD MYSQL USERS TO RUNTIME

    將MySQL用戶從MEMORY加載到RUNTIME數據結構，反之亦然

 

[2]    SAVE MYSQL USERS TO MEMORY / SAVE MYSQL USERS FROM RUNTIME

    將MySQL用戶從RUNTIME保存到MEMORY

 

[3]    LOAD MYSQL USERS TO MEMORY / LOAD MYSQL USERS FROM DISK

    將持久化的MySQL用戶從磁盤數據庫加載到MEMORY

 

[4]    SAVE MYSQL USERS FROM MEMORY / SAVE MYSQL USERS TO DISK

    將MySQL用戶從MEMORY中保存到DISK

 

[5]    LOAD MYSQL USERS FROM CONFIG

    從配置文件加載用戶到MEMORY

    經常使用的命令參考：

LOAD MYSQL USERS TO RUNTIME;
SAVE MYSQL USERS TO DISK;

LOAD MYSQL SERVERS TO RUNTIME;
SAVE MYSQL SERVERS TO DISK;

LOAD MYSQL QUERY RULES TO RUNTIME;
SAVE MYSQL QUERY RULES TO DISK;

LOAD MYSQL VARIABLES TO RUNTIME;
SAVE MYSQL VARIABLES TO DISK;

LOAD ADMIN VARIABLES TO RUNTIME;
SAVE ADMIN VARIABLES TO DISK;

注意：關鍵字MEMORY/RUNTIME 都支持縮寫：
MEM for MEMORY
RUN for RUNTIME

 

故障排除

    請注意，只有在將值加載到運行時纔會進行最終驗證。 

    能夠設置一個值，該值在保存到內存時不會引起任何類型的警告或錯誤，甚至能夠保存到磁盤。

    可是，當執行加載到運行時，會自動將更改恢復爲先前已經保存的狀態。 

    若是發生這種狀況，應該檢查定義的錯誤日誌文件：

    例如：

    [WARNING] Impossible to set variable monitor_read_only_interval with value "0". Resetting to current "1500".    

    

經常使用的一些命令技巧

1.    限制ProxySQL到後端MySQL的鏈接數經過權重，來控制ProxySQL到後端MySQL的訪問量

    權重只做用在同一個hostgroup中有效

    

 

    

2.    自動迴避複製延遲較大的節點

    若是服務器將max_replication_lag設置爲非零值，則Monitor模塊會按期檢查複製延遲    

    下圖中，當172.16.0.3的複製延遲超過了30秒會自動迴避，設置max_replication_lag = 0，表明不檢查複製延遲 。

    

    注意，max_replication_lag主要來源Seconds_Behind_Master，該參數判斷延遲準確性不高，顧我的建議爲參考功能。

 

3.    Master Slave，將Master做爲Slave的備用讀節點

   在下面的示例中，若是咱們將HG1配置爲提供讀請求，則99.95％的請求將發送到172.16.0.2和172.16.0.3，而0.05％的請求將正常發送到172.16.0.1。 

   若是172.16.0.2和172.16.0.3不可用，172.16.0.1將獲取全部讀取請求。

   注意：max_replication_lag僅適用於從節點。 若是服務器未啓用複製，則Monitor不會執行任何操做。

4.    優雅的禁用後端Server

    要正常禁用後端服務器，須要將其狀態更改成OFFLINE_SOFT。 

    不會影響當前的活動事務和鏈接，但不會向該節點發送新流量。

 

5.    當即禁用後端Server

    要當即禁用後端服務器，須要將其狀態更改成OFFLINE_HARD。 全部當前請求將當即終止，而且不會發送新請求。

    172.18.0.1 設置了OFFLINE_HARD 會馬上中斷當前的請求。

    

 

6.    從新啓用脫機/禁用後端Server

    要在離線後端從新啓用，將其狀態更改回ONLINE就能夠了

    

 

7.    刪除後端Server

 

    注意：

        在內部，刪除後端或將其設置爲OFFLINE_HARD的方式相同。 

        當執行LOAD MYSQL SERVERS TO RUNTIME時，Hostgroup_Manager將檢測到後端服務器已被刪除，並在內部將其標記爲OFFLINE_HARD。   

 

8.    將明文密碼轉換成Hash密碼，配置到ProxySQL中的mysql_users表 

    mysql_users表，支持明文密碼和Hash密碼的寫入，但生產環境，咱們仍是建議用Hash密碼。

    將明文密碼轉換Hash密碼有兩種方式：

    1.    經過PASSWORD()

           該函數生成Hash密碼，但該函數ProxySQL是不支持的，須要在MySQL數據庫裏自行生成，再粘貼加密後的密碼插入到ProxySQL中。

    2.    經過變量：admin-hash_passwords（推薦）

            此參數默認開啓，明文密碼存放到MEMORY的mysql_user中，一旦load到RUNTIME會自動HASH加密。

            而後再SAVE回MEMORY/DISK便可完成明文到Hash密碼的轉換

          

          

9.    限制User和ProxySQL之間的鏈接數

  

10.    同個事務內的SQL，禁止被路由到不一樣節點上

    啓動事務後，可能會根據查詢規則將某些查詢發送到其餘主機組。 爲了防止這種狀況發生，能夠開啓transaction_persistent

      

還有不少沒有總結，一點點來，基礎知識梳理完成，會對核心功能再進行測試說明，但願對須要的同窗有幫助