2. 程式人生 > >MongDB叢集容災方案步驟

MongDB叢集容災方案步驟

阿新 • • 發佈：2018-11-19

MongoDB複製集
優/特點
支援大資料量、高擴充套件性、高效能、靈活資料模型、高可用性。
同步機制
資料複製的目的是使資料得到最大的可用性，避免單點故障引起的整站不能訪問的情況的發生，Mongodb的副本集在同一時刻只有一臺伺服器是可以寫的，副本集的主從複製也是一個非同步同步的過程，是slave端從primary端獲取日誌，然後在自己身上完全順序的執行日誌所記錄的各種操作（該日誌是不記錄查詢操作的），這個日誌就是local資料庫中的oplog.rs表，預設在64位機器上這個表是比較大的，佔磁碟大小的5%，oplog.rs的大小可以在啟動引數中設定：--oplogSize 1000,單位是M。

鑑於雙機房容災意外情況可能放生，本方案選擇故障時人工介入轉移或恢復，不加入仲裁節點。其中A機房為主機房一個primary+2個Secondary節點，B機房作為災備機房，2個Secondary節點。最壞當主機房掛掉時通過權重來啟動B機房某節點為Primary，繼續提供服務。
環境規劃
A機房 角色 B機房 角色
192.168.70.214 Primary 192.168.71.214 Secondary 3 複製集節點 3
192.168.70.215 Secondary 1 複製集節點 1 192.168.71.215 Secondary 4 複製集節點 4
192.168.70.216 Secondary 2 複製集節點 2

架構示意圖
其中下面是主機房斷電斷網時的故障轉移示意圖。

安裝配置
這裡所有節點目錄建立一致，方便管理維護，從配置檔案來判斷各節點的角色。
建立目錄
--為MongoDB建立軟體、資料、日誌目錄，預設情況下它將資料儲存在/mgdata
[[email protected] /]# mkdir -p /mgdb/mongodbtest/replset/data
[[email protected] /]# mkdir /mgdata
[[email protected] /]# mkdir /mglog

上傳介質
sftp> cd /mgdb
sftp> put mongodb-linux-x86_64-2.2.3.tgz.tar

解壓
[[email protected] /]# cd /mgdb
$ tar -xvf mongodb-linux-x86_64-2.2.3.tgz.tar
[[email protected] mgdb]# mv mongodb-linux-x86_64-2.2.3 mongodb

服務啟動
每個節點都要執行
cd /root/mongodb/bin

192.168.70.214
/root/mongodb/bin/mongod --replSet repset --port 27017 --dbpath /root/data27011 --oplogSize 2048 --logpath /root/log27011/log27011.log &
./mongo 192.168.70.214:27017

192.168.70.215
/root/mongodb/bin/mongod --replSet repset --port 27017 --dbpath /root/data27012 --oplogSize 2048 --logpath /root/log27012/log27012.log &
./mongo 192.168.70.215:27017

192.168.70.216
/root/mongodb/bin/mongod --replSet repset --port 27017 --dbpath /root/data27013 --oplogSize 2048 --logpath /root/log27013/log27013.log &
./mongo 192.168.70.216:27017

192.168.71.214
/root/mongodb/bin/mongod --replSet repset --port 27017 --dbpath /root/data27017 --oplogSize 2048 --logpath /root/log27017/log27017.log &
./mongo 192.168.71.214:27017

192.168.71.215
/root/mongodb/bin/mongod --replSet repset --port 27017 --dbpath /root/data27018 --oplogSize 2048 --logpath /root/log27018/log27018.log &
./mongo 192.168.71.215:27017

