Orchestrator管理mysql複製

時間  2019-12-07
標籤 orchestrator 管理 mysql 複製 欄目 MySQL 简体版
原文   原文鏈接

.................................................................................
系統:centos7
Mysql:5.7.22
IP：192.168.225.130，端口3306（存放orchestrator的擴普狀態）
M1：主：192.168.225.128：3306 —— 從:192.168.225.129：3306
M2：主：192.168.225.128：3307 —— 從:192.168.225.129：3307
.................................................................................node

1、簡介

orchestrator – 對 MySQL 複製拓撲管理並可視化的工具。
支持：mysql

 檢測和審查複製集羣
 安全拓撲重構:轉移服務於另一臺計算機的系統拓撲S
 整潔的拓撲可視化
 複製問題可視化
 經過簡單的拖拽修改拓撲
 維護模式聲明和執行
 審計操做

重構拓撲只須要簡單的拖拽。Orchestrator 會保證安全,而且禁止非法複製拓撲。
Orchestrator是高可用性管理工具，它提供了發現MySQL環境的複製拓撲能力，經過上下連接來識別主從。它也能夠經過GUI重構複製拓撲結構，提供一個拖放界面將從設備提高爲主設備，這是一個很是安全的操做。事實上，Orchestrator拒絕任何非法操做，以避免破壞系統。
　　最後，Orchestrator在節點遭遇失敗時能夠支持恢復，由於它使用狀態的概念智能選擇正確的恢復方法，並決定使用適當的主升級過程。linux

2、安裝配置步驟

操做步驟git

步驟 一、下載安裝

網址：https://github.com/github/orc...github

# wget https://github.com/github/orchestrator/releases/download/v3.0.11/orchestrator-3.0.11-1.x86_64.rpm
# wget https://github.com/github/orchestrator/releases/download/v3.0.11/orchestrator-client-3.0.11-1.x86_64.rpm 
安裝：# rpm -ivh orchestrator-3.0.11-1.x86_64.rpm
# rpm -ivh orchestrator-client-3.0.11-1.x86_64.rpm
安裝完成後，目錄在/usr/local/orchestrator

步驟 二、添加host

在130上面添加host，vim /etc/hosts
192.168.225.128 vm-test1
192.168.225.129 vm-test2
192.168.225.130 vm-test3web

步驟三、 Mysql主從上面配置文件配置report_host

DiscoverByShowSlaveHosts": ture 這種狀況下，必須配置report_host
$ vim /etc/my_3306.cnf
report_host=192.168.225.128 //ip爲自身的ip
說明:不加report_host ，show slave hosts 不會顯示host，會致使程序報錯的sql

report_host爲只讀參數，必須重啓纔可生效
說明：
DiscoverByShowSlaveHosts": false 也能夠，這樣就不須要設置report_host了數據庫

步驟4 、130：3306上開通orchestrator的權限，存放擴譜狀態：

CREATE DATABASE IF NOT EXISTS orchestrator;
mysql>  GRANT ALL PRIVILEGES ON `orchestrator`.* TO 'orche'@'127.0.0.1' IDENTIFIED BY '000000';

步驟五、M:3306-S:3306/3307主從複製開通orchestrator的帳戶

M1/M2: mysql> GRANT SUPER, PROCESS, REPLICATION SLAVE, RELOAD ON *.* TO 'orche'@'192.168.225.130' IDENTIFIED BY '000000';
Mysql> GRANT SELECT ON mysql.slave_master_info TO 'orche'@'192.168.225.130';
說明：On MySQL 5.6 and above, and if using master_info_repository = 'TABLE', let orchestrator have access to the mysql.slave_master_infotable. 

步驟六、修改配置文件(存儲orche的擴譜狀態的mysql3307用戶名密碼)

# cd /usr/local/orchestrator/
# cp orchestrator-sample.conf.json orchestrator.conf.json
# vim orchestrator.conf.json
  "MySQLOrchestratorHost": "127.0.0.1",
  "MySQLOrchestratorPort": 3306,
  "MySQLOrchestratorDatabase": "orchestrator",
  "MySQLOrchestratorUser": "orche",
  "MySQLOrchestratorPassword": "000000",

