AI 助理
备案控制台
开发者社区 数据库 文章 正文

MongoDB副本集同步原理

2019-08-23 3544
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
云数据库 MongoDB，独享型 2核8GB
推荐场景：
构建全方位客户视图
日志服务 SLS，月写入数据量 50GB 1个月
简介： MongoDB的同步原理，官方文档介绍的比较少，网上资料也不是太多，下面是结合官方文档、网上资料和测试时候的日志，整理出来的一点东西。

MongoDB的同步原理，官方文档介绍的比较少，网上资料也不是太多，下面是结合官方文档、网上资料和测试时候的日志，整理出来的一点东西。
因为MongoDB的每个分片也是副本集，所以只需要搞副本集的同步原理即可。

一、Initial Sync

大体来说，MongoDB副本集同步主要包含两个步骤：

1. Initial Sync，全量同步
2. Replication，即sync oplog

先通过init sync同步全量数据，再通过replication不断重放Primary上的oplog同步增量数据。全量同步完成后，成员从转换 STARTUP2为SECONDARY

1.1 初始化同步过程

1) 全量同步开始，获取同步源上的最新时间戳t1
2) 全量同步集合数据，建立索引（比较耗时）
3) 获取同步源上最新的时间戳t2
4) 重放t1到t2之间所有的oplog
5) 全量同步结束

简单来说，就是遍历Primary上的所有DB的所有集合，将数据拷贝到自身节点，然后读取全量同步开始到结束时间段内的oplog并重放。

initial sync结束后，Secondary会建立到Primary上local.oplog.rs的tailable cursor，不断从Primary上获取新写入的oplog，并应用到自身。

1.2 初始化同步场景

Secondary节点当出现如下状况时，需要先进⾏全量同步

1) oplog为空
2) local.replset.minvalid集合⾥_initialSyncFlag字段设置为true（用于init sync失败处理）
3) 内存标记initialSyncRequested设置为true（用于resync命令，resync命令只用于master/slave架构，副本集无法使用）

这3个场景分别对应(场景2和场景3没看到官网文档有写，参考张友东大神博客)

1) 新节点加⼊，⽆任何oplog，此时需先进性initial sync
2) initial sync开始时，会主动将_initialSyncFlag字段设置为true，正常结束后再设置为false；如果节点重启时，发现_initialSyncFlag为true，说明上次全量同步中途失败了，此时应该重新进⾏initial sync
3)当⽤户发送resync命令时，initialSyncRequested会设置为true，此时会强制重新开始⼀次initial sync

1.3 疑问点解释

1.3.1 全量同步数据的时候，会不会源数据的oplog被覆盖了导致全量同步失败？

在3.4版本及以后，不会。
下面这张图说明了3.4对全量同步的改进（图来自张友东博客）：
Image

官方文档是：

initial sync会在为每个集合复制文档时构所有集合索引。在早期版本（3.4之前）的MongoDB中，仅_id在此阶段构建索引。
Initial sync复制数据的时候会将新增的oplog记录存到本地（3.4新增）。
1.3.2 如果一个成员脱离了副本集，然后过了很长的时间，oplog已经被多次覆盖的时候，该节点再次加入进来，会直接进行replication吗？

不会的。
先看一个脱节成员重新加入日志：

2019-08-30T10:12:21.585+0800 I REPL     [replication-0] could not find member to sync from
2019-08-30T10:13:21.591+0800 I REPL     [rsBackgroundSync] sync source candidate: 127.0.0.1:40002
2019-08-30T10:13:21.592+0800 I REPL     [replication-0] We are too stale to use 127.0.0.1:40002 as a sync source. Blacklisting this sync source because our last fetched timestamp: Timestamp(1567098178, 2144) is before their earliest timestamp: Timestamp(1567123884, 133) for 1min until: 2019-08-30T10:14:21.592+0800
2019-08-30T10:13:21.592+0800 I REPL     [replication-0] sync source candidate: 127.0.0.1:40000
2019-08-30T10:13:21.592+0800 I REPL     [replication-0] We are too stale to use 127.0.0.1:40000 as a sync source. Blacklisting this sync source because our last fetched timestamp: Timestamp(1567098178, 2144) is before their earliest timestamp: Timestamp(1567123883, 1248) for 1min until: 2019-08-30T10:14:21.592+0800
2019-08-30T10:13:21.592+0800 I REPL     [replication-0] could not find member to sync from

