【DB寶46】NoSQL數據庫之CouchBase簡介、集群搭建、XDCR同步及備份恢復

本文轉載自查看原文 2021-04-06 09:11 515 MySQL

一、 CouchBase概述
二、復制
- 2.1、復制的概述
- 2.2、Couchbase 中的復制
  - 2.2.1、集群內復制（單集群內復制）
  - 2.2.2、跨數據中心復制（多集群間復制）--XDCR
三、集群docker安裝
四、常見命令
五、CouchBase的備份和恢復
- 5.1、cbback和cbrestore
  - 5.1.1、cbback備份
  - 5.1.2、cbrestore還原數據庫
- 5.2、增量備份

一、 CouchBase概述

1.1、簡述

CouchBase是一款開源的、分布式的、面向文檔的NoSQL數據庫，主要用於分布式緩存和數據存儲領域。能夠通過manage cache提供快速的亞毫米級別的k-v存儲操作，並且提供快速的查詢和其功能強大的能夠指定SQL-like查詢的查詢引擎。Couchbase是一個較新的、發展迅速的nosql數據庫技術。2014年，viber宣布使用couchbase替換mongodb，以適應10億級的用戶量，目前，couchbase已大量運用於生產環境，國內使用的公司主要有新浪，騰訊等。

Couchbase是Apache CouchDB和MemBase這兩個NoSQL數據庫的合並的產物，而memBase是基於Memcached的。因此CouchBase聯合了CouchDB的簡單可靠和Memcached的高性能，以及membase的可擴展性。

Apache CouchDB和CouchBase這兩個NoSQL數據庫，都是開源、免費的NoSQL文檔型數據庫，都使用了JSON作為其文檔格式。Apache CouchDB和CouchBase的相似性極高，但也有不少不同之處。基本上CouchBase結合了Apache CouchDB和MemBase兩種數據庫的功能特性而構建的。CouchDB的面向文檔的數據模型、索引和查詢功能與MemBase分布式鍵值數據模型相結合、高性能、易於擴展、始終保持接通的能力，這就是CouchBase。

簡而言之， CouchBase = CouchDB + MemBase

但是，CouchBase並非CouchDB的新版本，相反，它實際上是MemBase的新版本。CouchBase Server實際上是MemBase Server的新名字。CouchBase並非CouchDB的替代，而是MemBase的替代版本。CouchBase仍然使用了Memcached協議，而沒有使用CouchDB的RESTful風格的API。同時，CouchDB仍然是CouchDB，是Apache旗下的項目，由Apache負責維護和演進。而且，CouchDB並非過時的CouchBase，CouchDB仍然是一個比較活躍的開源項目。而CouchBase是另一個完全獨立的項目。

1.2、CouchDB和CouchBase比對

1.2.1、CouchDB和CouchBase的相同之處

1）CouchDB和CouchBase兩者都是NoSQL文檔數據庫，都使用了JSON作為其文檔格式。
2）CouchDB和CouchBase兩者都使用了相同的索引和查詢方法。
3）CouchDB和CouchBase兩者都使用了相同的復制系統的方法，除了P2P復制。
盡管CouchBase的開發結合了CouchDB和MemBase的功能特性，但是CouchDB和CouchBase還是有很多的不同之處，尤其是在集群、緩存、許可證等方面。

1.2.2、CouchDB和CouchBase的不同之處

1、集群系統
CouchBase內建了一個集群系統，允許數據自動跨多種節點傳播。而CouchDB是一個單節點的解決方案，支持P2P復制技術，它更適合分散式的系統，以及適合不需要把數據傳播到多個節點的場景。

2、緩存系統
CouchBase與MemBase相似，它內建了一個基於Memcached的緩存技術，始終如一地提供了亞毫秒級的讀寫性能，在每個節點上每秒可執行上百萬個操作。Apache CouchDB是一個基於磁盤的數據庫，通常它更適合超低延遲或吞吐量需求不高的場合。

3、許可證系統
CouchBase不完全是開源、免費的軟件。它有兩個版本：社區版（免費、不包含最新的Bug修復）和企業版（使用有限制、需經過CouchBase公司的審核，還有一些很多人覺得無法接受的其他條款限制）。
CouchDB是一個開源、免費的軟件（沒有附帶任何條件），它基於Apache License 2.0許可證。