說明：配置文件放在/etc/orchestrator.conf.json，默認會調用json

步驟七、啓動orchestrator

$ cd /usr/local/orchestrator/
$ nohup orchestrator http &vim

步驟八、顯示已知的集羣

$ orchestrator -c clusters //第一次執行成功後庫orchestrator中就出現不少表，之後執行會顯示出已經知道的集羣拓撲
$ orchestrator -c clusters --config=/path/to/config.file //若配置文件在其餘路徑

clipboard.png

步驟九、發現mysql hosts（也能夠編輯web頁添加）

$ orchestrator -c discover -i vm-test1:3306
$ orchestrator -c discover -i vm-test1:3307
$ orchestrator -c discover -i192.168.225.128:3306
說明：該命令會向上檢測master，向下檢測slave。 -i 表明實例，必須跟着hostname:port
步驟 10web頁面

Web頁面：http://192.168.225.130:3000

clipboard.png

3、配置config

一、輪詢時間設置

InstancePollSeconds，默認是1分鐘輪詢一次服務器

二、Configuration: discovery, name resolving

{
  "HostnameResolveMethod": "default",
  "MySQLHostnameResolveMethod": "@@hostname",
}
"HostnameResolveMethod": "cname": do CNAME resolving on hostname //主機名上的CNAME解析碼
"HostnameResolveMethod": "default": no special resolving via net protocols 
"MySQLHostnameResolveMethod": "@@hostname": issue a select @@hostname
"MySQLHostnameResolveMethod": "@@report_host": issue a select @@report_host, requires report_host to be configured
"HostnameResolveMethod": "none" and "MySQLHostnameResolveMethod": "": do nothing. Never resolve. This may appeal to setups where everything uses IP addresses at all times.

三、Configuration: discovery, classifying servers

{
  "SlaveLagQuery": "select absolute_lag from meta.heartbeat_view",
  "DetectClusterAliasQuery": "select ifnull(max(cluster_name), '') as cluster_alias from meta.cluster where anchor=1",
  "DetectClusterDomainQuery": "select ifnull(max(cluster_domain), '') as cluster_domain from meta.cluster where anchor=1",
  "DataCenterPattern": "",
  "DetactDataCenterQuery": "select substring_index(substring_index(@@hostname, '-',3), '-', -1) as dc",
  "PhysicalEnvironmentPattern": "",
}

"SlaveLagQuery": 默認狀況下，協調器使用SHOW SLAVE STATUS並接受1秒粒度值來表示延遲。然而，這種延遲並無考慮鏈式複製時的級聯延遲。許多人使用自定義心跳機制，例如pt-heartbeat。這就提供了從master到sub-second的「絕對」延遲。
"DetectClusterAliasQuery": 可讓orchestrator知道集羣名稱的查詢

四、Configuration: recovery

{
  "RecoveryPeriodBlockSeconds": 3600,
  "RecoveryIgnoreHostnameFilters": [],
  "RecoverMasterClusterFilters": [
    "thiscluster",
    "thatcluster"
  ],
  "RecoverIntermediateMasterClusterFilters": [
    "*"
  ],
}

Orchestrator將自動恢復全部集羣的中間主失敗
Orchestrator將自動恢復兩個指定集羣的主故障;其餘集羣的主集羣不會自動恢復。能夠人爲進行恢復。
一旦集羣經歷了恢復，orchestrator將在接下來的3600秒(1小時)內阻止自動恢復。這是一種anti-flapping機制。

{
  "ApplyMySQLPromotionAfterMasterFailover": true,
  "MasterFailoverLostInstancesDowntimeMinutes": 10,
  "FailMasterPromotionIfSQLThreadNotUpToDate": true,
  "DetachLostReplicasAfterMasterFailover": true,
}
"ApplyMySQLPromotionAfterMasterFailover": when true, orchestrator will reset slave all and set read_only=0 on promoted master. Default: true

4、經常使用命令