这个副本集是三个节店（40000、40001、40002），当40001启动的时候，发现自己的最新数据比较副本集oplog的最旧的还要旧，就进入recovering状态。
那么这种情况如何解决呢？
官方提供了两种方法：

    1. 删除该节点全部数据，重新进行initial sync
    1. 复制（备份恢复）其他节点数据，然后进行同步（显然如果复制过来的数据恢复的时候副本集的oplog又被覆盖了，那么还是会进入recovering状态）

二、Replication

2.1 sync oplog的过程

全量同步结束后，Secondary就开始从结束时间点建立tailable cursor，不断的从同步源拉取oplog并重放应用到自身，这个过程并不是由一个线程来完成的，mongodb为了提升同步效率，将拉取oplog以及重放oplog分到了不同的线程来执行。
具体线程和作用如下（这部分暂时没有在官方文档找到，来自张友东大神博客）：

  • producer thread：这个线程不断的从同步源上拉取oplog，并加入到一个BlockQueue的队列里保存着，BlockQueue最大存储240MB的oplog数据，当超过这个阈值时，就必须等到oplog被replBatcher消费掉才能继续拉取。
  • replBatcher thread：这个线程负责逐个从producer thread的队列里取出oplog，并放到自己维护的队列里，这个队列最多允许5000个元素，并且元素总大小不超过512MB，当队列满了时，就需要等待oplogApplication消费掉
  • oplogApplication会取出replBatch thread当前队列的所有元素，并将元素根据docId（如果存储引擎不支持文档锁，则根据集合名称）分散到不同的replWriter线程，replWriter线程将所有的oplog应用到自身；等待所有oplog都应用完毕，oplogApplication线程将所有的oplog顺序写入到local.oplog.rs集合。

针对上面的叙述，画了一个图方便理解：
Image_2_

producer的buffer和apply线程的统计信息都可以通过db.serverStatus().metrics.repl来查询到。

2.2 对过程疑问点的解释

2.2.1 为什么oplog的回放要弄这么多的线程？

和mysql一样，一个线程做一个事情，拉取oplog是单线程，其他线程进行回放；多个回放线程加快速度。

2.2.2 为什么需要replBatcher线程来中转？

oplog重放时，要保持顺序性，⽽且遇到create、drop等DDL命令时，这些命令与其他的增删改查命令是不能并⾏执⾏的，⽽这些控制就是由replBatcher来完成的。

2.2.3 如何解决secondary节点oplog重放追不上primary问题？

方法一：设置更大的回放线程数

  * mongod命令行指定：mongod --setParameter replWriterThreadCount=32
  * 配置文件中指定
setParameter:
  replWriterThreadCount: 32

方法二：增大oplog的大小
方法三：将writeOpsToOplog步骤分散到多个replWriter线程来并发执行，看官方开发者日志已经实现了这个（在3.4.0-rc2版本）

2.3 注意事项
  • initial sync单线程复制数据，效率比较低，生产环境应该尽量避免initial sync出现，需合理配置oplog。
  • 新加⼊节点时，可以通过物理复制的⽅式来避免initial sync，将Primary上的dbpath拷⻉到新的节点，然后直接启动。
  • 当Secondary同步滞后是因为主上并发写入太高导致，db.serverStatus().metrics.repl.buffer的 sizeBytes值持续接近maxSizeBytes的时候，可通过调整Secondary上replWriter并发线程数来提升。

三、日志分析

3.1 初始化同步日志

将日志级别 verbosity设置为 1，然后过滤日志
cat mg36000.log |egrep "clone|index|oplog" >b.log
最后拿出过滤后的部分日志。
3.4.21新加入节点日志

因为日志太多，贴太多出来也没什么意义，下面贴出了对db01库的某个
集合的日志。
可以发现是先创建collection索引，然后clone集合数据和索引数据，这样就完成了该集合的clone。最后将配置改为下一个集合。

