MongoDB Sharding 请勿复用已删除的 namespace
SERVER-17397: Dropping a Database or Collection in a Sharded Cluster may not fully succeed 是 MongoDB 里老大难的问题,库或集合删除操作如果没有完全执行成功,再新建相同名字的集合,可能导致读到老版本数据的问题。
集合分片原理
MongoDB sharding 分片原理参考 MongoDB Sharded cluster架构原理
总的来说,当用户对集合执行开启分片之后,集合分片的元数据会保存在 config server 的 config 集合里
config.collections
记录集合分片的元数据,根据哪个 shardKey 分片,集合是否已经被删除等元数据config.chunks
,记录各个 chunk(shardKey的某一段范围)对应的 shard 信息,用于路由请求- 各个 shard 里存储集合实际的数据
删除分片集合流程
- 删除所有 shard 里的对应的数据
- 删除 config.chunks 这个集合相关的chunk信息
- 修改 config.collections,标记集合已经删除
注:3.2+都是按上述流程操作,删除 Database 过程类似,还需要再额外操作 config.databases 集合,但本质上存在的问题类似
上述动作需要操作 config server 以及 所有的 shard,如果中间有步骤失败(一些很老的版本,并不是按照上述步骤执行,而且执行过程中可能没有严格检查返回的错误码,即使返回成功实际上内部可能执行失败),最终导致集合的部分数据仍然残留,没有完全清理干净。
如果这个集合名字重新被使用,再次调用 shardCollection 产生新的分片元数据,可能导致
- 在 shard 上的一些残留数据可能被读取到,而这些数据实际上应该被删除了
- mongos 没有成功更新路由信息,最终可能出现多个 mongos 看到的数据视图也不一致,有的 mongos 能读到数据,有的读不到(通过 `flushRouterConfig 命令可以强制刷新路由信息可解决)
解决方案
MongoDB sharding 删除集合/数据库涉及到多个节点进行操作,这些动作无法做到原子性,可能导致一个集合最终处于某种中间状态;复用该集合可能导致一写数据一致性问题。
- 使用 MongoDB 3.2+ 以上版本,大部分case,只要没有异常,删除集合动作都能正常完成的,复用集合名字问题一般问题也不大,但无法完全避免问题。
- 建议 Sharding 环境下,namespace 名字一旦被删除,不要再次复用
- 在需要复用 Namespace 的情况下,如果要确保不会有数据问题,每次可以按 drop collection workaround 确保相关数据被正确清理,并且路由信息被更新。
作者:张友东
原文链接
本文为云栖社区原创内容,未经允许不得转载。
抢阿里云新用户专属优惠权益,致电95187-1 !

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
-
上一篇
关系型数据库全表扫描分片详解
导读:数据总线(DBus)专注于数据的实时采集与实时分发,可以对IT系统在业务流程中产生的数据进行汇聚,经过转换处理后成为统一JSON的数据格式(UMS),提供给不同数据使用方订阅和消费,充当数仓平台、大数据分析平台、实时报表和实时营销等业务的数据源。 在上一篇关于DBus的文章(DBus 数据库表结构变更处理方案)中,我们主要介绍了在DBus的设计中,表结构变更及其带来的各种问题是如何处理的。本文则是从数据分片的角度出发,具体介绍DBus在数据采集的过程中,运用了什么样的分片策略和分片原理,以及过程中遇到的问题及解决方案。 一、分片策略 对于传统的关系型数据库,DBus通过提供全量数据拉取和增量数据采集两种途径满足用户数据采集需求。DBus数据抽取流程如下图所示(以mysql为例): 全量数据采集的主要原理是:根据主键、唯一索引、索引等信息,确定分片列。之所以分片列要根据主键、唯一索引、索引等选择,是因为这些列的数据在库里建立了良好索引,能提升数据扫描的效率。 根据选定的分片列,对数据进行拆片,确定每片数据的上下界,然后根据每片上下界,以6~8左右的并发度,进行数据拉取。(6~8左右...
-
下一篇
Python 之父再发文:构建一个 PEG 解析器
花下猫语: Python 之父在 Medium 上开了博客,现在写了两篇文章,本文是第二篇的译文。前一篇的译文 在此 ,宣布了将要用 PEG 解析器来替换当前的 pgen 解析器。 本文主要介绍了构建一个 PEG 解析器的大体思路,并介绍了一些基本的语法规则。根据 Python 之父的描述,这个 PEG 解析器还是一个很笼统的实验品,而他也预告了,将会在以后的系列文章中丰富这个解析器。 阅读这篇文章就像在读一篇教程,虽然很难看懂,但是感觉很奇妙:我们竟然可以见证 Python 之父如何考虑问题、如何作设计、如何一点一点地丰富功能、并且传授出来。这种机会非常难得啊! 我会持续跟进后续文章的翻译,由于能力有限,可能翻译中有不到位之处,恳请读者们批评指正。 本文原创并首发于公众号【Python猫】,未经授权,请勿转载。 原文地址:https://mp.weixin.qq.com/s/yUQPeqc_uSRGe5lUi50kVQ 原题 | Building a PEG Parser 作者 | Guido van Rossum(Python之父) 译者 | 豌豆花下猫(“Python猫”公众号作...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- MySQL数据库在高并发下的优化方案
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS关闭SELinux安全模块
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- MySQL8.0.19开启GTID主从同步CentOS8
- SpringBoot2全家桶,快速入门学习开发网站教程
- Dcoker安装(在线仓库),最新的服务器搭配容器使用
- Docker使用Oracle官方镜像安装(12C,18C,19C)