專訪謝殿俠:別隻盯着智能音箱 語音交互將重構APP | AI英雄

網易科技2018-11-04 12:12:12


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 MEMORYRUN 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。


The Admin Schemas


ProxySQL 管理界面是一個使用 MySQL 協議的界面,任何能夠通過這種界面發送命令的客户端都很容易配置它。 


ProxySQL 解析通過此接口發送的查詢以查找特定於 ProxySQL 的任何命令,如果適當,則將它們發送到嵌入式 SQLite3 引擎以運行查詢。


請注意,SQLite3 和 MySQL 使用的 SQL 語法不同,因此並非所有適用於MySQL 的命令都適用於 SQLite3。例如,儘管管理界面接受 USE 命令,但它不會更改默認架構,因為 SQLite3 中不提供此功能。


連接到 ProxySQL 管理界面時,我們可以看到有一些數據庫可用。ProxySQL 將 SHOW DATABASES 命令轉換為 SQLite3 的等效命令。

 

 

這些數據庫的作用如下:

main:內存配置數據庫 。

使用此數據庫,可以輕鬆地以自動方式查詢和更新 ProxySQL 的配置。

使用 LOAD MYSQL USERS FROM MEMORY 和類似命令,存儲在此處的配置可以在運行時傳播到 ProxySQL 使用的內存數據結構。


disk:基於磁盤的 “main” 鏡像。

在重新啟動時,“main” 不會持久存在,並且可以從 “磁盤” 數據庫或配置文件中加載,具體取決於啟動標誌和磁盤數據庫的存在。


stats:包含從代理的內部功能收集的運行時指標。 

示例度量標準包括每個查詢規則匹配的次數,當前運行的查詢等。


monitor:包含與 ProxySQL 連接的後端服務器相關的監控指標。 
示例度量標準包括連接到後端服務器或對其進行ping操作的最短和最長時間。


myhgm:僅在調試版本中啟用。


此外,使用這兩種類型的用户使用這些默認憑據訪問管理數據庫。

user:admin / password:admin - 具有對所有表的讀寫訪問權限

user:stats / password:stats - 具有對統計表的只讀訪問權限。這用於從ProxySQL中提取指標,而不會暴露太多的數據庫。


上述的訪問憑據,可通過變量 admin-admin_credentials 和 admin-stats_credentials 進行配置。

MAIN 數據庫


主要包含了以下數據表:


核心配置表


1. mysql_server

 

字段定義

hostgroup_id

    包含此 mysqld 實例的主機組。請注意,同一實例可以是多個主機組的一部分


hostname,port

    可以聯繫 mysqld 實例的 TCP 端點


gtid_port                

    ProxySQL Binlog Reader 偵聽 GTID 跟蹤的後端服務器端口


status

    ONLINE - 後端服務器完全可以運行

    SHUNNED - 後端服務器暫時停止使用,因為在時間太短或複製延遲超過允許閾值的情況下連接錯誤太多

    OFFLINE_SOFT - 當服務器進入 OFFLINE_SOFT 模式時,不再接受新的傳入連接,而現有連接將保持不變,直到它們變為非活動狀態。換句話説,連接一直在使用,直到當前事務完成。這允許優雅地分離後端

    OFFLINE_HARD - 當服務器進入 OFFLINE_HARD 模式時,現有連接被丟棄,而新的傳入連接也不被接受。這相當於從主機組中刪除服務器,或暫時將其從主機組中取出以進行維護工作


weight

    服務器相對於其他權重的權重越大,從主機組中選擇服務器的概率就越高


compression

    如果該值大於0,則與該服務器的新連接將使用壓縮


max_connections

    ProxySQL將向此後端服務器打開的最大連接數。即使此服務器具有最高權重,但一旦達到此限制,就不會向其打開新連接。請確保後端配置了正確的max_connections值,以避免ProxySQL嘗試超出該限制


max_replication_lag

    如果更大且為0,ProxySQL將定期監視複製延遲,如果超出此閾值,它將暫時避開主機,直到複製趕上