分別通過 tail -f /root/log27011/log27011.log 來觀察分析個節點執行情況
複製集配置
在任何一臺mongodb例項上登入，進入admin庫，執行config命令，配置相應權重
[[email protected] bin]# pwd
/root/mongodb/bin
[[email protected] bin]# ./mongo 192.168.70.214:27017
MongoDB shell version: 2.2.3
connecting to: test
Welcome to the MongoDB shell.
For interactive help, type "help".
For more comprehensive documentation, see
http://docs.mongodb.org/
Questions? Try the support group
http://groups.google.com/group/mongodb-user
> use admin
switched to db admin
> config = { _id:"repset", members:[
... {_id:0,host:"192.168.70.214:27017",priority:10},
... {_id:1,host:"192.168.70.215:27017",priority:7},
... {_id:2,host:"192.168.70.216:27017",priority:6},
... {_id:3,host:"192.168.71.214:27017",priority:9}]
... {_id:4,host:"192.168.71.215:27017",priority:8}]
... }
{
"_id" : "repset",
"members" : [
{
"_id" : 0,
"host" : "192.168.70.214:27017",
"priority" : 10
},
{
"_id" : 0,
"host" : "192.168.70.215:27017",
"priority" : 7
},
{
"_id" : 0,
"host" : "192.168.70.216:27017",
"priority" : 6
},
{
"_id" : 1,
"host" : "192.168.71.214:27017",
"priority" : 9
},
{
"_id" : 2,
"host" : "192.168.71.215:27017",
"priority" : 8
}
]
}
--檢視
repset:PRIMARY> rs.conf()
{
"_id" : "repset",
"version" : 38349,
"members" : [
{
"_id" : 4,
"host" : "192.168.71.214:27017",
"priority" : 9
},
{
"_id" : 5,
"host" : "192.168.71.215:27017",
"priority" : 8
},
{
"_id" : 6,
"host" : "192.168.70.214:27017",
"priority" : 10
},
{
"_id" : 7,
"host" : "192.168.70.215:27017",
"priority" : 7
},
{
"_id" : 8,
"host" : "192.168.70.216:27017",
"priority" : 6
}
]
}
初始化副本集配置
> rs.initiate(config);
{
"info" : "Config now saved locally. Should come online in about a minute.",
"ok" : 1
}
初始需要一點時間同步
檢視叢集節點狀態
repset:PRIMARY> rs.status()
{
"set" : "repset",
"date" : ISODate("2018-11-09T07:55:04Z"),
"myState" : 1,
"members" : [
{
"_id" : 4,
"name" : "192.168.71.214:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 1104,
"optime" : Timestamp(1541749003000, 1),
"optimeDate" : ISODate("2018-11-09T07:36:43Z"),
"lastHeartbeat" : ISODate("2018-11-09T07:55:03Z"),
"pingMs" : 0
},
{
"_id" : 5,
"name" : "192.168.71.215:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 1104,
"optime" : Timestamp(1541749003000, 1),
"optimeDate" : ISODate("2018-11-09T07:36:43Z"),
"lastHeartbeat" : ISODate("2018-11-09T07:55:03Z"),
"pingMs" : 0
},
{
"_id" : 6,
"name" : "192.168.70.214:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 1680,
"optime" : Timestamp(1541749003000, 1),
"optimeDate" : ISODate("2018-11-09T07:36:43Z"),
"self" : true
},
{
"_id" : 7,
"name" : "192.168.70.215:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 1104,
"optime" : Timestamp(1541749003000, 1),
"optimeDate" : ISODate("2018-11-09T07:36:43Z"),
"lastHeartbeat" : ISODate("2018-11-09T07:55:03Z"),
"pingMs" : 0
},
{
"_id" : 8,
"name" : "192.168.70.216:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 1104,
"optime" : Timestamp(1541749003000, 1),
"optimeDate" : ISODate("2018-11-09T07:36:43Z"),
"lastHeartbeat" : ISODate("2018-11-09T07:55:03Z"),
"pingMs" : 0
}
],
"ok" : 1
}
repset:PRIMARY>

檢視後臺日誌
[[email protected]_master ~]# tail -f /mgdata/mongodb/log27017/mongod.log
驗證複製集資料一致性
先進去主庫primary的mongodb上，錄入資料
如
repset:PRIMARY> use dinpay
switched to db dinpay
repset:PRIMARY> db.dinpay.insert({"test1108":"xiawu1"})
repset:PRIMARY> db.getMongo().setSlaveOk();

