云數據庫 MongoDB 版的oplog相關參數設置不合理可能會導致實例主從同步異常、實例無法按時間點恢復數據等問題，本文將指導您如何配置oplog相關參數并對相關的風險進行說明。
oplog基本信息
云數據庫 MongoDB 版副本集實例的主從復制是通過oplog（operations log）邏輯日志來完成的，oplog表（local.oplog.rs）是一個特殊的限制集合（capped collection），其中存儲了所有對數據庫中文檔的改動操作。oplog具備以下基礎特性：
在副本集中，寫入操作只會在主節點上完成并產生相應的oplog，其他從節點將異步復制這些oplog并在自身回放，以保持主從復制狀態。
如果某個操作并不改動任何文檔或者因某種原因失敗，則不會產生相應的oplog記錄。
一條oplog記錄在副本集中所有節點上都完全一致，回放并不會改變oplog表里的記錄。
oplog表中的每個操作都是冪等的。無論一條oplog記錄被回放了一次還是多次，得到的結果都是相同的。
oplog記錄是與時間相關聯的，oplog里每一條操作都有唯一的時間戳字段（ts）。該字段由UNIX時間戳和計數器兩部分組成，因此可以確定任意兩條oplog記錄之間的先后順序。
oplog窗口（
oplog window）代表著oplog表里最老的一條oplog記錄和最新的一條oplog記錄之間的時間差。主從復制依賴這個oplog窗口，只有在同步源的oplog窗口找到期望的oplog記錄時，從節點才能正常進行同步。從節點重啟或者新增節點后，也是依賴oplog里的記錄來確認自己能否成功成為副本集中正常的一員。如果發現自己期望的oplog記錄在同步源中找不到，就會因為
too stale to catch up的錯誤而變成異常的RECOVERING狀態。
oplog大小
在云數據庫 MongoDB 版中，oplog的默認大小是實例磁盤空間的10%（例如您實例的磁盤空間為500 GB，則相應的oplog大小就是50 GB）。oplog大小會隨著磁盤擴容而自動調整。
如需調整oplog大小，您可以在控制臺對replication.oplogSizeMB參數進行調整，調整后無需重啟，提交后即生效。如何修改配置參數，請參見設置數據庫參數。
您可使用以下兩種方式查看oplog表的實際大?。?/p>
在控制臺監控信息頁面的磁盤空間使用率指標中查看oplog表的實際大小。具體操作，請參見基本監控。
通過客戶端工具（mongo shell或mongosh）連接實例后，執行以下命令來查看oplog表的大小以及oplog窗口期。
rs.printReplicationInfo()示例的結果如下：
configured oplog size: 192MB log length start to end: 65422secs (18.17hrs) oplog first event time: Mon Jun 23 2014 17:47:18 GMT-0400 (EDT) oplog last event time: Tue Jun 24 2014 11:57:40 GMT-0400 (EDT) now: Thu Jun 26 2014 14:24:39 GMT-0400 (EDT)在示例中，oplog大小約為192MB，oplog窗口約為18小時。
oplog最小保留時間
從MongoDB 4.4版本開始，支持了oplog最小保留時間的配置文件項storage.oplogMinRetentionHours，讓您可以直接控制oplog的保留時間來確保足夠的oplog窗口。
默認情況下，該配置項的值為0，表示不設置oplog最小保留時間，此時oplog的清理還是由之前的oplog大小控制。如果設置了該配置項，oplog清理將在以下2個條件均滿足時發生：
oplog超過了配置的
oplogSizeMB。oplog的時間戳比oplog最小保留時間還早。
當oplog還沒有達到配置的oplogSizeMB時（例如實例剛初始化，還未寫入太多數據），實際的oplog窗口可能會比設置的oplog最小保留時間大很多，此時oplog表的大小只受oplogSizeMB限制；當達到配置的oplogSizeMB后，oplog表的大小受oplog最小保留時間限制，當oplog產生速度較快時，oplog的總大小可能會比配置的oplogSizeMB大很多。
如需調整oplog的保留時間，您可以在控制臺對storage.oplogMinRetentionHours參數進行調整，調整后無需重啟，提交后即生效。如何修改配置參數，請參見設置數據庫參數。
如需查看oplog的保留時間，您可以在控制臺監控信息頁面查看oplog保留時長指標。具體操作，請參見基本監控。
云數據庫 MongoDB 版日志備份
云數據庫 MongoDB 版所有實例的日志備份都基于oplog，相關管控服務進程會不斷拉取實例上最新的oplog記錄并流式上傳至OSS，形成一系列日志備份文件。在按時間點恢復時，這些日志備份文件會用來進行oplog回放。
特殊情況下，日志備份中可能會產生空洞而導致無法按時間點恢復，具體信息，請參見風險說明。
本文中提到的日志備份空洞與MongoDB術語中的oplog hole并不是一個概念。
最佳實踐
設置合理的oplog大小或oplog保留時間
通常情況下，oplog大小保持默認值即可，但是在以下場景的業務負載下，建議您調大oplog的大?。?/p>
經常對文檔進行批量更新
每一個批量更新的操作都會生成多條針對單個文檔的更新操作，這會產生大量的oplog記錄。
反復地插入和刪除
如果文檔插入一段時間后被刪除，那么數據庫的磁盤空間并不會有明顯增長，但oplog里會有很多相關記錄。
針對相同文檔的大量原地更新
如果業務場景中大部分操作是不會增加文檔大小的更新，這些更新會產生大量的oplog記錄，但磁盤上的數據量不會有明顯變化。
如果您的業務負載是以下類型，也可以酌情調小oplog大小，以更充分地利用磁盤空間：
讀多寫少的業務負載。
存儲冷數據。
無論是設置oplog大小還是oplog保留時間，都建議您盡量將MongoDB實例的oplog窗口控制在24小時以上。在一些需要額外進行初始化同步（initial sync）的場景，oplog窗口需要覆蓋一個節點完成所有數據同步的時間，該時間通常跟實例的整體數據量、庫表總數、實例規格等因素相關，oplog窗口可能會需要更長的時間。
關注從節點的延遲情況并配置好相關告警
當從節點出現延遲并且不斷變大時，一旦延遲時間超過了oplog窗口，從節點將會進入異常狀態無法恢復。因此，您需要關注MongoDB實例中的從節點延遲情況，并且在延遲不斷增加時及時提交工單聯系阿里云技術支持協助解決。
導致從節點出現延遲的原因有很多，包括：
網絡延遲、丟包、中斷等。
從節點的磁盤吞吐達到瓶頸。
{w:1}的writeConcern并且寫入負載比較重。某些內核缺陷導致從節點主從復制被阻塞。
其他未列出的原因。
您可使用以下兩種方式查看從節點的延遲情況：
在控制臺監控信息頁面的主備延遲指標中查看從節點的延遲情況。具體操作，請參見基本監控。
通過客戶端工具（mongo shell或mongosh）連接實例后，執行以下命令來查看從節點的延遲情況。
rs.printSecondaryReplicationInfo()示例的結果如下：
source: m1.example.net:27017 syncedTo: Thu Apr 10 2014 10:27:47 GMT-0400 (EDT) 0 secs (0 hrs) behind the primary source: m2.example.net:27017 syncedTo: Thu Apr 10 2014 10:27:47 GMT-0400 (EDT) 0 secs (0 hrs) behind the primary在示例中，2個從節點都沒有延遲。
您可以通過控制臺的報警規則功能，創建一條針對復制延遲的云監控告警，建議報警閾值設置為10秒以上。具體操作，請參見設置閾值報警規則。
風險說明
可能導致日志備份出現空洞的主要原因有以下兩種。
內核大版本低于3.4
周期性的空操作（periodic noop）是MongoDB內核在3.4大版本引入的，目的是為了適配readPreference的配套參數maxStalenessSeconds，詳情請參見SERVER-23892。該空操作的目的主要是在沒有業務寫入的情況下，確保oplog依然在不斷向前推進，由此可以判斷副本集中主從節點的落后情況。
當數據庫的內核大版本低于3.4時，如果很長時間都沒有業務寫入的情況，oplog不會再推進。因此，實例的日志備份也獲取不到新的oplog數據而導致出現日志備份空洞，進而導致出現實例無法按時間點恢復的情況。
實例寫入速度過快，oplog窗口太短
根據云數據庫 MongoDB 版長期以來積累的實例日志備份數據判斷，當一個實例的oplog產生速度達到125GB/h ~ 165GB/h左右時，就很有可能會出現日志備份無法跟上而導致產生日志備份空洞。
您可以通過前面提到的oplog大小以及oplog窗口來估算oplog產生速度。例如某個實例的oplog大小為20 GB，其oplog窗口為0.06h，則oplog生產速度大概是333.3GB/h。
這樣的工作負載一般都是以下場景：
DTS、mongoShake或其他數據同步工具正在同步數據。
短時間內大量的批量INSERT或UPDATE負載。
灌數據（將大量數據快速導入到數據庫中）。
壓力測試。
為了避免寫入速度過快而導致產生日志備份空洞，建議您考慮以下優化措施：
使用同步工具時進行適當的限速（比如并發度、批次大小）。
writeConcern使用
{w:"majority"}而不是{w:1}。
如果您的工作負載就是會有比較高的oplog生產速度，則應轉而考慮以下優化方向：
使用分片集群實例或者增加分片數來降低單個分片上的oplog生產速度。
結合業務場景適當調大oplog大小或者oplog最小保留時間，給日志備份預留更長的緩沖時間。使得在工作負載降低時日志備份可以追趕之前落后的oplog記錄。