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.htmlProxySQL
ProxySQL作為一款強大的中介軟體為MySQL的架構提供了有力的支援。 目前可以很好的支援 Master Slave\ MGR \ PXC等，並提供連線池、讀寫分離、日誌記錄等功能，當然還有很多其他實用功能，這裡不一一列舉了。 本文都是基礎概念，基本出自官方文件，官方已經解釋的非常清晰，我就不太多加工，彙總一些實用的分享給大家。安裝
連線ProxySQL
ProxySQL預設管理埠6032，預設需要127.0.0.1來進入，進入方式和連線MySQL方式一致：ProxySQL 執行機制
RUNTIME
RUNTIME表示處理請求的執行緒使用的ProxySQL的記憶體資料結構。 runtime variables 包含了： 1. Global variables的實際值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不會執行任何操作。