去另一個備庫上驗證資料
repset:SECONDARY> db.dinpay.find()
{ "_id" : ObjectId("5bd676e97e238f7b0dddfb0d"), "MongoDB TEST" : "dinpay" }
{ "_id" : ObjectId("5bd823b65b237ec32e664db2"), "mdbtest" : "zgy20181030" }
{ "_id" : ObjectId("5be53e2c60074628c8509830"), "test1108" : "xiawu1" }

斷電斷網模擬
斷電：直接kill mongdb程序
斷網：開啟某一機房的防火牆限制機房間通訊
B機房斷電斷網
192.168.71.214、192.16871.215斷電斷網 後個節點狀態
repset:PRIMARY> rs.status()
{
"set" : "repset",
"date" : ISODate("2018-11-09T08:02:36Z"),
"myState" : 1,
"members" : [
{
"_id" : 4,
"name" : "192.168.71.214:27017",
"health" : 0,
"state" : 8,
"stateStr" : "(not reachable/healthy)",
"uptime" : 0,
"optime" : Timestamp(1541750316000, 1),
"optimeDate" : ISODate("2018-11-09T07:58:36Z"),
"lastHeartbeat" : ISODate("2018-11-09T08:01:59Z"),
"pingMs" : 0,
"errmsg" : "socket exception [CONNECT_ERROR] for 192.168.71.214:27017"
},
{
"_id" : 5,
"name" : "192.168.71.215:27017",
"health" : 0,
"state" : 8,
"stateStr" : "(not reachable/healthy)",
"uptime" : 0,
"optime" : Timestamp(1541750316000, 1),
"optimeDate" : ISODate("2018-11-09T07:58:36Z"),
"lastHeartbeat" : ISODate("2018-11-09T08:01:57Z"),
"pingMs" : 0,
"errmsg" : "socket exception [CONNECT_ERROR] for 192.168.71.215:27017"
},
{
"_id" : 6,
"name" : "192.168.70.214:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 2132,
"optime" : Timestamp(1541750316000, 1),
"optimeDate" : ISODate("2018-11-09T07:58:36Z"),
"self" : true
},
{
"_id" : 7,
"name" : "192.168.70.215:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 1556,
"optime" : Timestamp(1541750316000, 1),
"optimeDate" : ISODate("2018-11-09T07:58:36Z"),
"lastHeartbeat" : ISODate("2018-11-09T08:02:35Z"),
"pingMs" : 0
},
{
"_id" : 8,
"name" : "192.168.70.216:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 1556,
"optime" : Timestamp(1541750316000, 1),
"optimeDate" : ISODate("2018-11-09T07:58:36Z"),
"lastHeartbeat" : ISODate("2018-11-09T08:02:35Z"),
"pingMs" : 0
}
],
"ok" : 1
}
repset:PRIMARY>

結論：A機房執行正常。
A機房斷電斷網
192.168.70.214(PRI)、192.168.70.215、192.168.70.216

 

登入B機房任一臺節點強制reconfig恢復副本集，僅保留活動著的節點
repset:SECONDARY> use admin
switched to db admin
--檢視現有配置，其中70網段3個節點都已死掉了
repset:SECONDARY> cfg=rs.conf()
{
"_id" : "repset",
"version" : 79,
"members" : [
{
"_id" : 4,
"host" : "192.168.71.214:27017",
"priority" : 10
},
{
"_id" : 5,
"host" : "192.168.71.215:27017",
"priority" : 9
},
{
"_id" : 7,
"host" : "192.168.70.214:27017",
"priority" : 11
},
{
"_id" : 8,
"host" : "192.168.70.215:27017",
"priority" : 6
},
{
"_id" : 13,
"host" : "192.168.70.216:27017",
"priority" : 5
}
]
}
--只保留活著的節點
repset:SECONDARY> cfg.members = [cfg.members[0], cfg.members[1]]
[
{
"_id" : 4,
"host" : "192.168.71.214:27017",
"priority" : 10
},
{
"_id" : 5,
"host" : "192.168.71.215:27017",
"priority" : 9
}
]
--強制啟動並新產生一個PRIMARY組成2節點的備份集
repset:SECONDARY> rs.reconfig(cfg, {force :true })
{ "ok" : 1 }
repset:SECONDARY> rs.status()
{
"set" : "repset",
"date" : ISODate("2018-11-09T03:45:29Z"),
"myState" : 1,
"members" : [
{
"_id" : 4,
"name" : "192.168.71.214:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 69133,
"optime" : Timestamp(1541663971000, 1),
"optimeDate" : ISODate("2018-11-08T07:59:31Z"),
"self" : true
},
{
"_id" : 5,
"name" : "192.168.71.215:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 8,
"optime" : Timestamp(1541663971000, 1),
"optimeDate" : ISODate("2018-11-08T07:59:31Z"),
"lastHeartbeat" : ISODate("2018-11-09T03:45:29Z"),
"pingMs" : 0
}
],
"ok" : 1
}
repset:PRIMARY>
--檢查資料，先前資料仍存在
repset:PRIMARY> use test
switched to db test
repset:PRIMARY> show collections
system.indexes
test
Testdb
--狀態查詢
repset:PRIMARY> rs.conf()
{
"_id" : "repset",
"version" : 38342,
"members" : [
{
"_id" : 4,
"host" : "192.168.71.214:27017",
"priority" : 10
},
{
"_id" : 5,
"host" : "192.168.71.215:27017",
"priority" : 9
}
]
}

