MySQL Cluster Replication With MySQL Cluster and non-NDB


  • 環境介紹

因為筆電的空間和RAM有限，僅能在３台VM上來建置所有的場景
　　VM配置:
　　(3台環境資源配置均相同就不分開寫了)
　　hostname-> IP Address
　　ol65-> 192.168.56.101
　　ol65-cluster1-> 192.168.56.103
　　ol65-cluster2->192.168.56.104:
　　OS: Oracle Linux 6.5
　　RAM: 4G
　　mysql-5.6.19-ndb-7.3.6-cluster-commercial-advanced
　　mysql-5.6.21-enterprise-commercial-advanced (這只有在192.168.56.101）
　　
　　第一座MySQL cluster:
　　mgm_node: 192.168.56.101:1186
　　data_node_1: 192.168.56.103:50501
　　data_node_2: 192.168.56.104:50502
　　sql_node_1: 192.168.56.103:3306
　　sql_node_2: 192.168.56.104:3306

　　第二座MySQL cluster:
　　slave_mgm: 192.168.56.101:1188
　　slave_data_1: 192.168.56.103:50503
　　slave_data_2: 192.168.56.104:50504
　　slave_sql_1: 192.168.56.103:3306
　　slave_sql_2: 192.168.56.104:3306

　　MySQL Server
　　slave: 192.168.56.101:3306

  • 架構
MySQL Cluster Replication with MySQL Cluster
MySQL Cluster Replication with non-NDB

  • 前置設定

Table schema:
　　在Slave的mysql資料庫中新建此表，這個表是用來記錄已經從Master寫到Slave中的操作，所以之後的failover可以從這個表中找到線索
　　CREATE TABLE `ndb_apply_status` (　　　　　　　　　　　　
　　`server_id` INT(10) UNSIGNED NOT NULL,　　　　　　　　　
　　`epoch` BIGINT(20) UNSIGNED NOT NULL,　　　　　　　　　
　　`log_name` VARCHAR(255) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL,　　　　　　　　　　　　　　　　　　　　　
　　`start_pos` BIGINT(20) UNSIGNED NOT NULL,　　　　　　　　
　　`end_pos` BIGINT(20) UNSIGNED NOT NULL,　　　　　　　　
　　PRIMARY KEY (`server_id`) USING HASH　　　　　　　　　　
　　) ENGINE=NDBCLUSTER DEFAULT CHARSET=latin1;　　　　
這張表的storage engine如果是NDBCLUSTER的話只適用於cluster架構中，若不是可以改成MyISAM

　　Config file:

　　my.cnf (master_1:192.168.56.103:3306)
　　server_id                  = 1
　　log-bin
　　binlog_format             = ROW 
　　expire_logs_days        = 7  #清理過期多少天的bin log
　　ndb-log-update-as-write=0

　　my.cnf (master_2:192.168.56.104:3306)
　　server_id                  = 2
　　log-bin
　　binlog_format             = ROW 
　　expire_logs_days        = 7  #清理過期多少天的bin log
　　ndb-log-update-as-write=0

　　my.cnf (slave_1:192.168.56.103:3307)
　　server_id                  = 3
　　slave-exec-mode         = IDEMPOTENT
　　skip-slave-start         #(可設可不設)
　　slave-skip-errors          = ddl_exist_errors

　　my.cnf (slave_2:192.168.56.104:3307)
　　server_id                  = 4
　　slave-exec-mode         = IDEMPOTENT
　　skip-slave-start         #(可設可不設)
　　slave-skip-errors          = ddl_exist_errors
　　

  • Replication設定
　　
　　其設定如同一般的replication設定一樣，但這邊官網建議要使用two replication channel，這個設定跟後面在做failover時找bin log位置有關，下面簡單寫一下two repl channel：
　　primary master (M)
　　secondary master (M')
　　primary slave (S)
　　secondary slave (S')
　　我上面的參數(Config file)不論是single或two channel都可以用(single channel只差在另一台master SQL Node的bin log沒有開啟跟slave SQL Node沒有設那幾個參數)，然後同時間只有S是有啟動replication，S'是等主複製掛了才切換到這台上面。

 　　其實我個人認為這個是用在2座cluster做replication時用的，在文件failover章節中的方式是M→S、M'→S'，然後在最下面寫一句說："理論上也可以是M→S'或M'→S，但還沒實驗過！"，寫這樣超機車的，但我簡單測過後不論是對NDB或non-NDB都是沒問題的

  • Failover
　　假設今天sql_node_1掛掉時replication就會中止，此時要將master切換到sql_node_2去，如下圖所示：
　　
Failover

　　Step_01:
　　在slave_sql_2上面執行並記錄資料：
　　SELECT @latest:=MAX(epoch) FROM mysql.ndb_apply_status;
　　


 　　Step_02:
　　在sql_node_2上面執行：
　　SELECT @file:=SUBSTRING_INDEX(File, '/', -1), @pos:=Position 
　　FROM mysql.ndb_binlog_index 
　　WHERE epoch >@latest 
　　ORDER BY epoch ASC LIMIT 1;
　　＊這個@latest就是步驟一所得到的數值，若你在sql_node_2上面執行後沒有查出任何資料(Empty set (0.00 sec))就表示sql_node_2上面bin log中的資料，在slave中已寫到最新的位置上，如果在sql_node_2上面繼續寫入的話就會看到新的bin log位置。
　　

　　Step_03:
　　接下來就是執行change master to的指令了，記得master的內容要改成sql_node_2的資料，master_log_file和master_log_pos就是步驟二中查出來的資料。
　　Step_04:
　　start slave;
　　show slave status\G
　　若沒有錯誤的話就完成failover動作啦！

參考文件：
http://johanandersson.blogspot.tw/2009_05_01_archive.html

留言

張貼留言

這個網誌中的熱門文章

【工作筆記】SQL Timeout追蹤

圖片
幾個禮拜前去客戶那處理『SQL效能問題』，到場後，問題延伸為『SQL不定期發生Timeout的問題』 【客戶問題描述】 AP會建立100多個連線，且同時會將程式用幾十個連線來並行處理事務，會在不固定的時間會發生SQL Timeout的問題，由程式端無法定位是哪句SQL以及哪支程式導致的問題，在DB端也不會看到任何的錯誤訊息及警告訊息出現在Error Log中  【架構背景】 OS: CentOS 6.8, CPU 20 Cores, RAM 64G, HDD RAID 10 DB: MariaDB 10.0.1 Galera Cluster 【問題追踨】 在執行壓測過程中監控作業系統的狀態，包括CPU、RAM、IO的負載狀況 =>監控的結果CPU的load average大約在1，RAM有使用到少量的SWAP，cached的部份還有滿多可以使用，IO的負載不算太高，整體看來應該不是硬體方面造成的問題 在執行壓測過程中監控資料庫的錯誤日誌、慢查詢記錄、show processlist的狀況 =>錯誤日誌並未記錄到任何的錯誤及警告訊息，慢查詢只有其他資料庫中全表掃描的記錄，show processlist看到多數的連線均為sleep狀態，且SQL執行的時間都很短 在執行壓測過程中監控InnoDB的狀態 ------------------------ LATEST DETECTED DEADLOCK ------------------------ 2017-01-17 16:02:22 7fd7a00e6700 *** (1) TRANSACTION: TRANSACTION 755310052, ACTIVE 2 sec fetching rows mysql tables in use 1, locked 1 LOCK WAIT 6 lock struct(s), heap size 1184, 154 row lock(s) MySQL thread id 2916595, OS thread handle 0x7fdd2d9fe700, query id 213093063 192.168.3.2 tsap Sending data SELECT id, cid, time, retry FROM ss WHERE r
閱讀完整內容

MySQL監控軟體MEM及PMM介紹

圖片
MySQL監控軟體： PMP(Percona Monitoring Plugin) ：Percona之前的監控是以Plugin或Template的方式加載到其他的監控軟體上，他有支援Zabbix、Nagios和Cacti等3個常用的監控軟體，詳細的介紹可以參考官網： Percona Monitoring Plugins MEM(MySQL Enterprise Monitor) ：官方提供的監控軟體，需購企業版才能使用此功能，可以監控DB內的狀況和InnoDB、NDB、Replication等的內容，另外還可以監控作業系統上的部份內容，例如硬碟、CPU、RAM、網路…等使用狀況，除了監控之外，還有Query Analyzer及發送告警功能，詳細的介紹參考官網： MySQL Enterprise Monitor PMM(Percona Monitoring and Management) ：它是一個用於管理及監控MySQL及MongoDB效能的開源平台，它提供了對MyISAM、InnoDB、TokuDB和PXC/Glarera的監控，另外也提供了與MEM類似的Query Analytics的功能，可以檢視執行了哪些SQL指令，並對執行效能較差的語法進行優化；針對作業系統的部份也提供了硬碟、網路、CPU和RAM的監控，特別的是它提供了Context switches、Processes和interrupts的監控，Context Switches可以看到CPU上下切換文的狀況，Processes可以方便了解系統有多少程序在等待I/O，這3個是MEM沒有提供的。詳細內容參考官方： Percona Monitoring and Management 架構說明： MEM架構 MEM是由Java+Apache Tomcat+MySQL組成的監控軟體 主要安裝Service Manager(也可稱Monitor Server)它有內建一個Agent可以讓你遠端監控 或者是另外在MySQL Server上安裝Agent軟體，其差別在於能否搜集作業系統上的資訊，裝了Agent才能在作業系統上搜集資訊 而DB端的資訊會透過本機或Service Manager的Agent，連到DB裡的Performance Schema中搜集資訊，再儲存到Servi
閱讀完整內容

MySQL Router 設定檔說明

設定檔範例： 　 　 　 [DEFAULT] logging_folder  = /opt/mysql-router/log plugin_folder   = /opt/mysql-router/lib/mysqlrouter runtime_folder  = /opt/mysql-router/run config_folder   = /opt/mysql-router [logger] level = INFO ## these section are only for standalone [routing:read_write] bind_address    = 192.168.56.107 bind_port       = 7001 destinations    = 192.168.56.102:3306,192.168.56.102:3307 mode            = read-write connect_timeout    = 5 max_connections   = 100 [routing:read_only] bind_address    = 192.168.56.107 bind_port       = 7002 destinations    = 192.168.56.102:3308,192.168.56.102:3309 mode            = read-only connect_timeout    = 1 max_connections   = 100 ## these section are used for Fabric [fabric_cache:my_fabric] address    = 192.168.56.101 user         = fabric [routing:fabric_rw] bind_port       = 7001 mode            = read-write destinations    = fabric+cache://my_fabric/group/mygroup1 [routing:fabric_ro] bind_port       = 7002
閱讀完整內容