4、其它不同
CouchBase不支持以下CouchDB的特性：
1）RESTful API（只用於查看，無CRUD操作）
2）P2P復制
3）支持CouchApps
4）Futon（提供了不同的管理界面）
5）文檔ID
6）數據庫的概念（這里只有桶Bucket）
7）在CouchDB數據庫和CouchBase Server之間做復制
8）明確的附件（你必須存儲另外的文件作為新鍵值對）
9）CouchBase中的一切操作都使用了HTTP API，這與CouchDB不同（你需要使用CouchBase Server的SDK或其它實驗性的客戶端庫，無需curl和wget使用經驗）
10）CouchDB API（CouchBase使用了Memcached的API來代替）
11）在CouchBase中，不能通過瀏覽器完成所有工作，而在CouchDB中則可以（使用CouchBase必須寫服務器端的應用。）
12）使用CouchBase，開發兩層架構的Web應用是不可能的，而使用CouchDB則可以（使用CouchBase必須寫服務器端的應用來適配瀏覽器和數據庫，就像關系數據庫那樣。）

1.3、CouchBase的社區版和企業版的區別

詳細部分請參考官網：https://www.couchbase.com/products/editions

內容較多，這里不再列舉。

1.4、Couchbase名詞術語

Bucket: 相當於關系型數據庫中的庫，保存JSON文檔。

vBucket: 相當於Key的子集，保存的是key的值， CouchBase是JSON型數據庫，沒有表的概念。

1.5、Couchbase和RMDB對比

Couchbase Server	Relational databases	備注
Buckets	Databases	-
Documents	Tables	-
Items (key-value or document)	Rows	-
Index	Index	-

1.6、數據同步協議

1.6.1、DCP (Database Change Protocol)

DCP 協議是一個高效的二進制協議，它主要用於集群內的數據復制、索引復制、備份數據等等。主要概念有以下幾點：

有序復制，基於每個vbucket存在一個順序序列號，同步時根據序列號進行更新；
重啟恢復，當同步連接中斷后，重新連接后，會對沖突數據進行恢復；
一致性，使用快照數據同步數據統一性；
內存間復制。

1.6.2、XDCR (Cross Data Center Replication)

XDCR提供了多個有效vbucket的數據的復制，主要用於跨數據中心的多集群間的復制，可以跨版本復制。主要概念有以下幾點：

基於bucket復制，兩個集群的同一個bucket可以實現單向或者雙向復制；
通過DCP協議保持持續性復制，一個XDCR連接中包括多個DCP數據流。這些流可以根據不同的分區對目的集群進行同步復制；
支持多種集群拓撲復制。集群間可以通過單向，雙向復制。多個集群可以實現1對1,1對多,多對1等的集群復制拓撲圖；
安全復制。數據中心見傳輸數據可以使用SSL進行加密；
最終一致性和解決數據沖突的能力。當出現沖突數據，會使用元數據的序列值，CAS值，文檔標簽和過期時間限制對數據進行沖突解決。

二、復制

為了保證分布式存儲系統的高可靠和高可用，數據在系統中一般存儲多個副本。當某個副本所在的存儲節點出現故障時，分布式存儲系統能夠自動將服務切換到其它的副本，從而實現自動容錯。

2.1、復制的概述

分布式存儲系統中數據保存多個副本，一般來說，其中一個副本為主副本，其它副本為備副本，常見的做法是數據寫入到主副本，由主副本確定操作的順序並復制到其它副本。以下是兩種復制類型：

強同步復制：復制協議要求主備同步成功才可以返回客戶端寫成功，這種協議稱為強同步協議。強同步協議提供了強一致性，但是，如果備副本出現問題將阻塞寫操作，系統可用性較差。
異步復制：在異步復制下，主副本不需要等待備副本的回應，只需要本地修改成功就可以告知客戶端寫操作成功。異步復制的好處在於系統可用性較好，但是一致性較差，如果主副本發生不可恢復故障，可能丟失最后一部分更新操作。

2.2、Couchbase 中的復制

2.2.1、集群內復制（單集群內復制）

集群內復制主要針對同一個集群中多個節點的數據進行多份復制備份，並且復制的份數會分布到不同的節點中。在數據分布中我們知道每個節點都會儲存有效的 vbucket和復制的vbucket。如下圖展示，當應用對數據進行寫操作，此操作會先到集群節點中所對應有效的vbucket的數據進行寫操作，並且有效的vbucket節點會根據DCP協議傳輸寫操作的變更傳輸到復制的vbucket所對應的節點，對復制的vbucket進行變更。可復制的 vbucket的份數，可以在操作bucket的時候進行配置，備份數量為1-3份。

