[toc]

一、 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 协议是一个高效的二进制协议，它主要用于集群内的数据复制、索引复制、备份数据等等。主要概念有以下几点：

1. 有序复制，基于每个vbucket存在一个顺序序列号，同步时根据序列号进行更新；

2. 重启恢复，当同步连接中断后，重新连接后，会对冲突数据进行恢复；

3. 一致性，使用快照数据同步数据统一性；

4. 内存间复制。

1.6.2、XDCR (Cross Data Center Replication)

XDCR提供了多个有效vbucket的数据的复制，主要用于跨数据中心的多集群间的复制，可以跨版本复制。主要概念有以下几点：

1. 基于bucket复制，两个集群的同一个bucket可以实现单向或者双向复制；

2. 通过DCP协议保持持续性复制，一个XDCR连接中包括多个DCP数据流。这些流可以根据不同的分区对目的集群进行同步复制；

3. 支持多种集群拓扑复制。集群间可以通过单向，双向复制。多个集群可以实现1对1,1对多,多对1等的集群复制拓扑图；

4. 安全复制。数据中心见传输数据可以使用SSL进行加密；

5. 最终一致性和解决数据冲突的能力。当出现冲突数据，会使用元数据的序列值，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提供了以下几种模式的复制：

1. 内存级的储存。此种模式是当应用写数据时，当数据已经储存到内存中后，就会返回正确回复给应用，同步其它节点和持久化储存都是由异步处理。此种模式速度最快，相对的容错性也是最差。

2. 内存+持久化级的储存。此种模式是当应用写数据时，只有数据储存在内存和硬盘中后，才会返回正确回复给应用，同步其它节点是异步处理方式。此种模式，如果单节点出现问题，数据可能出现不一致性。

3. 内存+备份节点级的储存。此种模式是当应用写数据时，只有数据储存同步到其它节点的内存中时，才会返回正确回复给应用，持久话处理都是异步处理，应用是可以选择出同步数据的节点数量。此种模式保证了数据一定备份和容灾，但是也有一定可能数据没有持久话会丢失。

4. 内存+持久化+备份节点的储存。此种模式是当应用写数据时，数据存储必须满足所需要的节点中内存复制和持久化都完成后，才可以返回正确给应用。这种模式保证即使有效vbucket节点机器出现无法恢复的故障。

注：在程序流程中，第2,3,4种储存方式持久化数量节点和备份节点的数量是由客户端进行设置和进行检测的。第1种储存方式客户端是直接进行操作并且没有检测过程的。

在对于读的一致性的权衡，Couchbase 也提供了以下两种形式：

1. 读取时，获取一致性的的数据。此种方式是当数据更新后所有的应用读到数据都是一样的。主要原理是读和写都是操作有效vbucket。

2. 读取时，可以获取不一致性的数据。此种方式适合对于对数据一致性不是很重要，对可用性比较注重的场景。主要原理是读的时候，有效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位。

接受条款，点击继续

各个选项的含义依次为：

1. 主机名或者ip地址，两者都支持，强烈建议使用主机名，后续维护会比较方便
2. bucket落地disk的数据目录，注意这里不支持类似于elk的多path路径挂载，所以如果需要多快盘分担io的话:
   a. lvm
   b. 硬件raid
   c. 软链（每个bucket一个目录，软链到其他的disk上去）
3. 参考2
4. 相关服务的内存限额，需要考虑给系统留一些内存（10-20%），注意这里一旦设定了限额，那么后续所有的后面加入的节点都会是这个配额了。
5. 存储引擎设置
6. 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添加按钮

详细的项目解释如下：

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，如下：

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）。差异增量备份仅包含自上次备份以来发生的数据库更改。累积增量备份包含自上次完全备份以来发生的所有更改。

在本例中，星期一备份包含自周日完全备份以来所做的更改，星期二备份包含自星期一备份以来所做的更改，星期三备份包含自星期二备份以来所做的更改，依此类推。例如，周三执行的还原操作使用周日的完整备份以及周一和周二的差异增量备份。

在本例中，星期一备份包含自周日完全备份以来所做的所有更改，星期二备份包含自周日完全备份以来所做的所有更改，星期三备份包含自周日完全备份以来所做的所有更改，依此类推。例如，周三执行的还原操作使用周日的完整备份和周二的累计增量备份。

在本例中，备份计划包括不同天的差异增量备份和累积增量备份。在星期一、星期二、星期三、星期五和星期六，将进行差异增量备份。周四，将进行累积增量备份。例如，周六执行的还原操作使用周日的完整备份、周四的累计增量备份和周五的差异增量备份。

示例：

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），注明添加缘由
● 版权所有，欢迎分享本文，转载请保留出处