use_ssl

    如果設置為1,則與後端的連接將使用SSL


max_latency_ms

    定期監視ping時間。如果主機的ping時間大於max_latency_ms,則它將從連接池中排除(儘管服務器保持ONLINE狀態)


comment

    可用於用户定義的任何目的的文本字段。可以是主機存儲內容的描述,添加或禁用主機的提醒,或某些檢查器腳本處理的 JSON。

2. mysql_replication_hostgroups


表 mysql_replication_hostgroups 定義用於傳統主/從異步或者半同步或者增強半同步複製的複製主機組。 

 

如果使用 Group Replication / InnoDB Cluster 或 Galera / Percona XtraDB Cluster 進行復制,則應使用 mysql_group_replication_hostgroups 或mysql_galera_hostgroups(在2.x版中提供)。


mysql_replication_hostgroups中的每一行代表一對writer_hostgroup和reader_hostgroup。 

 

ProxySQL 將監視指定主機組中所有服務器的 read_only 值,並根據 read_only 的值將服務器分配給 writer 組或 reader 組。 

 

字段的註釋可用於存儲任意數據。


字段定義   

writer_hostgroup - 默認情況下將發送所有請求的主機組,MySQL 中 read_only = 0 的節點將分配給該主機組。

reader_hostgroup - 應該發送讀取請求的主機組,應該定義查詢規則或單獨的只讀用户將流量路由到此主機組,將 read_only = 1 的節點分配給該主機組。

check_type - 執行只讀檢查時檢查的 MySQL 變量,默認情況下為 read_only(也可以使用 super_read_only)。對於AWS Aurora,應使用innodb_read_only。

comment - 可用於用户定義的任何目的的文本字段。可以是集羣存儲內容的描述,添加或禁用主機組的提醒,或某些檢查器腳本處理的 JSON。

3. mysql_group_replication_hostgroups(MGR)


 

字段定義

writer_hostgroup - 默認情況下將發送所有請求的主機組,MySQL 中 read_only = 0 的節點將分配給該主機組。

backup_writer_hostgroup - 如果集羣有多個節點,其 read_only = 0 和max_writers,則 ProxySQL 會將其他節點(超過max_writes的節點)放入 backup_writer_hostgroup 中。

reader_hostgroup - 應該發送讀請求的主機組,將 read_only = 1 的節點分配給該主機組。

offline_hostgroup - 當 ProxySQL 的監視確定節點為 OFFLINE 時,它將被放入offline_hostgroup。

active - 啟用時,ProxySQL 監視主機組並在適當的主機組之間移動節點。

max_writers  - 此值確定 writer_hostgroup 中應允許的最大節點數,超過此值的節點將放入 backup_writer_hostgroup 中

writer_is_also_reader - 確定是否應將同一個節點添加到 reader_hostgroup 和writer_hostgroup 中。

max_transactions_behind - 確定在屏蔽節點之前,ProxySQL 應允許的寫入器後面的最大事務數,以防止讀取落後過多(這是通過查詢 MySQL 中sys.gr_member_routing_candidate_status表的transactions_behind 字段來確定的)。

comment - 可用於用户定義的任何目的的文本字段。可以是集羣存儲內容的描述,添加或禁用主機組的提醒,或某些檢查器腳本處理的 JSON。

4. mysql_galera_hostgroups(PXC)


表 mysql_galera_hostgroups(在 ProxySQL 2.x 及更高版本中可用)定義了用於 Galera Cluster / Percona XtraDB Cluster 的主機組。



字段定義

writer_hostgroup - 默認情況下將發送所有流量的主機組,MySQL 中 read_only = 0 的節點將分配給該主機組。

backup_writer_hostgroup - 如果集羣有多個節點,其 read_only = 0 和max_writers,則 ProxySQL 會將其他節點(超過 max_writes )放入 backup_writer_hostgroup 中。

reader_hostgroup - 應該發送讀取流量的主機組,應該定義查詢規則或單獨的只讀用户將流量路由到此主機組,將 read_only = 1 的節點分配給該主機組。