Couchbase 群集所有點都是對等的，只是在創建群或者加入集群時需要指定一個主節點，一旦結點成功加入集群，所有的結點對等。

對等網的優點是，集群中的任何節點失效，集群對外提供服務完全不會中斷，只是集群的容量受影響。

由於 couchbase 是對等網集群，所有的節點都可以同時對客戶端提供服務，

vBucket 概念的引入，是 couchbase 實現 auto sharding，在線動態增減節點的重要基礎。

簡單的解釋 vBucket 可以從靜態分片開始說起，靜態分片的做法一般是用 key 算出一個 hash，得到對應的服務器，這個算法很簡單。

集群內復制在Couchbase中可以由應用在寫數據的時候選擇一致性與可用性之間的權衡，Couchbase提供了以下幾種模式的復制：

內存級的儲存。此種模式是當應用寫數據時，當數據已經儲存到內存中后，就會返回正確回復給應用，同步其它節點和持久化儲存都是由異步處理。此種模式速度最快，相對的容錯性也是最差。
內存+持久化級的儲存。此種模式是當應用寫數據時，只有數據儲存在內存和硬盤中后，才會返回正確回復給應用，同步其它節點是異步處理方式。此種模式，如果單節點出現問題，數據可能出現不一致性。
內存+備份節點級的儲存。此種模式是當應用寫數據時，只有數據儲存同步到其它節點的內存中時，才會返回正確回復給應用，持久話處理都是異步處理，應用是可以選擇出同步數據的節點數量。此種模式保證了數據一定備份和容災，但是也有一定可能數據沒有持久話會丟失。
內存+持久化+備份節點的儲存。此種模式是當應用寫數據時，數據存儲必須滿足所需要的節點中內存復制和持久化都完成后，才可以返回正確給應用。這種模式保證即使有效vbucket節點機器出現無法恢復的故障。

注：在程序流程中，第2,3,4種儲存方式持久化數量節點和備份節點的數量是由客戶端進行設置和進行檢測的。第1種儲存方式客戶端是直接進行操作並且沒有檢測過程的。

在對於讀的一致性的權衡，Couchbase 也提供了以下兩種形式：

讀取時，獲取一致性的的數據。此種方式是當數據更新后所有的應用讀到數據都是一樣的。主要原理是讀和寫都是操作有效vbucket。
讀取時，可以獲取不一致性的數據。此種方式適合對於對數據一致性不是很重要，對可用性比較注重的場景。主要原理是讀的時候，有效vbucket不可用時，數據會從備份vbucket中獲取數據。

2.2.2、跨數據中心復制（多集群間復制）--XDCR

跨數據中心復制主要是針對多個集群間的數據復制，此種復制主要以異步的方式通過XDCR協議同步數據到其它集群中備份，從而實現單集群或機房出現問題級的容災。跨數據中心復制是以bucket為單位進行復制的，在管理員操作界面可以通過配置XDCR來進行此種復制方式，下圖為跨數據中心復制示例圖：

三、集群docker安裝

安裝的系統要求：https://docs.couchbase.com/server/current/install/install-platforms.html

普通安裝：https://docs.couchbase.com/server/current/install/install-intro.html

docker安裝使用：https://docs.couchbase.com/server/current/install/getting-started-docker.html

本次集群搭建的架構如下所示：

分2個數據中心，數據中心1使用4.1版本，數據中心2使用6.6版本，此處使用docker來搭建環境，否則至少得准備6台虛擬機環境，由此可見docker的確很棒！

相關命令如下所示：

https://hub.docker.com/_/couchbase/

-- 創建相關容器環境
docker pull couchbase:community-4.1.0
docker rm -f lhrcouchbase4180 lhrcouchbase4181 lhrcouchbase4182
docker run -d --name lhrcouchbase4180 -h lhrcouchbase4180 --net=mysql-network --ip 172.72.0.80 \
      -p  8091-8094:8091-8094 -p 11210:11210 \
      -e TZ=Asia/Shanghai couchbase:community-4.1.0
docker run -d --name lhrcouchbase4181 -h lhrcouchbase4181 --net=mysql-network --ip 172.72.0.81 \
     -p 8191-8194:8091-8094 -p 11281:11210 \
     -e TZ=Asia/Shanghai couchbase:community-4.1.0