2019-08-21T16:50:10.880+0800 D STORAGE  [InitialSyncInserters-db01.test20] create uri: table:db01/index-27-154229953453504826 config: type=file,internal_page_max=16k,leaf_page_max=16k,checksum=on,prefix_compression=true,block_compressor=,,,,key_format=u,value_format=u,app_metadata=(formatVersion=8,infoObj={ "v" : 2, "key" : { "num" : 1 }, "name" : "num_1", "ns" : "db01.test2" }),
2019-08-21T16:50:10.882+0800 I INDEX    [InitialSyncInserters-db01.test20] build index on: db01.test2 properties: { v: 2, key: { num: 1.0 }, name: "num_1", ns: "db01.test2" }
2019-08-21T16:50:10.882+0800 I INDEX    [InitialSyncInserters-db01.test20]      building index using bulk method; build may temporarily use up to 500 megabytes of RAM
2019-08-21T16:50:10.882+0800 D STORAGE  [InitialSyncInserters-db01.test20] create uri: table:db01/index-28-154229953453504826 config: type=file,internal_page_max=16k,leaf_page_max=16k,checksum=on,prefix_compression=true,block_compressor=,,,,key_format=u,value_format=u,app_metadata=(formatVersion=8,infoObj={ "v" : 2, "key" : { "_id" : 1 }, "name" : "_id_", "ns" : "db01.test2" }),
2019-08-21T16:50:10.886+0800 I INDEX    [InitialSyncInserters-db01.test20] build index on: db01.test2 properties: { v: 2, key: { _id: 1 }, name: "_id_", ns: "db01.test2" }
2019-08-21T16:50:10.886+0800 I INDEX    [InitialSyncInserters-db01.test20]      building index using bulk method; build may temporarily use up to 500 megabytes of RAM
2019-08-21T16:50:10.901+0800 D INDEX    [InitialSyncInserters-db01.test20]      bulk commit starting for index: num_1
2019-08-21T16:50:10.906+0800 D INDEX    [InitialSyncInserters-db01.test20]      bulk commit starting for index: _id_
2019-08-21T16:50:10.913+0800 D REPL     [repl writer worker 11] collection clone finished: db01.test2
2019-08-21T16:50:10.913+0800 D REPL     [repl writer worker 11]     collection: db01.test2, stats: { ns: "db01.test2", documentsToCopy: 2000, documentsCopied: 2000, indexes: 2, fetchedBatches: 1, start: new Date(1566377410875), end: new Date(1566377410913), elapsedMillis: 38 }
2019-08-21T16:50:10.920+0800 D STORAGE  [InitialSyncInserters-db01.collection10] create uri: table:db01/index-30-154229953453504826 config: type=file,internal_page_max=16k,leaf_page_max=16k,checksum=on,prefix_compression=true,block_compressor=,,,,key_format=u,value_format=u,app_metadata=(formatVersion=8,infoObj={ "v" : 2, "key" : { "_id" : 1 }, "name" : "_id_", "ns" : "db01.collection1" }),

3.6.12加入新节点日志

3.6较3.4的区别是，复制数据库的线程明确了是：repl writer worker 进行重放（看文档其实3.4已经是如此了）
还有就是明确是用cursors来进行。
其他和3.4没有区别，也是创建索引，然后clone数据。
2019-08-22T13:59:39.444+0800 D STORAGE  [repl writer worker 9] create uri: table:db01/index-32-3334250984770678501 config: type=file,internal_page_max=16k,leaf_page_max=16k,checksum=on,prefix_compression=true,block_compressor=,,,,key_format=u,value_format=u,app_metadata=(formatVersion=8,infoObj={ "v" : 2, "key" : { "_id" : 1 }, "name" : "_id_", "ns" : "db01.collection1" }),log=(enabled=true)
2019-08-22T13:59:39.446+0800 I INDEX    [repl writer worker 9] build index on: db01.collection1 properties: { v: 2, key: { _id: 1 }, name: "_id_", ns: "db01.collection1" }
2019-08-22T13:59:39.446+0800 I INDEX    [repl writer worker 9]      building index using bulk method; build may temporarily use up to 500 megabytes of RAM
2019-08-22T13:59:39.447+0800 D REPL     [replication-1] Collection cloner running with 1 cursors established.
2019-08-22T13:59:39.681+0800 D INDEX    [repl writer worker 7]      bulk commit starting for index: _id_
2019-08-22T13:59:39.725+0800 D REPL     [repl writer worker 7] collection clone finished: db01.collection1
2019-08-22T13:59:39.725+0800 D REPL     [repl writer worker 7]     database: db01, stats: { dbname: "db01", collections: 1, clonedCollections: 1, start: new Date(1566453579439), end: new Date(1566453579725), elapsedMillis: 286 }
2019-08-22T13:59:39.725+0800 D REPL     [repl writer worker 7]     collection: db01.collection1, stats: { ns: "db01.collection1", documentsToCopy: 50000, documentsCopied: 50000, indexes: 1, fetchedBatches: 1, start: new Date(1566453579440), end: new Date(1566453579725), elapsedMillis: 285 }
2019-08-22T13:59:39.731+0800 D STORAGE  [repl writer worker 8] create uri: table:test/index-34-3334250984770678501 config: type=file,internal_page_max=16k,leaf_page_max=16k,checksum=on,prefix_compression=true,block_compressor=,,,,key_format=u,value_format=u,app_metadata=(formatVersion=8,infoObj={ "v" : 2, "key" : { "_id" : 1 }, "name" : "_id_", "ns" : "test.user1" }),log=(enabled=true)