結論：B機房強制啟動，變成新的備份集
儘管已產生新的備份集，但不能保證斷電斷網瞬間存在舊PRIMARY未同步至各從節點而導致資料丟失的可能性。

恢復初始狀態
Kill並重啟A機房個節點mongdb

192.168.70.214
/root/mongodb/bin/mongod --replSet repset --port 27017 --dbpath /root/data27011 --oplogSize 2048 --logpath /root/log27011/log27011.log &
192.168.70.215
/root/mongodb/bin/mongod --replSet repset --port 27017 --dbpath /root/data27012 --oplogSize 2048 --logpath /root/log27012/log27012.log &
192.168.70.216
/root/mongodb/bin/mongod --replSet repset --port 27017 --dbpath /root/data27013 --oplogSize 2048 --logpath /root/log27013/log27013.log &

將A機房個節點加入新備份集（B機房），並對A機房某節點提權升為新的PRIMARY，恢復至斷電斷網前的狀態
epset:PRIMARY> use admin
switched to db admin
repset:PRIMARY> cfg=rs.conf()
repset:PRIMARY> cfg.members[XX].priority = 8
8
repset:PRIMARY> rs.reconfig(cfg)


////////////////////////////////////////////////////////////////////////////////
主機房掛了再恢復測試。。。比上面恢復詳細
--A機房(主機房) 192.168.70.214（主）/192.168.70.215/192.168.70.216斷電斷網，B機房強制重啟後成為了新的叢集，現在將2機房重新回到初始狀態，首先要確認之前各節點都是什麼角色
--加節點
--設權重
repset:PRIMARY> use admin
switched to db admin
repset:PRIMARY> rs.add("192.168.70.214:27017")
{ "ok" : 1 }
repset:PRIMARY> rs.add("192.168.70.215:27017")
{ "ok" : 1 }
repset:PRIMARY> rs.add("192.168.70.216:27017")
{ "ok" : 1 }
repset:PRIMARY>
repset:PRIMARY> cfg=rs.conf()
{
"_id" : "repset",
"version" : 63044,
"members" : [
{
"_id" : 4,
"host" : "192.168.71.214:27017",
"priority" : 9
},
{
"_id" : 5,
"host" : "192.168.71.215:27017",
"priority" : 8
},
{
"_id" : 6,
"host" : "192.168.70.214:27017"
},
{
"_id" : 7,
"host" : "192.168.70.215:27017"
},
{
"_id" : 8,
"host" : "192.168.70.216:27017"
}
]
}
repset:PRIMARY> cfg.members[2].priority = 11
11
repset:PRIMARY> cfg.members[3].priority = 6
6
repset:PRIMARY> cfg.members[4].priority = 5
5
repset:PRIMARY> rs.reconfig(cfg)
Mon Nov 12 16:04:10 DBClientCursor::init call() failed
Mon Nov 12 16:04:10 query failed : admin.$cmd { replSetReconfig: { _id: "repset", version: 63045, members: [ { _id: 4, host: "192.168.71.214:27017", priority: 9.0 }, { _id: 5, host: "192.168.71.215:27017", priority: 8.0 }, { _id: 6, host: "192.168.70.214:27017", priority: 11.0 }, { _id: 7, host: "192.168.70.215:27017", priority: 6.0 }, { _id: 8, host: "192.168.70.216:27017", priority: 5.0 } ] } } to: 192.168.71.214:27017
Mon Nov 12 16:04:10 trying reconnect to 192.168.71.214:27017
Mon Nov 12 16:04:10 reconnect 192.168.71.214:27017 ok
reconnected to server after rs command (which is normal)