docker run -d --name lhrcouchbase4182 -h lhrcouchbase4182 --net=mysql-network --ip 172.72.0.82 \
     -p 8291-8294:8091-8094 -p 11282:11210 \
     -e TZ=Asia/Shanghai couchbase:community-4.1.0


docker pull couchbase:community-6.6.0
docker rm -f lhrcouchbase6685 lhrcouchbase6686 lhrcouchbase6687
docker run -d --name lhrcouchbase6685 -h lhrcouchbase6685 --net=mysql-network --ip 172.72.0.85 \
      -p 8591-8596:8091-8096 -p 11284-11285:11210-11211 \
      -e TZ=Asia/Shanghai couchbase:community-6.6.0
docker run -d --name lhrcouchbase6686 -h lhrcouchbase6686 --net=mysql-network --ip 172.72.0.86 \
      -p 8691-8696:8091-8096 -p 11286-11287:11210-11211 \
      -e TZ=Asia/Shanghai couchbase:community-6.6.0
docker run -d --name lhrcouchbase6687 -h lhrcouchbase6687 --net=mysql-network --ip 172.72.0.87 \
      -p 8791-8796:8091-8096 -p 11288-11289:11210-11211 \
      -e TZ=Asia/Shanghai couchbase:community-6.6.0


-- 訪問web界面
http://192.168.66.35:8591/

3.1、初始化首節點

https://docs.couchbase.com/server/current/manage/manage-nodes/initialize-node.html

首次運行Couchbase Server時，需要您對其進行初始化。初始化有以下幾種方法：

Couchbase的web控制台 (Couchbase Web Console)
Couchbase的命令行 (Couchbase Command Line Interface)
Couchbase的API接口(Couchbase REST API)

我們這里是創建新的集群，點擊“Setup New Cluster”

輸入集群名字和Admin的用戶名和密碼，用戶名最小為6位。

接受條款，點擊繼續

各個選項的含義依次為：

主機名或者ip地址，兩者都支持，強烈建議使用主機名，后續維護會比較方便
bucket落地disk的數據目錄，注意這里不支持類似於elk的多path路徑掛載，所以如果需要多快盤分擔io的話:
a. lvm
b. 硬件raid
c. 軟鏈（每個bucket一個目錄，軟鏈到其他的disk上去）
參考2
相關服務的內存限額，需要考慮給系統留一些內存（10-20%），注意這里一旦設定了限額，那么后續所有的后面加入的節點都會是這個配額了。
存儲引擎設置
web啟用更新提示

3.2、將其他節點加入集群

還是上面節點，創建完集群后界面如下

點擊左邊欄的Servers按鈕，可以查看到目前只有一台機器

點擊右上欄的“ADD SERVER”按鈕，給集群添加其他的SERVER

具體的說明如下：
1.要添加機器的hostname或者ip地址，這里填172.72.0.86
2,3.不用填寫，因為對端的機器是新創建的
4.選擇新加入的這台機器上運行什么服務。注意只能選擇服務的種類，沒有辦法選擇每種服務的內存限額。
添加完畢后，進入到Servers界面

已經可以查看到新加入的節點了，因為新節點還沒有均衡數據，所以還是黃色的，點擊右上角的rebalance按鈕，進行vbucket的重新負載均衡
負載均衡完畢后，可以看到兩個節點都是綠色顯示的了

如此，將172.72.0.87也加入到集群中去，最終ui顯示如下，說明所有的節點都正常了

同理，初始化4.1版本的集群。

3.3、創建一個bucket

切換到Buckets界面，點擊“ADD BUCKET”按鈕

彈出Bucket添加按鈕

詳細的項目解釋如下：

bucket名字
內存限額，最小100M起，注意這里是每個節點都分配100M，總共三個節點，那么這個bucket的總大小為300M
bucket的類型，有三種，memcached可以理解為就是memcached，是基於內存的，沒有持久化，不會落地硬盤，也沒有復制同步等高級功能。ephemeral則是couchbase自己的memcached，也是基於內存的，不會落地硬盤，沒有持久化，但是有復制和同步的高級功能。Couchbase則是最主打，最高級的類型了，基於內存，但是數據可以持久化到硬盤，不會撐爆內存，並且有復制同步等高級功能。可以說couchbase類型的bucket才是couchbase的核心。
備份的數目，默認為1個備份
是否復制view索引，默認只復制數據，不會復制索引。所以需要的話，需要額外勾選
沖突解決方案，說白了就是復制了，然后多個節點同時修改某個數據，是有個可能發生2邊都修改了。這樣集群內部存在2份同個key的數據，具體以哪個為准呢，沖突解決方案就是決定以哪個為准的策略
彈出策略：也就是說如果內存中的數據過多的話，采用何種方式進行數據彈出，是全部都彈出，還是只彈出vlue，內存中依然保留着key
創建的這個bucket的硬盤io優先級，也就是說會有多個bucket時，這個bucket的硬盤io優先級
是否覆蓋自動壓縮設置
默認刪除item的時候不會立即刪除，開啟了這個參數，會盡可能快的刪除。