一、顯示已知集羣 ????如何使用ip，而不是hostname

# orchestrator -c clusters
# orchestrator -c clusters --config=/path/to/config.file

二、發現新的實例

# orchestrator -c discover -i 127.0.0.1:3306
# orchestrator -c discover -i 127.0.0.1:3306 --debug --stack

說明：--debug用來調試，--stack會在報錯的地方打印出來追蹤的代碼堆

三、忘記一個實例

# orchestrator -c forget -i 127.0.0.1:22987

若一個slave斷開了，複製不正常，可以使用該命令將其從集羣中去掉

四、打印拓撲實例的ASCII樹

# orchestrator -c topology -i vm-test1:3306

clipboard.png

五、relocate移動一個副本 到 目的地 下做爲副本

# orchestrator -c relocate -i vm-test2:3310 -d vm-test2:3307

clipboard.png 變爲
clipboard.png

# orchestrator -c relocate -i vm-test2:3308 -d vm-test2:3307

clipboard.png 變爲
clipboard.png

六、relocate-replicas 移動一個副本下的全部副本 到 目的地 下做爲副本

# orchestrator -c relocate-replicas -i vm-test1:3307 -d vm-test2:3308

說明：可以使用--pattern來列出要移動的副本，默認爲所有
注意每一個機器上要添加hosts解析

# orchestrator -c relocate-replicas -i vm-test2:3307 --pattern vm-test2:3310 -d vm-test2:3308

七、使實例爲只讀或者只寫

# orchestrator -c set-read-only -i vm-test1:3307
 # orchestrator -c set-writeable -i vm-test1:3307

八、Start/stop slave

$ orchestrator -c stop-slave -i a.replica.8.instance.com
$ orchestrator -c start-slave -i a.replica.8.instance.com
$ orchestrator -c restart-slave -i a.replica.8.instance.com

九、吧副本向上移動，前提:該副本有grandparent

如：有A-B—C能夠變爲 A-B、A-C

# orchestrator -c move-up -i vm-test2:3310

clipboard.png 變爲
clipboard.png

# orchestrator -c move-below -i 127.0.0.1:22988 -d 127.0.0.1:22990 --debug

十、把S2（以及它下面的S22）移動到另外一個S1下面

說明：S2和S1需屬於同一級別

# orchestrator -c move-below -i vm-test2:3308 -d vm-test1:3307 --debug

十一、破壞恢復slave的binlog 座標（gtid不適用）

$ orchestrator -c detach-replica -i a.replica.8.instance.com   //破壞
$ orchestrator -c reattach-replica -i a.replica.8.instance.com //恢復

5、配置orchestrator-client（128/129/130均可）

步驟一、配置環境

# export ORCHESTRATOR_API=http://192.168.225.130:3000/api

步驟二、linux下安裝json解析工具jq

# wget https://github.com/stedolan/jq/releases/download/jq-1.5/jq-1.5.tar.gz 
# tar zxvf jq-1.5.tar.gz
# cd jq
# ./configure && make && sudo make install

步驟三、基礎命令;

1.

# orchestrator-client -c help
# orchestrator-client -c which-api
2.列出master，集羣

詳情，見網址：https://github.com/github/orc...

# orchestrator-client -c api -path clusters 
# orchestrator-client -c clusters-alias      //master，集羣名
//顯示別名爲vm-test1的集羣的master
# orchestrator-client -c which-cluster-master -alias vm-test1 
//顯示別名爲vm-test1的集羣下全部的實例
# orchestrator-client -c which-cluster-instances -alias vm-test1

3.顯示已知集羣

# orchestrator-client -c clusters

//發現、忘記實例

# orchestrator-client -c discover -i vm-test1:3306
# orchestrator-client -c forget -i vm-test1:3306

//列出實例的拓撲結構

# orchestrator-client -c topology -i vm-test1:3307

//relocate命令通用

6、故障轉移

一、手動強制故障轉移,即master downtimed，slave 雙no，可是slave並無提高爲master

# orchestrator-client -c force-master-failover --alias vm-test1:3306
# orchestrator-client -c force-master-failover -i vm-test1:3306