4.0.11加入新节点日志

使用cursors，和3.6基本一致
2019-08-22T15:02:13.806+0800 D STORAGE  [repl writer worker 15] create uri: table:db01/index-30--463691904336459055 config: type=file,internal_page_max=16k,leaf_page_max=16k,checksum=on,prefix_compression=true,block_compressor=,,,,key_format=u,value_format=u,app_metadata=(formatVersion=8,infoObj={ "v" : 2, "key" : { "num" : 1 }, "name" : "num_1", "ns" : "db01.collection1" }),log=(enabled=false)
2019-08-22T15:02:13.816+0800 I INDEX    [repl writer worker 15] build index on: db01.collection1 properties: { v: 2, key: { num: 1.0 }, name: "num_1", ns: "db01.collection1" }
2019-08-22T15:02:13.816+0800 I INDEX    [repl writer worker 15]      building index using bulk method; build may temporarily use up to 500 megabytes of RAM
2019-08-22T15:02:13.816+0800 D STORAGE  [repl writer worker 15] create uri: table:db01/index-31--463691904336459055 config: type=file,internal_page_max=16k,leaf_page_max=16k,checksum=on,prefix_compression=true,block_compressor=,,,,key_format=u,value_format=u,app_metadata=(formatVersion=8,infoObj={ "v" : 2, "key" : { "_id" : 1 }, "name" : "_id_", "ns" : "db01.collection1" }),log=(enabled=false)
2019-08-22T15:02:13.819+0800 I INDEX    [repl writer worker 15] build index on: db01.collection1 properties: { v: 2, key: { _id: 1 }, name: "_id_", ns: "db01.collection1" }
2019-08-22T15:02:13.819+0800 I INDEX    [repl writer worker 15]      building index using bulk method; build may temporarily use up to 500 megabytes of RAM
2019-08-22T15:02:13.820+0800 D REPL     [replication-0] Collection cloner running with 1 cursors established.

3.2 复制日志

2019-08-22T15:15:17.566+0800 D STORAGE  [repl writer worker 2] create collection db01.collection2 { uuid: UUID("8e61a14e-280c-4da7-ad8c-f6fd086d9481") }
2019-08-22T15:15:17.567+0800 I STORAGE  [repl writer worker 2] createCollection: db01.collection2 with provided UUID: 8e61a14e-280c-4da7-ad8c-f6fd086d9481
2019-08-22T15:15:17.567+0800 D STORAGE  [repl writer worker 2] stored meta data for db01.collection2 @ RecordId(22)
2019-08-22T15:15:17.580+0800 D STORAGE  [repl writer worker 2] db01.collection2: clearing plan cache - collection info cache reset
2019-08-22T15:15:17.580+0800 D STORAGE  [repl writer worker 2] create uri: table:db01/index-43--463691904336459055 config: type=file,internal_page_max=16k,leaf_page_max=16k,checksum=on,prefix_compression=true,block_compressor=,,,,key_format=u,value_format=u,app_metadata=(formatVersion=8,infoObj={ "v" : 2, "key" : { "_id" : 1 }, "name" : "_id_", "ns" : "db01.collection2" }),log=(enabled=false)