repset:PRIMARY>
Mon Nov 12 16:04:29 Socket recv() errno:104 Connection reset by peer 192.168.71.214:27017
Mon Nov 12 16:04:29 SocketException: remote: 192.168.71.214:27017 error: 9001 socket exception [1] server [192.168.71.214:27017]
Mon Nov 12 16:04:29 DBClientCursor::init call() failed
Mon Nov 12 16:04:29 query failed : admin.$cmd { replSetGetStatus: 1.0, forShell: 1.0 } to: 192.168.71.214:27017
>
Mon Nov 12 16:04:37 trying reconnect to 192.168.71.214:27017
Mon Nov 12 16:04:37 reconnect 192.168.71.214:27017 ok
repset:SECONDARY>
repset:SECONDARY> rs.conf()
{
"_id" : "repset",
"version" : 63045,
"members" : [
{
"_id" : 4,
"host" : "192.168.71.214:27017",
"priority" : 9
},
{
"_id" : 5,
"host" : "192.168.71.215:27017",
"priority" : 8
},
{
"_id" : 6,
"host" : "192.168.70.214:27017",
"priority" : 11
},
{
"_id" : 7,
"host" : "192.168.70.215:27017",
"priority" : 6
},
{
"_id" : 8,
"host" : "192.168.70.216:27017",
"priority" : 5
}
]
}
repset:SECONDARY>
repset:SECONDARY> rs.status()
{
"set" : "repset",
"date" : ISODate("2018-11-12T08:05:16Z"),
"myState" : 2,
"syncingTo" : "192.168.70.214:27017",
"members" : [
{
"_id" : 4,
"name" : "192.168.71.214:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 19426,
"optime" : Timestamp(1542009850000, 1),
"optimeDate" : ISODate("2018-11-12T08:04:10Z"),
"errmsg" : "syncing to: 192.168.70.214:27017",
"self" : true
},
{
"_id" : 5,
"name" : "192.168.71.215:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 50,
"optime" : Timestamp(1542009850000, 1),
"optimeDate" : ISODate("2018-11-12T08:04:10Z"),
"lastHeartbeat" : ISODate("2018-11-12T08:05:14Z"),
"pingMs" : 0,
"errmsg" : "syncing to: 192.168.70.214:27017"
},
{
"_id" : 6,
"name" : "192.168.70.214:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 64,
"optime" : Timestamp(1542009850000, 1),
"optimeDate" : ISODate("2018-11-12T08:04:10Z"),
"lastHeartbeat" : ISODate("2018-11-12T08:05:14Z"),
"pingMs" : 1
},
{
"_id" : 7,
"name" : "192.168.70.215:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 64,
"optime" : Timestamp(1542009850000, 1),
"optimeDate" : ISODate("2018-11-12T08:04:10Z"),
"lastHeartbeat" : ISODate("2018-11-12T08:05:14Z"),
"pingMs" : 0,
"errmsg" : "syncing to: 192.168.70.214:27017"
},
{
"_id" : 8,
"name" : "192.168.70.216:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 64,
"optime" : Timestamp(1542009850000, 1),
"optimeDate" : ISODate("2018-11-12T08:04:10Z"),
"lastHeartbeat" : ISODate("2018-11-12T08:05:14Z"),
"pingMs" : 1,
"errmsg" : "syncing to: 192.168.70.214:27017"
}
],
"ok" : 1
}
repset:SECONDARY>

相關推薦

MongDB叢集容災方案步驟