offline_hostgroup - 當 ProxySQL 的監控確定主機處於OFFLINE 時,它將被放入 offline_hostgroup

active - 啟用時,ProxySQL 監視主機組並在適當的主機組之間移動服務器。

max_writers - 此值確定 writer_hostgroup 中應允許的最大節點數,超過此值的節點將放入 backup_writer_hostgroup 中

writer_is_also_reader - 確定是否應將節點添加到 reader_hostgroup 以及在提升後的 writer_hostgroup。

max_transactions_behind - 確定在避開節點之前 ProxySQL 應允許的集羣后面的最大寫集數,以防止過時讀取(這是通過查詢 wsrep_local_recv_queue Galera變量確定的)。

comment - 可用於用户定義的任何目的的文本字段。可以是集羣存儲內容的描述,添加或禁用主機組的提醒,或某些檢查器腳本處理的 JSON。

5. mysql_users

表 mysql_users 定義 MySQL 用户,用於連接後端。

 

字段定義

username,password - 用於連接 mysqld 或 ProxySQL 實例的憑據。

active - 將在數據庫中跟蹤 active = 0 的用户,但永遠不會在內存數據結構中加載

default_hostgroup - 如果此用户發送的查詢沒有匹配規則,則生成的流量將發送到指定的主機組

default_schema - 默認情況下連接應更改的架構

schema_locked - 尚不支持(TODO:check)

transaction_persistent - 如果是一個事務內的多條 SQL,只會路由到一個主機組中。

fast_forward - 如果設置,它繞過查詢處理層(重寫,緩存)並直接將查詢傳遞給後端服務器。

frontend - 如果設置為1,則此(用户名,密碼)對用於對 ProxySQL 實例進行身份驗證

backend - 如果設置為1,則此(用户名,密碼)對用於針對任何主機組對 mysqld 服務器進行身份驗證

max_connections - 定義特定用户的最大允許前端連接數。

comment - 可用於用户定義的任何目的的文本字段。可以是集羣存儲內容的描述,添加或禁用主機組的提醒,或某些檢查器腳本處理的 JSON。

注意,目前所有用户都需要將 “frontend” 和“後 backend” 都設置為 1。 


ProxySQL 的未來版本將在前端和後端之間分離證書。 


通過這種方式,前端永遠不會知道直接連接到後端的憑證,強制通過 ProxySQL 進行所有連接並提高系統的安全性。


fast_forward 注意事項:

1. 它不需要不同的端口:完整的功能代理邏輯和“快進”邏輯在同一代碼/模塊中實現

2. fast_forward 是基於每個用户實現的:取決於連接到 ProxySQL 的用户,啟用或禁用 fast_forward

3. 驗證後啟用 fast_forward 算法:客户端仍然對 ProxySQL 進行身份驗證,當客户端開始發送流量時,ProxySQL 將創建連接。這意味着在連接階段仍然會處理連接錯誤。

4. fast_forward 不支持 SSL

5. 如果使用壓縮,則必須在兩端啟用它

注意:mysql_users 中的用户也不應該與 admin-admin_credentials 和 admin-stats_credentials 裏的配置相同

6. mysql_query_rules

表 mysql_query_rules 定義了路由策略和屬性。

 

字段定義

rule_id - 規則的唯一 ID。規則以 rule_id 順序處理

 

active - 查詢處理模塊將僅考慮 active = 1 的規則,並且只將活動規則加載到運行時。

 

username - 匹配用户名的過濾條件。如果為非 NULL,則僅當使用正確的用户名建立連接時,查詢才會匹配

 

schemaname - 匹配 schemaname 的過濾條件。如果為非 NULL,則僅當連接使用 schemaname 作為默認模式時,查詢才會匹配(在 mariadb / mysql schemaname 中等效於 databasename)

flagIN,flagOUT,apply -

