MySQL-ProxySQL中間件(一)| ProxySQL基本概念


目錄

     MySQL-ProxySQL中間件(一)| ProxySQL基本概念: https://www.cnblogs.com/SQLServer2012/p/10972593.html
    MySQL-ProxySQL中間件(二)| Admin Schemas介紹:https://www.cnblogs.com/SQLServer2012/p/10972761.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
      
還有很多沒有總結,一點點來,基礎知識梳理完成,會對核心功能再進行測試說明,希望對需要的同學有幫助


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM