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

時間  2021-04-07 標籤 html node mysql web 算法 sql mongodb docker shell 數據庫

[toc]html

1、 CouchBase概述

1.一、簡述

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

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

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

簡而言之， 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是另外一個徹底獨立的項目。 sql

1.二、CouchDB和CouchBase比對

1.2.一、CouchDB和CouchBase的相同之處

1）CouchDB和CouchBase二者都是NoSQL文檔數據庫，都使用了JSON做爲其文檔格式。
2）CouchDB和CouchBase二者都使用了相同的索引和查詢方法。
3）CouchDB和CouchBase二者都使用了相同的複製系統的方法，除了P2P複製。
儘管CouchBase的開發結合了CouchDB和MemBase的功能特性，可是CouchDB和CouchBase仍是有不少的不一樣之處，尤爲是在集羣、緩存、許可證等方面。 mongodb

1.2.二、CouchDB和CouchBase的不一樣之處

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

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

三、許可證系統
CouchBase不徹底是開源、免費的軟件。它有兩個版本：社區版（免費、不包含最新的Bug修復）和企業版（使用有限制、需通過CouchBase公司的審覈，還有一些不少人以爲沒法接受的其餘條款限制）。
CouchDB是一個開源、免費的軟件（沒有附帶任何條件），它基於Apache License 2.0許可證。 數據庫

四、其它不一樣
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.三、CouchBase的社區版和企業版的區別

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

內容較多，這裏再也不列舉。

1.四、Couchbase名詞術語

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

Bucket: 至關於關係型數據庫中的庫，保存JSON文檔。

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

1.五、Couchbase和RMDB對比

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

1.六、數據同步協議

1.6.一、DCP (Database Change Protocol)

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

  1. 有序複製，基於每一個vbucket存在一個順序序列號，同步時根據序列號進行更新；

  2. 重啓恢復，當同步鏈接中斷後，從新鏈接後，會對衝突數據進行恢復；

  3. 一致性，使用快照數據同步數據統一性；

  4. 內存間複製。

1.6.二、XDCR (Cross Data Center Replication)

XDCR提供了多個有效vbucket的數據的複製，主要用於跨數據中心的多集羣間的複製，能夠跨版本複製。主要概念有如下幾點：

  1. 基於bucket複製，兩個集羣的同一個bucket能夠實現單向或者雙向複製；

  2. 經過DCP協議保持持續性複製，一個XDCR鏈接中包括多個DCP數據流。這些流能夠根據不一樣的分區對目的集羣進行同步複製；

  3. 支持多種集羣拓撲復制。集羣間能夠經過單向，雙向複製。多個集羣能夠實現1對1,1對多,多對1等的集羣複製拓撲圖；

  4. 安全複製。數據中心見傳輸數據可使用SSL進行加密；

  5. 最終一致性和解決數據衝突的能力。當出現衝突數據，會使用元數據的序列值，CAS值，文檔標籤和過時時間限制對數據進行衝突解決。

2、複製

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

2.一、複製的概述

分佈式存儲系統中數據保存多個副本，通常來講，其中一個副本爲主副本，其它副本爲備副本，常見的作法是數據寫入到主副本，由主副本肯定操做的順序並複製到其它副本。如下是兩種複製類型：

  • 強同步複製：複製協議要求主備同步成功才能夠返回客戶端寫成功，這種協議稱爲強同步協議。強同步協議提供了強一致性，可是，若是備副本出現問題將阻塞寫操做，系統可用性較差。

  • 異步複製：在異步複製下，主副本不須要等待備副本的迴應，只須要本地修改爲功就能夠告知客戶端寫操做成功。異步複製的好處在於系統可用性較好，可是一致性較差，若是主副本發生不可恢復故障，可能丟失最後一部分更新操做。

2.二、Couchbase 中的複製

2.2.一、集羣內複製（單集羣內複製）

集羣內複製主要針對同一個集羣中多個節點的數據進行多份複製備份，而且複製的份數會分佈到不一樣的節點中。在數據分佈中咱們知道每一個節點都會儲存有效的 vbucket和複製的vbucket。以下圖展現，當應用對數據進行寫操做，此操做會先到集羣節點中所對應有效的vbucket的數據進行寫操做，並 且有效的vbucket節點會根據DCP協議傳輸寫操做的變動傳輸到複製的vbucket所對應的節點，對複製的vbucket進行變動。可複製的 vbucket的份數，能夠在操做bucket的時候進行配置，備份數量爲1-3份。

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

Couchbase 羣集全部點都是對等的，只是在建立羣或者加入集羣時須要指定一個主節點，一旦結點成功加入集羣，全部的結點對等。

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

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

因爲 couchbase 是對等網集羣，全部的節點均可以同時對客戶端提供服務，

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

簡單的解釋 vBucket 能夠從靜態分片開始提及，靜態分片的作法通常是用 key 算出一個 hash，獲得對應的服務器，這個算法很簡單。

集羣內複製在Couchbase中能夠由應用在寫數據的時候選擇一致性與可用性之間的權衡，Couchbase提供瞭如下幾種模式的複製：

  1. 內存級的儲存。此種模式是當應用寫數據時，當數據已經儲存到內存中後，就會返回正確回覆給應用，同步其它節點和持久化儲存都是由異步處理。此種模式速度最快，相對的容錯性也是最差。

  2. 內存+持久化級的儲存。此種模式是當應用寫數據時，只有數據儲存在內存和硬盤中後，纔會返回正確回覆給應用，同步其它節點是異步處理方式。此種模式，若是單節點出現問題，數據可能出現不一致性。

  3. 內存+備份節點級的儲存。此種模式是當應用寫數據時，只有數據儲存同步到其它節點的內存中時，纔會返回正確回覆給應用，持久話處理都是異步處理，應用是能夠選擇出同步數據的節點數量。此種模式保證了數據必定備份和容災，可是也有必定可能數據沒有持久話會丟失。

  4. 內存+持久化+備份節點的儲存。此種模式是當應用寫數據時，數據存儲必須知足所須要的節點中內存複製和持久化都完成後，才能夠返回正確給應用。這種模式保證即便有效vbucket節點機器出現沒法恢復的故障。

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

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

  1. 讀取時，獲取一致性的的數據。此種方式是當數據更新後全部的應用讀到數據都是同樣的。主要原理是讀和寫都是操做有效vbucket。

  2. 讀取時，能夠獲取不一致性的數據。此種方式適合對於對數據一致性不是很重要，對可用性比較注重的場景。主要原理是讀的時候，有效vbucket不可用時，數據會從備份vbucket中獲取數據。

2.2.二、跨數據中心複製（多集羣間複製）--XDCR

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

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

3、集羣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

本次集羣搭建的架構以下所示：

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

分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.一、初始化首節點

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)

【DB寶46】NoSQL數據庫之CouchBase簡介、集羣搭建、XDCR同步及備份恢復
咱們這裏是建立新的集羣，點擊「Setup New Cluster」
【DB寶46】NoSQL數據庫之CouchBase簡介、集羣搭建、XDCR同步及備份恢復
輸入集羣名字和Admin的用戶名和密碼 ，用戶名最小爲6位。
【DB寶46】NoSQL數據庫之CouchBase簡介、集羣搭建、XDCR同步及備份恢復
接受條款，點擊繼續
【DB寶46】NoSQL數據庫之CouchBase簡介、集羣搭建、XDCR同步及備份恢復

各個選項的含義依次爲：

  1. 主機名或者ip地址，二者都支持，強烈建議使用主機名，後續維護會比較方便
  2. bucket落地disk的數據目錄，注意這裏不支持相似於elk的多path路徑掛載，因此若是須要多快盤分擔io的話:
    a. lvm
    b. 硬件raid
    c. 軟鏈（每一個bucket一個目錄，軟鏈到其餘的disk上去）
  3. 參考2
  4. 相關服務的內存限額，須要考慮給系統留一些內存（10-20%），注意這裏一旦設定了限額，那麼後續全部的後面加入的節點都會是這個配額了。
  5. 存儲引擎設置
  6. web啓用更新提示

3.二、將其餘節點加入集羣

仍是上面節點，建立完集羣后界面以下
【DB寶46】NoSQL數據庫之CouchBase簡介、集羣搭建、XDCR同步及備份恢復
點擊左邊欄的Servers按鈕，能夠查看到目前只有一臺機器
image-20210322120528694

點擊右上欄的「ADD SERVER」按鈕，給集羣添加其餘的SERVER
img

img
具體的說明以下：
1.要添加機器的hostname或者ip地址，這裏填172.72.0.86
2,3.不用填寫，由於對端的機器是新建立的
4.選擇新加入的這臺機器上運行什麼服務。注意只能選擇服務的種類，沒有辦法選擇每種服務的內存限額。
添加完畢後，進入到Servers界面
image-20210322113040012

已經能夠查看到新加入的節點了，由於新節點尚未均衡數據，因此仍是黃色的，點擊右上角的rebalance按鈕，進行vbucket的從新負載均衡
負載均衡完畢後，能夠看到兩個節點都是綠色顯示的了
image-20210322113108438

如此，將172.72.0.87也加入到集羣中去，最終ui顯示以下，說明全部的節點都正常了
【DB寶46】NoSQL數據庫之CouchBase簡介、集羣搭建、XDCR同步及備份恢復

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

3.三、建立一個bucket

切換到Buckets界面，點擊「ADD BUCKET」按鈕
img
彈出Bucket添加按鈕
【DB寶46】NoSQL數據庫之CouchBase簡介、集羣搭建、XDCR同步及備份恢復
詳細的項目解釋以下：

  1. bucket名字

  2. 內存限額，最小100M起，注意這裏是每一個節點都分配100M，總共三個節點，那麼這個bucket的總大小爲300M

  3. bucket的類型，有三種，memcached能夠理解爲就是memcached，是基於內存的，沒有持久化，不會落地硬盤，也沒有複製同步等高級功能。ephemeral則是couchbase本身的memcached，也是基於內存的，不會落地硬盤，沒有持久化，可是有複製和同步的高級功能。Couchbase則是最主打，最高級的類型了，基於內存，可是數據能夠持久化到硬盤，不會撐爆內存，而且有複製同步等高級功能。能夠說couchbase類型的bucket纔是couchbase的核心。

  4. 備份的數目，默認爲1個備份

  5. 是否複製view索引，默認只複製數據，不會複製索引。因此須要的話，須要額外勾選

  6. 衝突解決方案，說白了就是複製了，而後多個節點同時修改某個數據，是有個可能發生2邊都修改了。這樣集羣內部存在2份同個key的數據，具體以哪一個爲準呢，衝突解決方案就是決定以哪一個爲準的策略

  7. 彈出策略：也就是說若是內存中的數據過多的話，採用何種方式進行數據彈出，是所有都彈出，仍是隻彈出vlue，內存中依然保留着key

  8. 建立的這個bucket的硬盤io優先級，也就是說會有多個bucket時，這個bucket的硬盤io優先級

  9. 是否覆蓋自動壓縮設置

  10. 默認刪除item的時候不會當即刪除，開啓了這個參數，會盡量快的刪除。

    多添加幾個Buckes，以下：

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

3.四、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桶。

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

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

第2步，在4.1版本上建立集羣引用和複製：

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

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

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

到此，XDCR配置完成。

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

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

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

能夠看到，6.6版本上也同步過去了。

4、常見命令

4.一、鏈接

能夠在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.二、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.三、客戶端鏈接集羣

在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/

5、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.一、cbback和cbrestore

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

5.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.二、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 參數代表截止到具體的某一日

注意：

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

二、還原以前，必須在目標端提早建立好要還原的Buckets名稱

示例：

首先刪除要還原的桶beer-sample，而後建立一個空的桶beer-sample：

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

而後，進行還原：

[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

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

數據已成功恢復。

5.二、增量備份

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

麥老師經過閱讀官網，可知，CouchBase也能夠進行增量備份，增量備份能夠分爲差別增量備份（Differential incremental backup）、累積增量備份（Cumulative incremental backup）和組合增量備份類型（Combining incremental backup types）。差別增量備份僅包含自上次備份以來發生的數據庫更改。累積增量備份包含自上次徹底備份以來發生的全部更改。

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

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

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

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

backup-combined-incremental

在本例中，備份計劃包括不一樣天的差別增量備份和累積增量備份。在星期1、星期2、星期3、星期五和星期六，將進行差別增量備份。週四，將進行累積增量備份。例如，週六執行的還原操做使用週日的完整備份、週四的累計增量備份和週五的差別增量備份。

示例：

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空桶，最後進行還原：

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

[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

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

有關其它內容的深刻學習，本文再也不演示，如有須要，請聯繫麥老師。

About Me

● 本文做者：小麥苗，部份內容整理自網絡，如有侵權請聯繫小麥苗刪除
● 本文原始發表於我的微 信公衆號（DB寶）上● QQ羣號： 230161599 、618766405，微信羣私聊 ● 我的QQ號（646634621），微 信號（db_bao），註明添加原因● 版權全部，歡迎分享本文，轉載請保留出處

联系我们 沪ICP备2021010478号-7