二、優雅的接管master

說明：原M：downtimed，show slave status能夠看到做爲原S的slave，可是爲雙no，由rw變爲ro；
原S：若以前爲ro，接管master後也是ro，show slave status 能夠看到仍是做爲原M的slave，且爲雙yes，

# orchestrator-client -c graceful-master-takeover -i vm-test2:3306 
//（cluster中某個機器host：port，也能夠是vm-test1:3306）
# orchestrator-client -c graceful-master-takeover -i vm-test1 （cluster別名）
Command line: orchestrator-client -c graceful-master-takeover -alias mycluster -s designated.master.to.promote:3306

clipboard.png 變爲

clipboard.png

clipboard.png

7、高可用方式

方式一：synchronous replication backend

含義：假若有3個orchestrator node節點，每個node節點鏈接一個DB，這3個DB作的[galera|xtradb cluster|innodb cluster]，互相通訊保持同步。Orchestrator node節點之間不進行通訊。
Orchestrator/raft：假若有3個orchestrator node節點，每個node節點鏈接一個DB，這3個DB是互相獨立的，不進行通訊。Orchestrator node節點之間經過raft識別進行通訊。

方式二：Orchestrator/raft

一、orchestrator/raft 概述

經過使用協商一致協議，orchestrator節點可以挑選出具備法定人數的領導，這意味着它不是孤立的。
例如，考慮一個3節點orchestrator/raft設置。一般狀況下，三個節點會互相聊天，其中一個節點是穩定的被選出的leader。然而，面對網絡分區，假設節點n1與節點n2和n3分開，能夠保證leader不是n2就是n3。n1將不能成爲leader，由於它沒有法定人數（在一個3節點設置中，仲裁大小是2;在5個節點中設置仲裁大小爲3）
服務節點：設置3個或5個orchestrator節點。其餘數字也是合法的，但至少須要3個。

2.安裝

（1） 、在128/129/130上面分別安裝orchestrator和orchestrator client ，配置文件加上raft，
啓動 # nohup orchestrator http &
"RaftEnabled": true,
"RaftDataDir": "/data/orchestrator",
"RaftBind": "192.168.225.128",
"DefaultRaftPort": 10008,
"RaftNodes": [

"192.168.225.128",
"192.168.225.129",
"192.168.225.130"

]
（2）在須要監控的mysql集羣上給128/129機器受權，以便orche帳戶可訪問
（3）配置orchestrator client

# export ORCHESTRATOR_API="http://192.168.225.130:3000/api http://192.168.225.129:3000/api http://192.168.225.128:3000/api"

配置完client後，client會自動選擇出leader
（4）查看狀態

關閉130的orchestrator，再次查看狀態

三、注意事項

Orchestrator命令行不支持給定的raft設置，由於它直接與底層數據庫交互，不參與raft識別。所以不能確保全部的raft成員均可以看到變動。
若要強制在orchestrator命令行執行命令，可加參數 --ignore-raft-setup，不過最好在leader端執行。

四、Orchestrator service

（1）單一的orchestrator節點擁有領導權，能夠：運行恢復
（2）全部的節點將：
發現（探測）mysql 拓撲
運行故障檢測
記錄監控檢測
（3）非leader 節點不能：
運行任意命令（eg：從新部署、開機停機）
按照人類請求運行恢復
處理客戶端HTTP請求（可是一些端點，如負載均衡器和健康檢查，是有效的）。

五、Orchestrator/raft

（1）添加新節點
雖然DB爲空，不過也不須要作什麼，啓動後，過一段時間便可自動加入raft集羣
也能夠克隆原來的DB，使用備份恢復的方法，爲新後端DB提供數據（沒有必要）。
（2）替換node3
（原來是：node1，node2，node3，使用nodex替換node3）
關閉node3，node1和node2會運行正常，且在node1和node2選擇出一個leader
建立好nodex，配置好後端數據庫
修改node一、node二、nodex中的配置文件，RaftNodes: ["node1", "node2", "nodeX"]
啓動nodex，重啓node一、node2（不重啓node2和3將不會識別出nodex）

