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之 從複製延遲問題排查MySql
- MySQL主從複製延遲解決方案MySql
- mysql同步(複製)延遲的原因及解決方案MySql
- 如何利用PostgreSQL的延遲複製實現災備SQL
- Fiddler(8)設定網路丟包和延遲
- 主從複製延遲推薦解決方案
- Mysql 非同步複製延遲的原因及解決方案MySql非同步
- MySQL主從複製延遲原因及處理思路MySql
- PostgreSQL 13 同步流複製+延遲備庫(#2.5)-202104SQL
- 網路延遲對事務的影響
- 4種Kafka網路中斷和網路分割槽場景分析Kafka
- 如何利用網路延遲穿越時空
- 阿里雲 DTS 網路延遲為那般 ?阿里
- OGG複製程式延遲高,優化方法一(使用索引)優化索引
- 在Linux中,mysql 如何減少主從複製延遲?LinuxMySql
- PostgreSQL 13 非同步流複製+延遲備庫(#2.2)-202103SQL非同步
- MongoDB學習4:MongoDB複製集機制和原理,搭建複製集MongoDB
- 故障分析 | MySQL 異地從庫複製延遲案例一則MySql
- oracle分割槽表和分割槽表exchangeOracle
- oracle分割槽表和非分割槽表exchangeOracle
- mongodb複製集MongoDB
- oracle 分割槽表move和包含分割槽表的lob moveOracle
- 移動分割槽表和分割槽索引的表空間索引
- 【每日一題】743. 網路延遲時間每日一題
- 網路丟包,網路延遲,這款神器幫你搞定所有
- Hive的分割槽和排序Hive排序
- MySQL 8.0能徹底解決困擾運維的複製延遲問題!MySql運維
- mysql的主從複製延遲問題--看這一篇就夠了MySql
- Flink 鏈路延遲測量
- esp32筆記[17]-顯示網路延遲筆記
- 乙太網交換機中的網路延遲是什麼呢?
- MongoDB 搭建複製集MongoDB
- MongoDB 複製機制MongoDB
- 網際網路公司為啥都不用MySQL分割槽表?MySql
- OGG複製程式延遲高,優化方法二(存在索引),SQL選擇不好的索引優化索引SQL
- 實現簡單延遲佇列和分散式延遲佇列佇列分散式