参考：
https://docs.mongodb.com/v4.0/core/replica-set-sync/
https://docs.mongodb.com/v4.0/tutorial/resync-replica-set-member/#replica-set-auto-resync-stale-member
http://www.mongoing.com/archives/2369

文章标签：
云数据库 MongoDB 版
日志服务
索引
NoSQL
MongoDB
关键词：
云数据库 MongoDB 版副本集
云数据库 MongoDB 版原理
云数据库 MongoDB 版同步
云数据库 MongoDB 版副本集原理
云数据库 MongoDB 版副本集同步
相关实践学习
MongoDB数据库入门
MongoDB数据库入门实验。
快速掌握 MongoDB 数据库
本课程主要讲解MongoDB数据库的基本知识，包括MongoDB数据库的安装、配置、服务的启动、数据的CRUD操作函数使用、MongoDB索引的使用（唯一索引、地理索引、过期索引、全文索引等）、MapReduce操作实现、用户管理、Java对MongoDB的操作支持（基于2.x驱动与3.x驱动的完全讲解）。 通过学习此课程，读者将具备MongoDB数据库的开发能力，并且能够使用MongoDB进行项目开发。   相关的阿里云产品：云数据库 MongoDB版 云数据库MongoDB版支持ReplicaSet和Sharding两种部署架构，具备安全审计，时间点备份等多项企业能力。在互联网、物联网、游戏、金融等领域被广泛采用。 云数据库MongoDB版（ApsaraDB for MongoDB）完全兼容MongoDB协议，基于飞天分布式系统和高可靠存储引擎，提供多节点高可用架构、弹性扩容、容灾、备份回滚、性能优化等解决方案。 产品详情: https://www.aliyun.com/product/mongodb
南山123
目录
相关文章
数据知道
|
3月前
|
存储 缓存 NoSQL
MongoDB内部的存储原理
这篇文章详细介绍了MongoDB的内部存储原理，包括存储引擎WiredTiger的架构、btree与b+tree的比较、cache机制、page结构、写操作流程、checkpoint和WAL日志，以及分布式存储的架构。
数据知道
109 1
MongoDB内部的存储原理
土木林森
|
4月前
|
运维 监控 NoSQL
【MongoDB 复制集秘籍】Secondary 同步慢怎么办？深度解析与实战指南，让你的数据库飞速同步！
【8月更文挑战第24天】本文通过一个具体案例探讨了MongoDB复制集中Secondary成员同步缓慢的问题。现象表现为数据延迟增加，影响业务运行。经分析，可能的原因包括硬件资源不足、网络状况不佳、复制日志错误等。解决策略涵盖优化硬件（如增加内存、升级CPU）、调整网络配置以减少延迟以及优化MongoDB配置（例如调整`oplogSize`、启用压缩）。通过这些方法可有效提升同步效率，保证系统的稳定性和性能。
土木林森
109 4
想飞的雪糕
|
1月前
|
NoSQL 容灾 MongoDB
MongoDB主备副本集方案：两台服务器使用非对称部署的方式实现高可用与容灾备份
在资源受限的情况下，为了实现MongoDB的高可用性，本文探讨了两种在两台服务器上部署MongoDB的方案。方案一是通过主备身份轮换，即一台服务器作为主节点，另一台同时部署备节点和仲裁节点；方案二是利用`priority`设置实现自动主备切换。两者相比，方案二自动化程度更高，适合追求快速故障恢复的场景，而方案一则提供了更多的手动控制选项。文章最后对比了这两种方案与标准三节点副本集的优缺点，指出三节点方案在高可用性和数据一致性方面表现更佳。
想飞的雪糕
75 5
cqtianxin1
|
2月前
|
存储 NoSQL MongoDB
MongoDB 复制（副本集）
10月更文挑战第17天
cqtianxin1
42 2
MongoDB 复制（副本集）
公众号:码到三十五
|
6月前
|
存储 监控 NoSQL
MongoDB索引解析：工作原理、类型选择及优化策略
MongoDB索引解析：工作原理、类型选择及优化策略
公众号:码到三十五
189 1
数据知道
|
3月前
|
存储 NoSQL Shell
MongoDB复制（副本集）总结
这篇文章是关于MongoDB副本集的总结，包括复制原理、设置副本集、案例分析等内容。
数据知道
48 1
土木林森
|
4月前
|
C# 开发者 Windows
全面指南：WPF无障碍设计从入门到精通——让每一个用户都能无障碍地享受你的应用，从自动化属性到焦点导航的最佳实践
【8月更文挑战第31天】为了确保Windows Presentation Foundation (WPF) 应用程序对所有用户都具备无障碍性，开发者需关注无障碍设计原则。这不仅是法律要求，更是社会责任，旨在让技术更人性化，惠及包括视障、听障及行动受限等用户群体。
土木林森
95 0
香吧香
|
5月前
|
存储 NoSQL MongoDB
MongoDB 索引原理与索引优化
MongoDB 索引原理与索引优化
香吧香
118 1
嘟嘟嘟嘟嘟嘟
|
5月前
|
分布式计算 DataWorks NoSQL
DataWorks产品使用合集之怎么离线同步MongoDB的增量数据
DataWorks作为一站式的数据开发与治理平台，提供了从数据采集、清洗、开发、调度、服务化、质量监控到安全管理的全套解决方案，帮助企业构建高效、规范、安全的大数据处理体系。以下是对DataWorks产品使用合集的概述，涵盖数据处理的各个环节。
嘟嘟嘟嘟嘟嘟
78 7
金雪人
|
5月前
|
自然语言处理 运维 NoSQL
MongoDB集群同步
实现 MongoDB Cluster-to-Cluster 即集群同步的工具是：mongosync 详情可参考如下官方文档： https://www.mongodb.com/zh-cn/docs/cluster-to-cluster-sync/current/quickstart/ 以上这个地址的文档一看就是机器翻译的，可能有不恰当的地方，但基本可参考使用。 以下是本次在某项目地配置集群同步的简要步骤，可参考使用。
金雪人
95 6