這些允許我們創建一個接一個地應用的“規則鏈”。 
輸入標誌值設置為 0,並且在開始時僅考慮 flagIN = 0 的規則。 
當為特定查詢找到匹配規則時,將評估 flagOUT,如果為 NOT NULL,則將使用flagOUT 中的指定標誌標記查詢。 
如果 flagOUT 與 flagIN 不同,則查詢將退出當前鏈並輸入一個新的規則鏈,其中flagIN 作為新的輸入標誌。 
如果 flagOUT 與 flagIN 匹配,則將針對具有所述flagIN的第一個規則再次重新評估查詢。 
這種情況會發生,直到沒有更多匹配規則,或者 apply 設置為 1(這意味着這是要應用的最後一條規則)


client_addr - 匹配來自特定源的流量

 

proxy_addr - 匹配特定本地 IP 上的傳入流量

 

proxy_port - 匹配特定本地端口上的傳入流量

使用 stats_mysql_query_digest.digest 返回的特定摘要匹配查詢

 

match_digest - 與查詢摘要匹配的正則表達式。另請參見https://github.com/sysown/proxysql/wiki/Global-variables#mysql-query_processor_regex

 

match_pattern - 與查詢文本匹配的正則表達式。另請參見https://github.com/sysown/proxysql/wiki/Global-variables#mysql-query_processor_regex

 

negate_match_pattern - 如果將其設置為 1,則只有與查詢文本不匹配的查詢才會被視為匹配項。這在與 match_pattern 或 match_digest 匹配的正則表達式前面充當 NOT 運算符

 

re_modifiers -

用逗號分隔的選項列表,用於修改RE引擎的行為。使用CASELESS,匹配不區分大小寫。

使用GLOBAL,替換是全局的(替換所有匹配而不僅僅是第一個匹配)。

為了向後兼容,默認情況下僅啟用CASELESS。有關更多詳細信息,另請參見https://github.com/sysown/proxysql/wiki/Global-variables#mysql-query_processor_regex。

 

replace_pattern -

這是用於替換匹配模式的模式。

它是使用RE2 :: Replace完成的,因此值得一看有關的在線文檔:https://github.com/google/re2/blob/master/re2/re2.h#L378。

請注意,這是可選的,當缺少此選項時,查詢處理器將僅緩存,路由或設置其他參數而不重寫。

 

destination_hostgroup -

將匹配的查詢路由到此主機組。

除非存在已啟動的事務且登錄用户將transaction_persistent標誌設置為1(請參閲mysql_users表),否則會發生這種情況。

 

cache_ttl - 緩存查詢結果的毫秒數。注意:在 ProxySQL 1.1 中,cache_ttl 只需幾秒鐘

 

cache_empty_result -

控制是否緩存沒有行的結果集

重新連接 - 未使用的功能

 

timeout -

應執行匹配或重寫查詢的最大超時(以毫秒為單位)。

如果查詢運行的時間超過特定閾值,則會自動終止查詢。如果未指定timeout,則應用全局變量mysql-default_query_timeout

 

retries - 在執行查詢期間檢測到失敗時需要重新執行查詢的最大次數。如果未指定重試,則應用全局變量 mysql-query_retries_on_failure

delay -

延遲執行查詢的毫秒數。

這本質上是一種限制機制和QoS,允許優先考慮某些查詢而不是其他查詢。

此值將添加到適用於所有查詢的mysql-default_query_delay全局變量中。未來版本的ProxySQL將提供更高級的限制機制。

 

mirror_flagOUT 和 mirror_hostgroup - 與鏡像相關的設置 https://github.com/sysown/proxysql/wiki/Mirroring。

 

error_msg - 將阻止查詢,並將指定的 error_msg 返回給客户端

 

OK_msg - 將為使用已定義規則的查詢返回指定的消息

 

sticky_conn - 尚未實現

 

multiplex -

如果為0,則禁用Multiplex。

如果為1,如果沒有任何其他條件阻止此操作(如用户變量或事務),則可以重新啟用Multiplex。

如果為2,則不會僅針對當前查詢禁用多路複用。請參閲 wiki 默認為 NULL,因此不會修改多路複用策略