多添加幾個Buckes，如下：

3.4、XDCR跨集群復制

XDCR提供了多個有效vbucket的數據的復制，主要用於跨數據中心的多集群間的復制，可以跨版本復制。

我們這里配置從版本4.1到版本6.6的XDCR復制。

注意：

若要配置4.1到6.6版本的復制，那么必須在4.1版本上做配置。數據才能從4.1版本流向6.6版本。

第1步，在4.1上創建名為lhrdb41的buckets桶，在6.6上創建名為lhrdb66的buckets桶。

第2步，在4.1版本上創建集群引用和復制：

到此，XDCR配置完成。

接下來，在41版本上，插入一條數據，查詢66版本上是否同步：

可以看到，6.6版本上也同步過去了。

四、常見命令

4.1、連接

可以在windows平台安裝CouchBase，然后使用cbq連接到CouchBase數據庫。

https://docs.couchbase.com/server/current/tools/cbq-shell.html

N1QL：https://www.dazhuanlan.com/2020/03/20/5e74609b54b49/

https://query-tutorial.couchbase.com/tutorial/#1

N1QL（發音是“妮叩”）是一門將SQL引入文件數據庫的查詢語言。講得技術一點，JSON是不符合第一范式的數據模型，而N1QL則對這一數據模型進行操作。N1QL將傳統SQL對表和行的操作拓展至JSON （嵌套文件）。

N1QL實際上可以理解成NOSQL+JSON，一種語法類似於SQL的語言。可以在couchbase上執行，主要考慮是方便熟悉關系型數據庫的開發人員快速上手。與SQL類似，N1QL也分為DDL與DML語句，不同的是DDL語句是create indexes，modify indexes，drop indexes，這里index與關系型數據庫中的表的概念有點像，也是必須創建對應的index才能進行增刪改查。

將SQL引入JSON有點像汽車油改電，雖然引擎換了但駕駛員的操作方式保持不變。現在開發人員既可以使用熟悉的SQL來操作又可以動態擴展應用的schema。

root@d4155ca1e245:~# cbq --help
Usage of cbq:
  -engine="http://localhost:8093/": URL to the query service(cbq-engine). By default, cbq connects to: http://localhost:8093

 Examples:
         cbq 
                 Connects to local query node. Same as: cbq -engine=http://localhost:8093
         cbq -engine=http://172.23.107.18:8093 
                 Connects to query node at 172.23.107.18 Port 8093 
         cbq -engine=https://my.secure.node.com:8093 
                 Connects to query node at my.secure.node.com:8093 using secure https protocol.

  -quiet=false: Enable/Disable startup connection message for the shell 
                 Default : false 
                 Possible Values : true/false
     
     
-- 遠程連接
cbq -e http://192.168.66.35:8093 -u Administrator -p lhr123

cbq> create primary index on `beer-sample`;
cbq> select * from `beer-sample` limit 1;
cbq> SELECT 'Hello World' AS Greeting;
cbq> \EXIT;

注：在查詢的時候，這種非大寫的bucket，一定要使用反引號引起來。

C:\Users\lhrxxt>cbq -e http://192.168.66.35:8093 -u Administrator -p lhr123
 Connected to : http://192.168.66.35:8093/. Type Ctrl-D or \QUIT to exit.

 Path to history file for the shell : C:\Users\lhrxxt\.cbq_history