MongoDB複製集優/特點支援大資料量、高擴充套件性、高效能、靈活資料模型、高可用性。同步機制資料複製的目的是使資料得到最大的可用性，避免單點故障引起的整站不能訪問的情況的發生，Mongodb的副本集在同一時刻只有一臺伺服器是可以寫的，副本集的主從複製也是一個非同步同步的過程，是slave端從primary

Redis Sentinel叢集雙機房容災實施步驟

概要目標防止雙機房情況下任一個機房完全無法提供服務時如何讓Redis繼續提供服務。架構設計A、B兩機房，其中A機房有一Master一Slave和兩個Sentinel，B機房只有2個Sentinel，如下圖。 初始規劃A機房192.168.71.213 S+哨兵192.168.71.214 M+哨兵B機房19

叢集容災解決方案之Rose HA

Rose是美國ROSE Datasystem公司研發的高可用性系列軟體，Rose HA也稱為基於共享儲存的雙機高可用解決方案。 Rose HA高可用性系統解決方案以低成本且簡便的方式，實現了兩個節點的Cluster環境.客戶只需要在原有的單機系統上增加一臺伺服器、一個共享儲存裝置，通過Rose基於共

OceanBase資料庫高可用及容災方案詳細介紹

1     前言 眾所周知，作為生產系統中極為關鍵的核心軟體，資料庫產品的高可用性一直是使用者極為關注的功能點。尤其是在金融這樣一個特殊的領域裡，無論是從監管的要求來看，還是從業務需求本身來看，都需要提供24*7持續不間斷的服務，這就對金融行業中資料庫產品的高可用性提出了很

淺談基於VCS+VVR+GCO組合的資料容災方案

       容災技術以往只有在對資訊資料特別敏感的金融和通訊領域應用，但隨著容災技術的發展和企業對資訊資料的重視層度的提高，整個資訊市場也就對災難場景下業務系統的快速恢復和資料保護提出了需求。現有的容災技術包含以下幾類：        1. 基於硬體平臺的資料容災解決方案，如IBM PPRC，EM

實戰:sqlserver 2008 R2容災方案:另一種思路-1

自己的定義的容災方案，可以根據自己的需要自己定義. 1.源資料庫備份資料 說明: 使用方法:exec master.dbo.fullbackup1 's:\backup','suzhou','full' 0.備份型別只能是full、diff或log，資料庫名不能為空

利用HDFS實現ElasticSearch7.2容災方案

# 利用HDFS實現ElasticSearch7.2容災方案 [toc] # 前言 ​ Elasticsearch 副本提供了高可靠性，它們讓你可以容忍零星的節點丟失而不會中斷服務。但是，副本並不提供對災難性故障的保護。對這種情況，就需要的是對叢集真正的備份（在某些東西確實出問題的時候有一個完整的拷貝）

輕鬆上雲系列之五：阿里雲容災與備份方案

災備能力是各類雲產品能力與穩定性非常重要的衡量指標，猶記得某友商雲因為資料丟失被索賠1000多萬的慘痛教訓。保障企業業務穩定、IT系統功能正常、資料安全十分重要。因此可以同時保障資料備份與系統、應用容災的災備解決方案應勢而生，且發展迅速。 下面我們來看，在阿里雲和阿里雲產品都有哪些災備的解決方案和能力。

redis叢集實現(六) 容災與宕機恢復

實現叢集，一個重要的保證就是高可用性，要在各種軟體和硬體的故障情況下仍然能夠提供服務。一般來說有兩種解決思路，一種是每一個節點互相之間都會進行資料互動以及監控，出現故障的時候，各個節點都可以做協調任務。另一種就是增加一個協調元件來對叢集進行實時監控以及故障處理。現在使用比較

CentOS 7上搭建安全、容災、高可用的etcd叢集_Kubernetes中文社群

【編者的話】etcd 是 CoreOS 團隊發起的開源專案，基於 Go 語言實現，做為一個分散式鍵值對儲存，通過分散式鎖，leader選舉和寫屏障(write barriers)來實現可靠的分散式協作。 本文目標是部署一個基於TLS（Self-signed certificates）的安全、快