8、Pseudo GTID

一、概述

Pseudo GTID是向二進制日誌中注入唯一條目的方法，這樣就能夠在沒有直接鏈接的狀況下使用它們來匹配/同步副本，或者使用主服務器已損壞/死亡的副本。
Pseudo GTID對於沒有GTID的用戶頗有吸引力。Pseudo GTID具備GTID的大部分優勢，但沒有做出GTID所要求的承諾。使用Pseudo gtid，不管使用哪一個MySQL版本，您均可以保留現有的拓撲。

二、優點：

完成master故障轉移。
完成中間master故障轉移。
任意重構，將副本從一個地方遷移到另外一個地方(甚至那些沒有二進制日誌記錄的副本)。
廠商中立;在Oracle和MariaDB上工做，甚至二者的結合。
沒有配置更改。複製設置保持原樣。
沒有承諾。您能夠選擇隨時不使用Pseudo gtid;不要再寫P-GTID了。
P-gtid意味着對運行的副本進行安全的複製:log-slave-updates sync_binlog=1
與MySQL 5.6上的GTID不一樣，服務器不須要運行打開log-slave-updates，不過建議最好打開。

三、開啓P-GTID

{
"AutoPseudoGTID": true,
}
還須要在mysql機器上受權
GRANT DROP ON _pseudo_gtid_.* to 'orchestrator'@'orch_host';
若是想只在特定集羣上開啓P-GTID功能，只需在特定集羣開通權限便可。

四、侷限

（1）不支持 active-active master-master模式
但可支持active-passive master-master模式，Pseudo-GTID支持只注入到active master上
（2）沒有開啓log-slave-update的複本，能夠經過中繼日誌同步。MySQL默認對中繼日誌的強制清除意味着，若是master發生崩潰，副本的中繼日誌也剛剛被清除，而後，在中繼日誌中沒有用於修復拓撲的僞Pseudo-GTID信息。
頻繁注入P-GTID能夠緩解這一問題。咱們每5秒注入一次P-GTID
（3）當副本讀取基於statement的複製relay logs和轉譯基於Row的複製binlog logs，而後，orchestrator經過中繼日誌匹配P-gtid。有關中繼日誌的限制，請參見（2）
（4）不能匹配兩個服務器，其中一個是徹底RBR(接收和寫入基於行的複製日誌)，另外一個是徹底SBR。這種狀況可能發生在 由基於SBR的拓撲遷移到RBR拓撲時；
（5）一個邊界場景下（當從5.6複製到5.7時，5.7向binlog 添加了匿名語句）這時orchestrator知道如何跳過這些語句。然而，若是5.6->5.7複製中斷(eg：master dead)，而且匿名語句是binlog中的最後一條語句，此時，orchestrator沒法匹配服務器。

五、說明：

orchestrator-client -c relocate -i some.server.to.relocate -d under.some.other.server
Relocate命令將自動識別是否開啓了Pseudo_GTID

9、故障檢測

Orchestrator使用總體分析master 和中間master的故障。不一樣於按照多長時間聯繫不到master來判定錯誤，orchestrator。當全部master的副本都贊成沒法鏈接master時，複製拓撲就被破壞了，故障轉移是合理的。
要診斷一個dead master，orchestrator必須：
A.沒法鏈接該master; &&
B.能夠聯接master的副本，並確認副本也不能看到master

一、檢測和恢復

檢測不必定會致使恢復，有些狀況下是不但願恢復的：
A.該集羣不在自動故障轉移列表
B.管理員用戶已經指出，不該該在特定的服務器上進行恢復。
C.用戶禁用了恢復
D.在同一集羣上的上一次恢復在不久前完成，而且anti-flapping發生
E.故障類型認爲不值得恢復。

在特定場景中，檢測後會當即進行恢復，其餘時候，恢復多是在長時間的檢測以後

二、檢測失敗的場景：

（1）dead masterMaster鏈接失敗Master的全部副本都鏈接失敗

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程