cbq> select * from `lhrdb41`;
{
    "requestID": "7b2a01e7-f265-4a45-8726-ee2b05b77602",
    "errors": [
        {
            "code": 4000,
            "msg": "No primary index on keyspace lhrdb41. Use CREATE PRIMARY INDEX to create one."
        }
    ],
    "status": "fatal",
    "metrics": {
        "elapsedTime": "2.272368223s",
        "executionTime": "2.272268823s",
        "resultCount": 0,
        "resultSize": 0,
        "errorCount": 1
    }
}
cbq> create primary index on `lhrdb41`;
{
    "requestID": "b78c5f50-5b4c-480a-bde1-0124dd6513bd",
    "signature": null,
    "results": [
    ],
    "status": "success",
    "metrics": {
        "elapsedTime": "7.859142423s",
        "executionTime": "7.859013758s",
        "resultCount": 0,
        "resultSize": 0
    }
}
cbq> select * from `lhrdb41`;
{
    "requestID": "812490a8-5b78-418a-95d2-5696f5c015b8",
    "signature": {
        "*": "*"
    },
    "results": [
        {
            "lhrdb41": {
                "66": "xxt",
                "new in 2.0": "there are no reserved field names"
            }
        }
    ],
    "status": "success",
    "metrics": {
        "elapsedTime": "148.363934ms",
        "executionTime": "148.255245ms",
        "resultCount": 1,
        "resultSize": 145
    }
}
cbq>  SELECT 'Hello World' AS Greeting;
{
    "requestID": "5e8a4def-89c4-4105-9838-2d687ce463be",
    "signature": {
        "Greeting": "string"
    },
    "results": [
        {
            "Greeting": "Hello World"
        }
    ],
    "status": "success",
    "metrics": {
        "elapsedTime": "1.388056ms",
        "executionTime": "1.228273ms",
        "resultCount": 1,
        "resultSize": 49
    }
}
cbq>

4.2、couchbase-cli

root@336bb04f0d87:/# couchbase-cli server-list -c 172.72.0.80:8091 -u Administrator -p lhr123
ns_1@172.72.0.80 172.72.0.80:8091 healthy active
ns_1@172.72.0.81 172.72.0.81:8091 healthy active
ns_1@172.72.0.82 172.72.0.82:8091 healthy active

C:\Users\lhrxxt>couchbase-cli bucket-list -c 192.168.66.35:8091 -u Administrator -p lhr123
beer-sample
 bucketType: membase
 numReplicas: 1
 ramQuota: 314572800
 ramUsed: 91817216
default
 bucketType: membase
 numReplicas: 1
 ramQuota: 1258291200
 ramUsed: 81784944
lhr
 bucketType: membase
 numReplicas: 1
 ramQuota: 4869586944
 ramUsed: 81445144

4.3、客戶端連接集群

在Couchbase的集群架構中，沒有中心節點和Router的概念，這些工作是由Smartclient完成的，在客戶端與couchbase server交互時，Couchbase集群是作為一個黑匣子存在的。客戶端負責客戶程序與群集里獨立節點的通信，首次連接的那個節點並不會充當代理或者風發的角色。Smartclient或Moxi（couchbase server端的proxy組件）會加載vBucket映射表，並決定連接到集群里的哪個節點去獲取和存儲數據。如果集群的拓撲圖改變了（比如執行rebalance或者failover操作），客戶端庫會自動處理任何會話錯誤。可以這樣理解，集群的配置和結構，對應用程序是透明的，你無需去關注。

什么是Buckets，Buckets是獨立的虛擬的數據容器，一個bucket就是couchbase服務器集群中的一個邏輯組，可以被集群中的多個客戶端應用使用。它提供安全的機制來組織、管理、分析數據存儲資源。

什么是vBuckets，一個vBucket定義為couchbase集群里key空間的一個子集的擁有者。通過使用vBuckets，信息在集群里分發更有效。vBucket系統被用於分布式數據，以及支持多節點間的數據復制。

在Couchbase中bucket有兩種類型，一種是couchbase類型，另一種是memcache類型，Couchbase類型bucket支持數據的持久化，因為它的數據是存儲在磁盤上，把活躍的數據讀取到內存中供客戶端使用（后續的備份和Failover也僅是針對着用類型的bucket），而memcache類型的bucket是內存級別的，所有的數據均保存在內存中。現在我們開始切入主題，我們老的couchbase服務器，使用了這兩種類型的bucket，我們使用couchbase類型的bucket存儲的是持久化的數據，供我們的客戶端調用，這部分數據相當重要且不能丟失。

https://blog.couchbase.com/rebalancing-couchbase-part-i/

https://blog.couchbase.com/rebalancing-couchbase-part-ii/

五、CouchBase的備份和恢復

官網：https://docs.couchbase.com/server/current/backup-restore/backup-restore.html

https://docs.couchbase.com/server/current/cli/cbtools/cbbackup.html

https://docs.couchbase.com/server/current/cli/cbtools/cbrestore.html

5.1、cbback和cbrestore