從IT應用架構角度，暢談雙活資料中心容災解決方案

本文根據朱祥磊老師在〖5月6日DBAplus社群濟南資料庫技術沙龍〗現場演講內容整理而成。 講師介紹：朱祥磊 運營商系統架構師 負責業務支撐系統架構規劃和建設。獲國家級創新獎1項、通訊行業級科技進步獎2項、移動集團級業務服務創新獎3項，申請發明專利13項。 為什麼要講雙活資料中心？從應用系統和

HBase的資料備份容災遷移方案：Distcp，CopyTable，Export/Import，Snapshot，Replication

HBase的資料備份或者容災方案有這幾種：Distcp，CopyTable，Export/Import，Snapshot，Replication，以下分別介紹（以下描述的內容均是基於0.94.20版本）。 一、Distcp    在使用distcp命令copy hdfs檔

為資料安全而生，阿里雲容災備份方案場景實踐解析

摘要： 數字經濟時代，資料正以超出想象的速度快速增長。短短几年，資料量已經從TB級別躍升到PB乃至ZB級別。 數字經濟時代，資料正以超出想象的速度快速增長。短短几年，資料量已經從TB級別躍升到PB乃至ZB級別。 根據相關研究機構調查結果顯示，2017 年全年資料總量將超過

elasticsearch叢集擴容和容災

elasticsearch專欄：https://www.cnblogs.com/hello-shf/category/1550315.html 一、叢集健康 Elasticsearch 的叢集監控資訊中包含了許多的統計資料，其中最為重要的一項就是叢集健康，它在 status 欄位中展示為 green 、

備份容災數據 一致性問題

數據一致性一致性問題一般是指數據前後之間的邏輯關系是否一致（正確和完整）。簡單舉例來說，比如A用戶正在寫數據N的時候，B用戶開始讀數據N，由於A用戶剛寫了一半，所以B用戶讀的數據就不是前後邏輯一致性的，這就是一致性問題的一種。 一致性問題在各個領域都存在，提的比較多的是分布式存儲的一致性問題，數據庫的一致性問

【大話存儲】學習筆記（17章），數據容災

交互 領域 傳輸 基本 備份系統 掛載共享 調制 出現 通信 數據容災 數據備份系統只能保證實際上被安全復制了一份，如果生產系統故障，必須將備份數據盡快的恢復到生產系統中繼續生產，就叫容災。 容災可以分為四個級別： 數據級容災：只是將生產站點的數據同步到遠端。 與應用

VMWare“長模式不兼容”解決方案

vmwareVMWare“長模式不兼容”解決方案 平臺：HP8770CPU：core i5OS : win7x64 參考文獻鏈接:http://blog.sina.cn/dpool/blog/s/blog_63b15fc901019wkn.html 情景描述：在使用Windows7 64位操作系統時，無法運行

記錄一次郵件容災恢復過程

數據庫修改 Eseutil Exchange容災恢復 背景介紹 客戶目前使用的是Exchange Server 2013,兩前兩後，數據盤是存儲掛載過來的，郵件備份使用的是NBU，由於機房漏水，導致存儲服務器宕機。導致絕大部分數據丟失。 Exchange恢復過程 使用新存儲重新劃分磁盤，並使用N

Win2012R2 Hyper-V初級教程15 -- 基於Kerberos與CA證書的系統容災（中）

系統/運維 Windows 二、基於CA證書的HTTPS復制 ??????? 剛剛看了一下關於基於Kerberos與CA證書的系統容災（上）還是2017-08-31寫的，到現在半年過去了，懶癌太重了，一直沒有更新，從今天起將逐步更新完初級教程，希望能夠有更多的博友了解並學習微軟的虛擬化技術。前面我們說

46.異地（Azure）容災-準備工作

雲計算 雲平臺 之前給點擊介紹了恢復保管庫（ARS）的Backup Service，實現數據災備解決方案，在這裏我將給大家介紹ARS還可以實現計算機環境災備解決方案以及遷移區域和本地業務系統上Azure雲的解決方案，這裏主要使用的是ARS裏的Site Recovery功能實現對計算機環境的災備解決方案