gtid_from_hostgroup - 定義哪個主機組應該用作 GTID 一致性讀取的領導者(通常是複製主機組對中定義的 WRITER 主機組)

 

log- 將記錄查詢

 

apply - 當設置為1時,在匹配和處理此規則後,將不再評估進一步的查詢(注意:之後不會評估 mysql_query_rules_fast_routing 規則)

 

comment- 自由格式文本字段,可用於查詢規則的描述性註釋

7. mysql_query_rules_fast_routing


表 mysql_query_rules_fast_routing 是 mysql_query_rules 的擴展,之後會對快速路由策略和屬性進行評估(僅在ProxySQL 1.4.7+中可用)。



字段定義

username - 與用户名匹配的過濾條件,只有在使用正確的用户名建立連接時,查詢才會匹配

schemaname - 匹配 schemaname 的過濾條件,只有當連接使用 schemaname作為默認模式時,查詢才會匹配(在 mariadb / mysql schemaname 中,這相當於 databasename)

flagIN - 與 mysql_query_rules 中 flagin 相同,並與 mysql_query_rules 表中指定的 flagout / apply 相關聯

destination_hostgroup - 將匹配的查詢路由到此主機組。 

comment- 自由格式文本字段,可用於查詢規則的描述性註釋

8. global_variables\mysql_collations\scheduler 


暫不介紹了,後面會逐步投在功能介紹裏提及

 

Runtime 層對應表

表以 runtime_開頭,其餘基本與MAIN庫中的表名相同,例如:runtime_mysql_servers 是 內存層 mysql_servers表的對應表

  • runtime_global_variables : runtime version of global_variables

  • runtime_mysql_replication_hostgroups : runtime version of mysql_replication_hostsgroups

  • runtime_mysql_galera_hostgroups : runtime version of mysql_replication_hostsgroups

  • runtime_mysql_group_replication_hostgroups : runtime version of mysql_replication_hostsgroups

  • runtime_mysql_query_rules : runtime version of mysql_query_rules

  • runtime_mysql_query_rules_fast_routing : runtime version of mysql_query_rules_fast_routing

  • runtime_mysql_servers : runtime version of mysql_servers

  • runtime_mysql_users : runtime version of mysql_users

  • runtime_proxysql_servers : runtime version of proxysql_servers

  • runtime_scheduler : runtime version of scheduler


請注意,如果 ProxySQL 重新啟動,如果內容未保存在磁盤數據庫中,則內存表(MAIN數據庫)的所有內容都將丟失。

 

Disk 層對應表


“disk” 數據庫與 “main” 數據庫具有完全相同的表,具有相同的語義。 

唯一的主要區別是這些表存儲在磁盤上,而不是存儲在內存中。 

每當重新啟動 ProxySQL 時,將從此數據庫開始填充內存中的 “main” 數據庫。

 

監控MGR,需要在 MySQL 實例中配置一些監控腳本(MySQL 5.7 和 MySQL 8.0 略有不同)


該腳本需要配置到 sys 庫下,因筆記 web 顯示問題,無法顯示折行,但是不影響複製,可以自行復制粘貼出來即可。


先看看執行效果 

select * from sys.gr_member_routing_candidate_status;+------------------+-----------+---------------------+----------------------+| viable_candidate | read_only | transactions_behind | transactions_to_cert |+------------------+-----------+---------------------+----------------------+| YES              | NO        |                   0 |                    0 |+------------------+-----------+---------------------+----------------------+
viable_candidate:MGR當前節點是否正常read_only:當前節點是否開啟了只讀transactions_behind:MGR應用relay log的隊列中,積壓事務數transactions_to_cert:MGR當前節點的驗證隊列,積壓事務數

 

MySQL 5.7 配置腳本為:

USE sys;
DELIMITER $$
CREATE FUNCTION IFZERO(a INT, b INT) RETURNS INT DETERMINISTIC RETURN IF(a = 0, b, a)$$
CREATE FUNCTION LOCATE2(needle TEXT(10000), haystack TEXT(10000), offset INT)RETURNS INT DETERMINISTIC RETURN IFZERO(LOCATE(needle, haystack, offset), LENGTH(haystack) + 1)$$
CREATE FUNCTION GTID_NORMALIZE(g TEXT(10000))RETURNS TEXT(10000) DETERMINISTIC RETURN GTID_SUBTRACT(g, '')$$
CREATE FUNCTION GTID_COUNT(gtid_set TEXT(10000))RETURNS INT DETERMINISTIC BEGIN DECLARE result BIGINT DEFAULT 0; DECLARE colon_pos INT;DECLARE next_dash_pos INT; DECLARE next_colon_pos INT; DECLARE next_comma_pos INT;SET gtid_set = GTID_NORMALIZE(gtid_set); SET colon_pos = LOCATE2(':', gtid_set, 1);WHILE colon_pos != LENGTH(gtid_set) + 1 DO SET next_dash_pos = LOCATE2('-', gtid_set, colon_pos + 1);SET next_colon_pos = LOCATE2(':', gtid_set, colon_pos + 1); SET next_comma_pos = LOCATE2(',', gtid_set, colon_pos + 1);IF next_dash_pos THEN SET result = result + SUBSTR(gtid_set, next_dash_pos + 1,LEAST(next_colon_pos, next_comma_pos) - (next_dash_pos + 1)) - SUBSTR(gtid_set, colon_pos + 1, next_dash_pos - (colon_pos + 1)) + 1;ELSE SET result = result + 1; END IF;SET colon_pos = next_colon_pos;END WHILE; RETURN result;END$$
CREATE FUNCTION gr_applier_queue_length()RETURNS INT DETERMINISTICBEGIN RETURN (SELECT sys.gtid_count( GTID_SUBTRACT( (SELECT Received_transaction_set FROM performance_schema.replication_connection_status WHERE Channel_name = 'group_replication_applier' ), (SELECT @@global.GTID_EXECUTED) )));END$$
CREATE FUNCTION gr_member_in_primary_partition()RETURNS VARCHAR(3) DETERMINISTIC BEGIN RETURN (SELECT IF( MEMBER_STATE='ONLINE' AND (( SELECT COUNT() FROM performance_schema.replication_group_members WHERE MEMBER_STATE != 'ONLINE') >= (( SELECT COUNT() FROM performance_schema.replication_group_members)/2) = 0), 'YES', 'NO' ) FROM performance_schema.replication_group_members JOIN performance_schema.replication_group_member_stats USING(member_id));END$$
CREATE VIEW gr_member_routing_candidate_status AS SELECT sys.gr_member_in_primary_partition() AS viable_candidate, IF((SELECT (SELECT GROUP_CONCAT(variable_value) FROM performance_schema.global_variables WHERE variable_name IN ('read_only' , 'super_read_only')) != 'OFF,OFF' ), 'YES', 'NO') AS read_only, sys.gr_applier_queue_length() AS transactions_behind, Count_Transactions_in_queue AS 'transactions_to_cert' FROM performance_schema.replication_group_member_stats$$
DELIMITER ;


MySQL 8.0 配置腳本為:

USE sys;DELIMITER $$
CREATE FUNCTION IFZERO(a INT, b INT)RETURNS INTDETERMINISTICRETURN IF(a = 0, b, a)$$
CREATE FUNCTION LOCATE2(needle TEXT(10000), haystack TEXT(10000), offset INT)RETURNS INTDETERMINISTICRETURN IFZERO(LOCATE(needle, haystack, offset), LENGTH(haystack) + 1)$$
CREATE FUNCTION GTID_NORMALIZE(g TEXT(10000))RETURNS TEXT(10000)DETERMINISTICRETURN GTID_SUBTRACT(g, '')$$
CREATE FUNCTION GTID_COUNT(gtid_set TEXT(10000))RETURNS INTDETERMINISTICBEGIN DECLARE result BIGINT DEFAULT 0; DECLARE colon_pos INT; DECLARE next_dash_pos INT; DECLARE next_colon_pos INT; DECLARE next_comma_pos INT; SET gtid_set = GTID_NORMALIZE(gtid_set); SET colon_pos = LOCATE2(':', gtid_set, 1); WHILE colon_pos != LENGTH(gtid_set) + 1 DO SET next_dash_pos = LOCATE2('-', gtid_set, colon_pos + 1); SET next_colon_pos = LOCATE2(':', gtid_set, colon_pos + 1); SET next_comma_pos = LOCATE2(',', gtid_set, colon_pos + 1); IF next_dash_pos SET result = result + SUBSTR(gtid_set, next_dash_pos + 1, LEAST(next_colon_pos, next_comma_pos) - (next_dash_pos + 1)) - SUBSTR(gtid_set, colon_pos + 1, next_dash_pos - (colon_pos + 1)) + 1; ELSE SET result = result + 1; END IF; SET colon_pos = next_colon_pos; END WHILE; RETURN result;END$$
CREATE FUNCTION gr_applier_queue_length()RETURNS INTDETERMINISTICBEGIN RETURN (SELECT sys.gtid_count( GTID_SUBTRACT( (SELECTReceived_transaction_set FROM performance_schema.replication_connection_statusWHERE Channel_name = 'group_replication_applier' ), (SELECT@@global.GTID_EXECUTED) )));END$$

CREATE FUNCTION gr_member_in_primary_partition()RETURNS VARCHAR(3)DETERMINISTICBEGIN RETURN (SELECT IF( MEMBER_STATE='ONLINE' AND ((SELECT COUNT(*) FROMperformance_schema.replication_group_members WHERE MEMBER_STATE != 'ONLINE') >=((SELECT COUNT(*) FROM performance_schema.replication_group_members)/2) = 0),'YES', 'NO' ) FROM performance_schema.replication_group_members JOINperformance_schema.replication_group_member_stats USING(member_id) where [email protected]@hostname);END$$
CREATE VIEW gr_member_routing_candidate_status AS SELECT sys.gr_member_in_primary_partition() AS viable_candidate, IF((SELECT (SELECT GROUP_CONCAT(variable_value) FROM performance_schema.global_variables WHERE variable_name IN ('read_only' , 'super_read_only')) != 'OFF,OFF' ), 'YES', 'NO') AS read_only, sys.gr_applier_queue_length() AS transactions_behind, Count_Transactions_in_queue AS 'transactions_to_cert' FROM performance_schema.replication_group_member_stats a JOIN performance_schema.replication_group_members b ON a.member_id = b.member_id WHERE b.member_host IN (SELECT variable_value FROM performance_schema.global_variables WHERE                variable_name = 'hostname')$$
DELIMITER ;


還有很多沒有總結,一點點來,基礎知識梳理完成,會對核心功能再進行測試説明,希望對需要的同學有幫助。

來源:cnblogs
原文:http://t.cn/Ai9B8mrV
題圖:
來自谷歌圖片搜索 
版權:
本文版權歸原作者所有
投稿:歡迎投稿,投稿郵箱: [email protected]


文末推薦極客時間視頻專欄 「Elasticsearch 核心技術與實戰」,一共 95 講,約 1000 分鐘,更多專欄介紹可「這裏」。果你想快速構建分佈式搜索和分析引擎,這個課程可以幫到你,該專欄剛上架已經有 8000+ 名同學在學習了。


公眾號額外福利通過下面海報訂閲專欄的讀者,公眾號再返 24 元紅包。到手相當於  75  元,非常划算。(購買後,加我微信返現還沒加我微信的可戳「這裏」找到我喲~)。


👇 優惠僅剩最後 3 天,抓緊時間訂購吧

△ 掃碼試讀或訂閲



推薦閲讀

  • 10 個構建和管理容器的技巧

  • 談談互聯網架構

  • 從零開始搭建創業公司後台技術棧

  • 淺談集羣、分佈式、微服務的異同

  • 史上最全的 Linux 運維工程師面試問答錄

https://weiwenku.net/d/201124609