分布式数据库Couchbase 集群迁移-2

简介: 在之前的文章中,我们介绍了基于 CBBACK 以及 CBRESTORE 等操作方式进行的分布式数据库 Couchbase 集群迁移方案,具体可参考链接:分布式数据库Couchbase 集群迁移。其实,在基于不同的业务场景以及架构方案,针对分布式数据库 Couchbase 集群迁移有多种不同的实现策略,只有能够达到高效、稳定及安全,才是最优选择。


    在之前的文章中,我们介绍了基于 CBBACK 以及 CBRESTORE 等操作方式进行的分布式数据库 Couchbase 集群迁移方案,具体可参考链接:分布式数据库Couchbase 集群迁移。其实,在基于不同的业务场景以及架构方案,针对分布式数据库 Couchbase 集群迁移有多种不同的实现策略,只有能够达到高效、稳定及安全,才是最优选择。

    在进行主题之前先补充一下分布式数据库 Couchbase 一些基本概念:在 Couchbase 的集群架构中,没有中心节点和 Router 的概念,这些工作是由 Smartclient 完成的,在客户端与 Couchbase Server 交互时,Couchbase 集群是作为一个黑匣子存在的。客户端负责客户程序与群集里独立节点的通信,首次连接的那个节点并不会充当代理或者分发的角色。Smartclient 或 Moxi( Couchbase Server 端的 Proxy组件)会加载 vBucket 映射表,并决定连接到集群里的哪个节点去获取和存储数据。如果集群的拓扑图改变了(比如执行 Rebalance 或者 Ffailover 操作),客户端库会自动处理任何会话错误。可以这样理解,集群的配置和结构,对应用程序是透明的,我们无需去过多关注。

     什么是 Buckets,Buckets 是独立的虚拟的数据容器,一个 Bucket 就是 Couchbase服务器集群中的一个逻辑组,可以被集群中的多个客户端应用使用。它提供安全的机制来组织、管理、分析数据存储资源。

     什么是 vBuckets,一个 vBucket 定义为 Couchbase 集群里 Key 空间的一个子集的拥有者。通过使用 vBuckets,信息在集群里分发更有效。vBucket 系统被用于分布式数据,以及支持多节点间的数据复制。

    在 Couchbase 中 Bucket有两种类型,一种是 Couchbase 类型,另一种是 Memcache类型,Couchbase 类型 Bucket 支持数据的持久化,因为它的数据是存储在磁盘上,把活跃的数据读取到内存中供客户端使用(后续的备份和Failover也仅是针对这种类型的 Bucket),而 Memcache 类型的 Bucket 是内存级别的,所有的数据均保存在内存中。现在我们开始切入主题,我们老的 Couchbase 服务器,使用了这两种类型的 Bucket,我们使用 Couchbase 类型的 Bucket存储的是持久化的数据,供我们的客户端调用,这部分数据相当重要且不能丢失。

    基本思路:

    1、备份老的 Couchbase 服务数据

   2、将新 Couchbase 服务器加入到老服务器集群中,并通过 Rebalance 同步两台服务器 Cache 数据

    3、修改客户端 Couchbase 配置节点

    4、Failover 老服务器进行升级

   本文主要基于 CBTRANSFER 操作方案以实现 Couchbase 集群迁移。具体如下所示:

    我们先描述当前的环境信息,具体如下所示:

    --- 环境描述:CentOS release 6.7 (Final)

    --- 源主机IP:10.10.10.10(此处真实地址已xx)

    --- 目标主机IP:11.11.11.11(此处真实地址已xx)

    --- 应用服务:Couchbase-server-enterprise-5.5.2-centos6.x86_64.rpm版本

     CBTRANSFER

     基于集群之间或者数据文件进行转换以实现无缝迁移。其语法为:


cbtransfer [options] source destination

       具体如下所示:


[root@testserver bin]# ./cbtransfer -u Administrator -p password http://10.10.10.10:8091 http://11.11.11.11:8091 -b xwf_main --bucket-destination xwf_main
  //  http://10.10.10.10:8091 参数为源主机
  //  http://11.11.11.11:8091 参数为目标主机
  //  -b 参数为源主机对应的bucket信息
  //  --bucket-destination 参数为目标主机对应的bucket信息
  .
  bucket: xwf_main, msgs transferred...
          :                total |       last |    per sec
    byte  :                    0 |          0 |        0.0
    done

[root@testserver bin]#./cbtransfer -v -u Administrator -p password http:/10.10.10.10:8091 http://11.11.11.11:8091 -b xwf_main --bucket-destination xwf_main

2016-01-03 14:55:17,477: mt cbtransfer...

2016-01-03 14:55:17,478: mt  source : http://10.10.10.10:8091

2016-01-03 14:55:17,478: mt  sink   : http://11.11.11.11:8091

2016-01-03 14:55:17,478: mt  opts   : {'username': '<xxx>', 'destination_vbucket_state': 'active', 'verbose': 1, 'extra': {'max_retry': 10.0, 'rehash': 0.0,'dcp_consumer_queue_length': 1000.0, 'data_only': 0.0, 'uncompress': 0.0, 'nmv_retry': 1.0, 'conflict_resolve': 1.0, 'cbb_max_mb': 100000.0, 'report': 5.0, 'mcd_compatible': 1.0, 'try_xwm': 1.0, 'backoff_cap': 10.0, 'batch_max_bytes': 400000.0, 'report_full': 2000.0, 'flow_control': 1.0, 'batch_max_size': 1000.0,'seqno': 0.0, 'design_doc_only': 0.0, 'allow_recovery_vb_remap': 0.0, 'recv_min_bytes': 4096.0}, 'collection': None, 'ssl': False, 'threads': 4, 'key': None,'password': '<xxx>', 'id': None, 'destination_operation': None, 'source_vbucket_state': 'active', 'silent': False, 'dry_run': False, 'single_node': False, 'bucket_destination': 'xwf_main', 'vbucket_list': None, 'separator': '::', 'bucket_source': 'xwf_main'}

2016-01-03 14:55:17,492: mt Starting new HTTP connection (1): 10.10.10.10

2016-01-03 14:55:17,604: mt Starting new HTTP connection (1): 11.11.11.11

2016-01-03 14:55:17,697: mt bucket: xwf_main

2016-01-

03 14:55:17,940: w0 source: http://10.10.10.10:8091(xwf_main@10.10.10.10:8091)

2016-01-

03 14:55:17,940: w0 sink: http://11.11.11.11:8091(xwf_main@10.10.10.10:8091)

2016-01-03 14:55:17,941: w0 :                total |       last |    per sec

 .

 bucket: xwf_main, msgs transferred...

         :                total |       last |    per sec

   batch :                    0 |          0 |        0.0

   byte  :                    0 |          0 |        0.0

   msg   :                    0 |          0 |        0.0

2016-01-03 14:55:17,998: mt Starting new HTTP connection (1): 10.10.10.10

2016-01-03 14:55:18,003: mt Starting new HTTP connection (1): 10.10.10.10

2016-01-03 14:55:18,054: mt Starting new HTTP connection (1): 11.11.11.11

2016-01-03 14:55:18,061: mt Starting new HTTP connection (1): 11.11.11.11

2016-01-03 14:55:18,103: mt Starting new HTTP connection (1): 10.10.10.10

2016-01-03 14:55:18,110: mt Starting new HTTP connection (1): 10.10.10.10

done

     至此,一个简单的关于 Couchbase 集群迁移操作轻松搞定,后续仅需要对新的集群进行 Rebalancing 操作即可。


相关文章
|
SQL 关系型数据库 MySQL
乐观锁在分布式数据库中如何与事务隔离级别结合使用
乐观锁在分布式数据库中如何与事务隔离级别结合使用
192 5
|
5月前
|
存储 监控 分布式数据库
ClickHouse分布式数据库动态伸缩(弹性扩缩容)的实现
实现ClickHouse数据库的动态伸缩需要持续的维护和精细的操作。从集群配置到数据迁移,再到监控和自动化,每一步都要仔细管理以确保服务的可靠性和性能。这些活动可以显著提高应用的响应性和成本效率,帮助业务根据实际需求灵活调整资源分配。
337 10
|
6月前
|
存储 关系型数据库 分布式数据库
【赵渝强老师】基于PostgreSQL的分布式数据库:Citus
Citus 是基于 PostgreSQL 的开源分布式数据库,采用 shared nothing 架构,具备良好的扩展性。它以插件形式集成,部署简单,适用于处理大规模数据和高并发场景。本文介绍了 Citus 的基础概念、安装配置步骤及其在单机环境下的集群搭建方法。
501 2
|
SQL 关系型数据库 MySQL
乐观锁在分布式数据库中如何与事务隔离级别结合使用
乐观锁在分布式数据库中如何与事务隔离级别结合使用
|
8月前
|
SQL 存储 分布式数据库
分布式存储数据恢复—hbase和hive数据库数据恢复案例
分布式存储数据恢复环境: 16台某品牌R730xd服务器节点,每台服务器节点上有数台虚拟机。 虚拟机上部署Hbase和Hive数据库。 分布式存储故障: 数据库底层文件被误删除,数据库不能使用。要求恢复hbase和hive数据库。
284 12
|
存储 SQL 分布式数据库
OceanBase 入门:分布式数据库的基础概念
【8月更文第31天】在当今的大数据时代,随着业务规模的不断扩大,传统的单机数据库已经难以满足高并发、大数据量的应用需求。分布式数据库应运而生,成为解决这一问题的有效方案之一。本文将介绍一款由阿里巴巴集团自主研发的分布式数据库——OceanBase,并通过一些基础概念和实际代码示例来帮助读者理解其工作原理。
1209 0
|
10月前
|
SQL 运维 关系型数据库
体验用分布式数据库突破资源瓶颈,完成任务领智能台灯!
体验用分布式数据库突破资源瓶颈,完成任务领智能台灯!
|
10月前
|
SQL 数据建模 BI
【YashanDB 知识库】用 yasldr 配置 Bulkload 模式作单线程迁移 300G 的业务数据到分布式数据库,迁移任务频繁出错
问题描述 详细版本:YashanDB Server Enterprise Edition Release 23.2.4.100 x86_64 6db1237 影响范围: 离线数据迁移场景,影响业务数据入库。 外场将部分 NewCIS 的报表业务放到分布式数据库,验证 SQL 性能水平。 操作系统环境配置: 125G 内存 32C CPU 2T 的 HDD 磁盘 问题出现的步骤/操作: 1、部署崖山分布式数据库 1mm 1cn 3dn 单线启动 yasldr 数据迁移任务,设置 32 线程的 bulk load 模式 2、观察 yasldr.log 是否出现如下错
|
11月前
|
容灾 关系型数据库 分布式数据库
PolarDB分布式版:与云融合的分布式数据库发展新阶段
PolarDB分布式版标志着分布式数据库与云融合的新阶段。它经历了三个发展阶段:从简单的分布式中间件,到一体化分布式架构,再到云原生分布式数据库。PolarDB充分利用云资源的弹性、高性价比、高可用性和隔离能力,解决了大规模数据扩展性问题,并支持多租户场景和复杂事务处理。零售中台的建设背景包括国家数字化转型战略及解决信息孤岛问题,采用分布式数据库提升高可用性和性能,满足海量订单处理需求。展望未来,零售中台将重点提升容灾能力、优化资源利用并引入AI技术,以实现更智能的服务和更高的业务连续性。
349 9

热门文章

最新文章