MongoDB的複製延遲和網路分割槽
Replication: when everything is working, it seems the easiest thing, but the challenge comes when we have failures. This is something that MongoDB, being a database that is out for some years, shows us very well.
If you look at MongoDB's replication page, there is a section called "Rollback". This applies when there is a replication lag - your secondary is behind the primary - in conjunction with a network partition. It may look like, but it's not a scenario that uncommon.
What happens then? Since the primary is ahead of the secondary, if it wants to rejoin the cluster, it needs to somehow "resync" to the current state. This means that operations applied previously but not replicated (due to the lag) will need to be rolled back. First, this process in MongoDB is manual.But what happens then if your secondary was behind a large amount of data - more precisely, 300Mb or more? MongoDB does not have the capability of rolling back and manual intervention is required to recover that node.
If you look at MongoDB's replication page, there is a section called "Rollback". This applies when there is a replication lag - your secondary is behind the primary - in conjunction with a network partition. It may look like, but it's not a scenario that uncommon.
What happens then? Since the primary is ahead of the secondary, if it wants to rejoin the cluster, it needs to somehow "resync" to the current state. This means that operations applied previously but not replicated (due to the lag) will need to be rolled back. First, this process in MongoDB is manual.But what happens then if your secondary was behind a large amount of data - more precisely, 300Mb or more? MongoDB does not have the capability of rolling back and manual intervention is required to recover that node.
Read for yourself:
Warning: A mongod instance will not rollback more than 300 megabytes of data. If your system needs to rollback more than 300 MB, you will need to manually intervene to recover this data.
Although it supports asynchronous replication (the eventual consistency), it does not solve these resynchronization problems automatically. Maybe it was just deemed as not very common and low priority compared to other features, but can you imagine the pain if you need to go through this process?
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/301743/viewspace-745533/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- PostgreSQL中的複製延遲SQL
- MySQL 8 複製(三)——延遲複製與部分複製MySql
- mysql主從延遲複製MySql
- MySQL 5.7 延遲複製配置MySql
- MySQL之 從複製延遲問題排查MySql
- MySQL主從複製延遲解決方案MySql
- mysql同步(複製)延遲的原因及解決方案MySql
- 如何利用PostgreSQL的延遲複製實現災備SQL
- mysql的主從複製資料延遲問題MySql
- 主從複製延遲推薦解決方案
- Mysql 非同步複製延遲的原因及解決方案MySql非同步
- MySQL主從複製延遲原因及處理思路MySql
- python檢測網路延遲Python
- Fiddler(8)設定網路丟包和延遲
- 記一次 MySQL 主從複製延遲的踩坑MySql
- 網路延遲對事務的影響
- 網際網路專案中“延遲”分析
- 如何利用網路延遲穿越時空
- OGG複製程式延遲高,優化方法一(使用索引)優化索引
- 故障分析 | MySQL 異地從庫複製延遲案例一則MySql
- MongoDB學習4:MongoDB複製集機制和原理,搭建複製集MongoDB
- 4種Kafka網路中斷和網路分割槽場景分析Kafka
- 阿里雲 DTS 網路延遲為那般 ?阿里
- MariaDB 10之並行複製–延遲測試結果薦並行
- 香港地域ECS網路延遲異常通知公告
- 網路丟包,網路延遲,這款神器幫你搞定所有
- mongodb複製集MongoDB
- mongodb複製+分片MongoDB
- 網路資料庫的複製和同步(轉)資料庫
- 乙太網交換機中的網路延遲是什麼呢?
- PostgreSQL 13 同步流複製+延遲備庫(#2.5)-202104SQL
- mysql的主從複製延遲問題--看這一篇就夠了MySql
- MySQL 8.0能徹底解決困擾運維的複製延遲問題!MySql運維
- oracle分割槽表和分割槽表exchangeOracle
- 3.官方優化建議3.1網路延遲優化
- MySQL分割槽表的分割槽原理和優缺點MySql
- 《RHEL6硬碟的分割槽和swap分割槽管理》——硬碟分割槽的大總結硬碟
- 【學習筆記】分割槽表和分割槽索引——分割槽表的其他管理(三)筆記索引