Activemq資料安全機制——Activemq中的KahaDB訊息日誌的恢復機制
阿新 • • 發佈：2019-01-24
KahaDB 支援多種機制在系統異常關閉後重啟並恢復。包括檢測資料檔案丟失和還原損壞的metadata。這些特性並不能完全保證系統異常關閉不造成訊息丟失。如果需要保證系統的高可靠性，建議部署到容災系統上。例如RAID磁碟陣列中。
當broker正常關閉時， KahaDB message store會將所有的快取資料刷到檔案系統中。尤其是這些資料：
1、所有未處理的日誌資料
2、所有快取的metadata
最後meta store中的資訊與journal資料檔案中的資料保持一致性。
正常情況下，在系統恢復時優先讀取journal中的資料。因為metacache中的索引資訊是週期性的更新到meta store中的。當系統異常關閉時，可能journal中有的資料meta store中並沒有不存在索引。但是KahaDB在恢復時會先讀取meta store中的資料，然後再讀取journal有但是meta store不存在的資料（因為KahaDB根據meta store中的索引資訊快速定位到metastore沒有但是journal檔案中包含的資料，然後根據這些資料重新在meta store中建立索引資訊）
KahaDB會在更新metadata store之前，儲存更新操作的概要資訊到重做日誌(db.redo)中。減少系統異常關閉時的風險。因為重做日誌非常小，所以在系統異常關閉時能快速寫入。當系統恢復時會判斷重做日誌中的資訊是否需要更新到metadata中。
如果 metadata store 已被不可挽回的損壞了，可以刪除metadata store檔案（db.data）來強制恢復；只不過這個時候，broker會讀取所有的journal檔案來重建metadata store，需要一段比較長的時間。
KahaDB可以檢測是否有journal檔案丟失，如果有丟失，預設將會丟擲一個異常然後關閉。便於管理員調查丟失的journal檔案，並手動還原。可以通過設定ignoreMissingJournalfiles為true，讓broker在啟動時忽略這些丟失的journal檔案。
KahaDB同樣可以檢測journal檔案的完整性。不過這些特性需要明確的配置來啟用。
KahaDB的各個可配置屬性：
當broker正常關閉時， KahaDB message store會將所有的快取資料刷到檔案系統中。尤其是這些資料：
1、所有未處理的日誌資料
2、所有快取的metadata
最後meta store中的資訊與journal資料檔案中的資料保持一致性。
正常情況下，在系統恢復時優先讀取journal中的資料。因為metacache中的索引資訊是週期性的更新到meta store中的。當系統異常關閉時，可能journal中有的資料meta store中並沒有不存在索引。但是KahaDB在恢復時會先讀取meta store中的資料，然後再讀取journal有但是meta store不存在的資料（因為KahaDB根據meta store中的索引資訊快速定位到metastore沒有但是journal檔案中包含的資料，然後根據這些資料重新在meta store中建立索引資訊）
KahaDB會在更新metadata store之前，儲存更新操作的概要資訊到重做日誌(db.redo)中。減少系統異常關閉時的風險。因為重做日誌非常小，所以在系統異常關閉時能快速寫入。當系統恢復時會判斷重做日誌中的資訊是否需要更新到metadata中。
如果 metadata store 已被不可挽回的損壞了，可以刪除metadata store檔案（db.data）來強制恢復；只不過這個時候，broker會讀取所有的journal檔案來重建metadata store，需要一段比較長的時間。
KahaDB可以檢測是否有journal檔案丟失，如果有丟失，預設將會丟擲一個異常然後關閉。便於管理員調查丟失的journal檔案，並手動還原。可以通過設定ignoreMissingJournalfiles為true，讓broker在啟動時忽略這些丟失的journal檔案。
KahaDB同樣可以檢測journal檔案的完整性。不過這些特性需要明確的配置來啟用。
- <persistenceAdapter>
- <kahaDBdirectory="activemq-data"
- journalMaxFileLength="32mb"
- checksumJournalFiles="true"
- checkForCorruptJournalFiles="true"
- />
- </persistenceAdapter>
KahaDB的各個可配置屬性：
| 屬性 | 預設值 | 描述 |
| directory | activemq-data | 儲存message store資料檔案的目錄 |
| indexWriteBatchSize | 1000 | 批量更新索引的閥值，當要更新的索引到達這個索引時，批量更新到metadata store中 |
| indexCacheSize | 10000 | 指定metadata cache的大小 |
| enableIndexWriteAsync | false | 寫入索引檔案到metadata store中的方式是否採用非同步寫入 |
| journalMaxFileLength | 32mb | 訊息持久資料檔案的大小 |
| enableJournalDiskSyncs | true | 如果為true，保證使用同步寫入的方式持久化訊息到journal檔案中 |
| cleanupInterval | 30000 | 清除（清除或歸檔）不再使用的journal 檔案的時間週期（毫秒）。 |
| checkpointInterval | 5000 | 寫入索引資訊到metadata store中的時間週期（毫秒） |
| ignoreMissingJournalfiles | false | 是否忽略丟失的journal檔案。如果為false，當丟失了journal檔案時，broker啟動時會拋異常並關閉 |
| checkForCorruptJournalFiles | false | 如果為true，broker在啟動的時候會檢測journal檔案是否損壞，若損壞便嘗試恢復它。 |
| checksumJournalFiles | false | 如果為true。KahaDB為journal檔案生產一個checksum，以便能夠檢測journal檔案是否損壞。 |
| archiveDataLogs | false | 如果為true，當達到cleanupInterval週期時，會歸檔journal檔案而不是刪除 |
| directoryArchive | null | 指定歸檔journal檔案存放的路徑 |
| databaseLockedWaitDelay | 10000 | 在使用主從資料庫備份時，等待獲取DB上的lock的延遲時間。 |
| maxAsyncJobs | 10000 | 等待寫入journal檔案的任務佇列的最大數量。應該大於或等於最大併發producer的數量。配合並行儲存轉發屬性使用。 |
| concurrentStoreAndDispatchTransactions | false | 如果為true，轉發訊息的時候同時提交事務 |
| concurrentStoreAndDispatchTopics | false | 如果為true，轉發Topic訊息的時候同時儲存訊息的message store中。 |
| concurrentStoreAndDispatchQueues | true |
如果為true，轉發Queue訊息的時候同時儲存訊息到message store中。 |