热门文章

最新文章

  • 1
    MongoDB基础
  • 2
    docker安装mongodb
  • 3
    centos6.6部署Mongodb数据库主从同步
  • 4
    Adhesive框架系列文章--Mongodb数据服务模块实现（下）
  • 5
    MongoDB 应用场景 ？
  • 6
    CentOS 6.5安装MongoDB 2.6
  • 7
    【MongoDB学习笔记16】MongoDB的查询：find中的正则表达式
  • 8
    MongoDB数据库操作和程序基础文档
  • 9
    MongoDB用户权限篇
  • 10
    mongodb的安装
  • 1
    MongoDB Atlas Vector Search与Amazon Bedrock集成已全面可用
    2642
  • 2
    Fireworks AI和MongoDB：依托您的数据，借助优质模型，助力您开发高速AI应用
    2782
  • 3
    mongoDB查看数据的插入日志
    467
  • 4
    【MongoDB 专栏】MongoDB 在物联网（IoT）领域的应用
    515
  • 5
    【MongoDB 专栏】MongoDB 的分布式事务解决方案
    359
  • 6
    【MongoDB 专栏】MongoDB 的性能基准测试与评估
    303
  • 7
    【MongoDB 专栏】MongoDB 的内存管理与优化
    351
  • 8
    【MongoDB 专栏】MongoDB 的副本集故障转移与恢复
    365
  • 9
    【MongoDB 专栏】MongoDB 的日志管理与分析
    180
  • 10
    【MongoDB 专栏】MongoDB 与 Spring Boot 的集成实践
    253

    • 相关课程

    更多
  • MongoDB精讲课程（下）
  • MongoDB精讲课程（上）
  • MongoDB完全自学手册
  • 云数据库MongoDB版使用教程
  • 快速掌握 MongoDB 数据库
  • MongoDB快速入门

    • 相关电子书

    更多
  • Data as a Service - 数据即服务 -- MongoDB⾼级应⽤模式
  • 开源数据库 MongoDB 专场 MongoDB疑难杂症分析及优化
  • 饿了么高级架构师陈东明：MongoDB是如何逐步提高可靠性的

    • 相关实验场景

    更多
  • 如何快速连接云数据库RDS MySQL
  • MySQL引擎及架构优化
  • 云数据库MongoDB快速入门
  • PolarDB for PostgreSQL 闪回特性体验
  • 快速体验PolarDB开源数据库
  • 体验PolarDB MySQL多主集群

    • 推荐镜像

    更多
  • mongodb
  • postgresql
  • mysql
    • 下一篇
    DataWorks售前咨询