ProxySQL Cluster 概述
1:前言
在ProxySQL 1.4.2 之前,ProxySQL 單點的解決方法有配合keepalived 使用來實現ProxySQL的主備,但是需要在主備上配置兩份完全相同的路由或規則,如果再沒有自動運維平臺,同時維護兩份配置的也是相當麻煩的。而且目前主流的云環境,均不支持keepalived 使用的 VRRP 協議,所以在云環境上就無法通過keepalived 來實現故障切換。從1.4.2 開始,ProxySQL 開始支持原生的 Cluster,這就有效的解決了之前需要借助第三方工具才能解決的單點問題。
另外:ProxySQL Cluster 對MySQL Group Replication 的支持,和任務調度功能,也正在開發中。
2:ProxySQL Cluster
當前版本的ProxySQL Cluster 有2個主要組件:
monitoringre-configuration
這2個組件對原有的4個表都是支持的:
mysql_query_rulesmysql_servers
mysql_users
proxysql?_servers
2.1 Monitoring
為了監控Cluster,ProxySQL Cluster 新加了部分表、命令和變量。
2.1.1 :admin variables
2.1.1.1:同步什么
| admin-checksum_mysql_query_rules | true | =true時,每次執行LOAD MYSQL QUERY RULES TO RUNTIME時,proxy都會生成一個新的配置checksum。=false時,新的配置不會自動被廣播,也不會其他節點同步。 |
| admin-checksum_mysql_servers | true | =true時,每次執行LOAD MYSQL serversTO RUNTIME時,proxy都會生成一個新的配置checksum。=false時,新的配置不會自動被廣播,也不會其他節點同步。 |
| admin-checksum_mysql_users | true | =true時,每次執行LOAD MYSQL usersTO RUNTIME時,proxy都會生成一個新的配置checksum。=false時,新的配置不會自動被廣播,也不會其他節點同步。 |
2.1.1.2 :認證參數
集群間,Proxy 為了監控其他Proxy 實例需要認證參數:admin-cluster_username 和 admin-cluster_password。而且這2個參數指定的用戶名/密碼還必須配置到參數 admin-admin_credentials 中,否則會無法連接到其他proxy
admin_credentials="admin:admin;cluster1:secret1pass"2.1.1.3: 檢查間隔和頻率相關參數
| admin-cluster_check_interval_ms | 1000 | 定義進行checksum的時間間隔。10~300000 |
| admin-cluster_check_status_frequency | 10 |
2.1.1.4 :持久化相關參數
當有新的集群配置被同步到遠端proxy ,并且load to runtime 后,可以控制是否立即將配置自動存盤。 query rules, servers, users 和proxysql servers 分別有admin-cluster_XXX_save_to_disk 相關的參數,默認是 true。
有些原因,可能造成多個ProxySQL 實例在同一時間發生reconfigured 的情況:
所有proxy 實例都在監控一個MySQL 集群,并且都發現了MySQL 集群發生了failover。在很短的時間內(通常小于1s),所有proxy 實例都會發生同樣的配置變更,并且不需要和其他實例進行同步所有實例都探測到網絡異常或者MySQL DB 反應慢,那所有proxy 實例都會避開該節點。此時所有proxy 實例都會執行同樣的動作,從而也不用從其他實例上同步配置。
極端情況下,一個slave 由于lag 很大,并且主動從集群中退出。此時所有proxy 實例也都會發生相應的reconfiguration。
2.1.1.5 :延遲同步
ProxySQL Cluster 可以定義達到多少個checksum 不同之后,才在集群內部進行配置同步。
query rules, servers, users 和proxysql servers 分別有admin-cluster_XXX_diffs_before_sync 相關的參數,取值范圍0 ~ 1000,0 代表從不同步。默認3。
2.1.2 :configuration table
2.1.2.1: proxysql_servers
ProxySQL 集群有哪些實例,可以查看proxysql_servers 表。在新增ProxySQL 實例時,也需要 insert 該表,或者修改cnf 文件中的 proxysql_servers 部分的配置。
注意:?weight 在當前版本中還未正式啟用。
CREATE TABLE proxysql_servers (hostname VARCHAR NOT NULL,port INT NOT NULL DEFAULT 6032,weight INT CHECK (weight >= 0) NOT NULL DEFAULT 0,comment VARCHAR NOT NULL DEFAULT '',PRIMARY KEY (hostname, port) )2.1.2.2:runtime_checksums_values
CREATE TABLE runtime_checksums_values (name VARCHAR NOT NULL,version INT NOT NULL,epoch INT NOT NULL,checksum VARCHAR NOT NULL,PRIMARY KEY (name))runtime_checksums_values 記錄當 load to runtime 被執行時系統的信息。
epoch : 記錄load to runtime 被執行的時間checksum: 記錄每個組件在load to runtime 時的checksum 值
version :記錄load to run 的次數。每次重啟實例后,該值都會被重置為 1
目前6個組件中只有4個可以生成checksum,不能生成的組件是:admin_variables,mysql_variables。 checnsum 只有在執行了load to run ,并且admin-checksum_XXX = true 時,才可以正常生成。
2.1.3: state tables
有三個表被加入到stat 表中。
2.1.3.1:stats_proxysql_servers_checksums
記錄集群中各個實例的組件checksum 信息。
Admin> SHOW CREATE TABLE stats.stats_proxysql_servers_checksums\G *************************** 1. row ***************************table: stats_proxysql_servers_checksums Create Table: CREATE TABLE stats_proxysql_servers_checksums (hostname VARCHAR NOT NULL,port INT NOT NULL DEFAULT 6032,name VARCHAR NOT NULL,version INT NOT NULL,epoch INT NOT NULL,checksum VARCHAR NOT NULL,changed_at INT NOT NULL,updated_at INT NOT NULL,diff_check INT NOT NULL,PRIMARY KEY (hostname, port, name) ) changed_at :探測到發生checksum change 的時間updated_at :上次更新checksum 的時間
diff_check :計數器,用來記錄本地proxy 和遠端proxy checksum 不同的次數,當達到參數cluster_*_diffs_before_sync 定義的閥值后,才能觸發集群的同步動作。如果 diff_check 很大,但是又沒觸發同步動作,那遠端的proxy 就不是一個可靠的數據源。
2.1.3.2:stats_proxysql_servers_metrics
該表用來顯示群集模塊在各個實例中執行 SHOW MYSQL STATUS 時,當前系統的部分指標。目前該表只是用來debug 的,在未來該表的各個指標將用來反映各個實例的健康狀態。
Admin> SHOW CREATE TABLE stats.stats_proxysql_servers_metrics\G *************************** 1. row ***************************table: stats_proxysql_servers_metrics Create Table: CREATE TABLE stats_proxysql_servers_metrics (hostname VARCHAR NOT NULL,port INT NOT NULL DEFAULT 6032,weight INT CHECK (weight >= 0) NOT NULL DEFAULT 0,comment VARCHAR NOT NULL DEFAULT '',response_time_ms INT NOT NULL,Uptime_s INT NOT NULL,last_check_ms INT NOT NULL,Queries INT NOT NULL,Client_Connections_connected INT NOT NULL,Client_Connections_created INT NOT NULL,PRIMARY KEY (hostname, port) ) weight: 和proxysql_servers.weight 一樣,暫時未使用。response_time_ms:單位毫秒。執行show mysql status 的響應時間。
uptime_s: 各個實例的啟動時間。
queries:各個實例上已經執行的query 數量
last_check_ms:上一次執行 show mysql status 距今的時間,單位毫秒。
Client_Connections_connected :已經連接上來的客戶端連接數
Client_Connections_created:被創建的客戶端連接數
2.1.3.3:stats_proxysql_servers_status
在目前的1.4.6 版本中,該表還未啟用。
2.2 :Re-configuration
因為集群間,所有節點都是相互監控的。所以當配置發生變動時,它們可以立即發現。當其他節點的配置發生變動時,本節點會先去檢查一次它自身的配置,因為有可能remote instance 和local instance 同時發生配置變動。如果不同:
如果它們自身的 version = 1,就去找集群內 version >1,并且 epoch 最高的節點,并立即同步。如果version >1, 該節點開始統計和其他節點間的differ 數。
當 differ 大于 cluster__name___diffs_before_sync , 并且cluster__name__diffs_before_sync > 0, 就去找集群內 version >1, 并且epoch 最高的節點,并立即同步。
同步過程如下:
健康檢查語句會執行一系列的SELECT 語句,例如 Select?list_of_columns?FROM runtime_module.SELECT hostgroup_id, hostname, port, status, weight, compression, max_connections, max_replication_lag, use_ssl, max_latency_ms, comment FROM runtime_mysql_servers; SELECT writer_hostgroup, reader_hostgroup, comment FROM runtime_mysql_replication_hostgroups; 刪除本地配置。例如:
DELETE FROM mysql_servers; DELETE FROM mysql_replication_hostgroups; 將新的配置insert 到本地表
內部提交LOAD module_name TO RUNTIME。 對應的version 會增加,并且生成一個新的 checksum
如果cluster__name__save_to_disk =true,還會內部執行 SAVE module_name TO DISK。
3:網絡消耗
從上面的論述可以看出,ProxySQL Cluster 中每個節點都在監控其他節點,是個很典型的點對點的網絡。 為了減少網絡開銷,節點間并不總是交換所有的checksum 信息,而是將所有version 、所有checksum 相結合產生的單個新的 checksum 進行交換。所以一旦這個新的checksum 發生變動,那么得到詳細的各個模塊的checksum。 在一個200個節點的集群中,如果每個節點每 1000ms 去探測一次,每個節點需要 50KB 的帶寬。
原文發布時間為:2018-03-18
本文作者:張燦
本文來自云棲社區合作伙伴“老葉茶館”,了解相關信息可以關注“老葉茶館”微信公眾號
總結
以上是生活随笔為你收集整理的ProxySQL Cluster 概述的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Android样式和主题(二):系统有哪
- 下一篇: [JOYOI] 1124 花店橱窗