該 cbbackup命令，可以在單個節點，單桶，或整個群集備份到一個靈活的備份架構，它可以將數據恢復到相同或不同的集群和水桶。所有的備份可以實時集群或節點上執行。該命令 cbbackup 是最靈活和推薦的備份工具，是一款客戶端工具，備份的文件位於客戶端上。

5.1.1、cbback備份

命令行操作方式：cbbackup [options] [source] [backup-dir] -u [admin] -p [password]

例如：

cbbackup -m full -v http://172.72.0.80:8091 /bk -u Administrator -p lhr123

-m full參數表明：執行全集群節點備份操作，基於-m參數：full、diff及accu
-v參數表明：執行過程中相關log的輸出

cbbackup -m full --single-node -t 3 http://172.72.0.80:8091 /bk -u Administrator -p lhr123

--single-node 參數表明：執行單節點的備份操作
-t 3參數表明：當前執行備份的線程個數為3

示例：

[root@docker35 bk]# cbbackup -m full -t 8 http://172.72.0.85:8091 /bk -u Administrator -p lhr123
  [####################] 100.0% (3/estimated 3 msgs)
bucket: XXT, msgs transferred...
       :                total |       last |    per sec
 byte  :                  112 |        112 |       48.8
2021-03-22 14:46:10,605: mt (0, None)
  [####################] 100.0% (3/estimated 3 msgs)
bucket: XXT2, msgs transferred...
       :                total |       last |    per sec
 byte  :                  224 |        224 |      159.8
2021-03-22 14:46:12,544: mt (0, None)
  [####################] 100.0% (7303/estimated 7303 msgs)
bucket: beer-sample, msgs transferred...
       :                total |       last |    per sec
 byte  :              2543148 |    2543148 |   743088.8
2021-03-22 14:46:16,848: mt (0, None)
  [####################] 100.0% (1/estimated 1 msgs)
bucket: lhrdb, msgs transferred...
       :                total |       last |    per sec
 byte  :              2543178 |    2543178 |  1616610.5
2021-03-22 14:46:19,100: mt (0, None)
  [####################] 100.0% (31570/estimated 31570 msgs)
bucket: lhrdb2, msgs transferred...
       :                total |       last |    per sec
 byte  :             33593916 |   33593916 |  5303973.5
2021-03-22 14:46:26,170: mt (0, None)
  [####################] 100.0% (5/estimated 5 msgs)
bucket: lhrdb66, msgs transferred...
       :                total |       last |    per sec
 byte  :             33593977 |   33593977 | 21310665.8
2021-03-22 14:46:28,796: mt (0, None)
  [####################] 100.0% (31569/estimated 31569 msgs)
bucket: travel-sample, msgs transferred...
       :                total |       last |    per sec
 byte  :             64644653 |   64644653 | 10702286.6
2021-03-22 14:46:35,688: mt (0, None)
done
[root@docker35 bk]# ll
total 0
drwxr-xr-x 3 root root 37 Mar 22 14:46 2021-03-22T064606Z
[root@docker35 bk]# ll 2021-03-22T064606Z/*
total 4
drwxr-xr-x 5 root root 158 Mar 22 14:46 bucket-beer-sample
drwxr-xr-x 3 root root  77 Mar 22 14:46 bucket-lhrdb
drwxr-xr-x 5 root root 139 Mar 22 14:46 bucket-lhrdb2
drwxr-xr-x 5 root root 139 Mar 22 14:46 bucket-lhrdb66
drwxr-xr-x 5 root root 158 Mar 22 14:46 bucket-travel-sample
drwxr-xr-x 5 root root 139 Mar 22 14:46 bucket-XXT
drwxr-xr-x 5 root root 139 Mar 22 14:46 bucket-XXT2
-rw-r--r-- 1 root root   2 Mar 22 14:46 fts_alias.json

注意，這里的桶名都加上了bucket，真實的桶名為去掉bucket后的名稱，例如桶名為lhrdb，而不是bucket-lhrdb

5.1.2、cbrestore還原數據庫

命令操作方式：cbrestore [options] [backup-dir] [destination]

cbrestore -b lhr -B lhrdb  -t 8  /bk/ http://172.72.0.85:8091 -u Administrator -p lhr123

-b 參數表明源buckets名稱，必須正確，即source_bucket
-B 參數表明目標buckets名稱，需要提前創建，即destiant_bucket
--from-date 參數表明從具體的某一日開始
--to-date 參數表明截止到具體的某一日

注意：

1、還原的時候必須指定還原的桶名，即-b和-B都必須指定

2、還原之前，必須在目標端提前創建好要還原的Buckets名稱

示例：

首先刪除要還原的桶beer-sample，然后創建一個空的桶beer-sample：

然后，進行還原：

[root@docker35 bk]# cbrestore -b beer-sample -B beer-sample  -t 8  /bk/ http://172.72.0.85:8091 -u Administrator -p lhr123
  [####################] 100.0% (7303/estimated 7303 msgs)
bucket: b'beer-sample', msgs transferred...
       :                total |       last |    per sec
 byte  :              2542924 |    2542924 |  2483121.5
done

數據已成功恢復。

5.2、增量備份

官網：https://docs.couchbase.com/server/current/backup-restore/incremental-backup.html

麥老師通過閱讀官網，可知，CouchBase也可以進行增量備份，增量備份可以分為差異增量備份（Differential incremental backup）、累積增量備份（Cumulative incremental backup）和組合增量備份類型（Combining incremental backup types）。差異增量備份僅包含自上次備份以來發生的數據庫更改。累積增量備份包含自上次完全備份以來發生的所有更改。

在本例中，星期一備份包含自周日完全備份以來所做的更改，星期二備份包含自星期一備份以來所做的更改，星期三備份包含自星期二備份以來所做的更改，依此類推。例如，周三執行的還原操作使用周日的完整備份以及周一和周二的差異增量備份。

在本例中，星期一備份包含自周日完全備份以來所做的所有更改，星期二備份包含自周日完全備份以來所做的所有更改，星期三備份包含自周日完全備份以來所做的所有更改，依此類推。例如，周三執行的還原操作使用周日的完整備份和周二的累計增量備份。

backup-combined-incremental

在本例中，備份計划包括不同天的差異增量備份和累積增量備份。在星期一、星期二、星期三、星期五和星期六，將進行差異增量備份。周四，將進行累積增量備份。例如，周六執行的還原操作使用周日的完整備份、周四的累計增量備份和周五的差異增量備份。

示例：

XXT桶目前是4條數據，全量備份已做，接下來插入一條數據，讓XXT桶變為5條數據，然后進行增量備份：

[root@docker35 2021-03-22T064606Z]# cbbackup -m diff -b XXT -t 8 http://172.72.0.85:8091 /bk -u Administrator -p lhr123
  [####################] 100.0% (5/estimated 5 msgs)
bucket: XXT, msgs transferred...
       :                total |       last |    per sec
 byte  :                  256 |        256 |      100.8
2021-03-22 15:36:47,172: mt (0, None)
done
[root@docker35 2021-03-22T064606Z]# ll
total 0
drwxr-xr-x 9 root root 182 Mar 22 14:46 2021-03-22T064606Z-full
drwxr-xr-x 3 root root  46 Mar 22 15:36 2021-03-22T073643Z-diff

文件夾2021-03-22T073643Z-diff中就是增量備份的內容，接下來刪除XXT桶，然后再創建XXT空桶，最后進行還原：

[root@docker35 2021-03-22T064606Z-full]# cbrestore -b XXT -B XXT  -t 8  /bk/  http://172.72.0.85:8091 -u Administrator -p lhr123
  [####################] 100.0% (8/estimated 8 msgs)
bucket: b'XXT', msgs transferred...
       :                total |       last |    per sec
 byte  :                  368 |        368 |     4231.8
done

有關其它內容的深入學習，本文不再演示，若有需要，請聯系麥老師。

About Me

● 本文作者：小麥苗，部分內容整理自網絡，若有侵權請聯系小麥苗刪除
● 本文原始發表於個人微信公眾號（DB寶）上
● QQ群號： 230161599 、618766405，微信群私聊
● 個人QQ號（646634621），微信號（db_bao），注明添加緣由
● 版權所有，歡迎分享本文，轉載請保留出處

免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。

猜您在找 DB2的備份（backup）和恢復（RESTORE）數據庫方法 HBase、Redis、MongoDB、Couchbase、LevelDB主流 NoSQL 數據庫的對比 Linux實戰教學筆記46：NoSQL數據庫之redis持久化存儲（二） mysql 數據庫備份和恢復 postgresql數據庫備份和恢復 postgre數據庫備份與恢復 MySQL數據庫備份與恢復 postgres的數據庫備份和恢復 postgresql數據庫備份和恢復 Oracle基礎數據庫備份和恢復