Hazelcast分區丟失行爲初始模式=「LAZY/EAGER」

Question

我想知道如何initial-mode =「LAZY/EAGER」行爲在一個分區丟失。

根據在線文檔 EAGER - 同步加載條目。電話設置爲getMap（）被阻塞而發生這種情況

我需要知道丟失的分區是如何加載在下列情況下，...

1）節點崩潰和丟失的分區時，有在另一個節點

備份

• 會丟失從數據庫或備份加載的分區數據嗎？
• 如果這是從DB加載的，初始模式=「LAZY/EAGER」如何影響地圖 加載？
• 將丟失的分區遷移到備份可用的節點還是可以遷移到完全的 新節點？

2）節點崩潰並且當存在的另一個節點

• 在這種情況下丟失的分區數據沒有任何備份將被從DB
• 如何初始模式=「延遲加載丟失的分區/ EAGER「在沒有任何備份時會影響地圖加載？

當初始模式=「懶」， 後立即分區丟失，我可以看到它在另一個節點搬遷，我想這僅僅是分區創建不與數據

在該圖像中可以看到的分區ID 87丟失的瞬間分區夏日示出了它的另一個節點重新定位

62-（LOM：FE44） = partionID - （分區鍵）

Answer 1

首先讓通過了解備份選項之間的根本差異開始： 同步 - 默認1備份數] 異步 - 默認0異步備份數]

默認情況下，我們有因爲很強的一致性： 客戶端map.put（foo） - >主要兩個線程：T1可運行線程存儲在主分區上，而T2存儲在備份上。 T1和T2在返回到客戶端之前加入。因此，一旦從map.put返回，數據將安全地存儲在兩個位置。

如果您將[backup-count]設置爲0並且[async-backup-count]> 0，那麼您將具有最終的一致性，因爲在返回給客戶端之前，T1和T2將會加入而不是;相反，一旦T1完成服務器返回到客戶端。

因此，現在讓我們來看看您的問題： 1）當另一個節點有備份時，節點崩潰並丟失分區 會丟失從數據庫或備份加載的分區數據嗎？ 我們還沒有討論過MapStore（這是將數據存儲到數據庫中的幾種方法之一），但是如果您已經實現了Map Store，那麼在發生緩存未命中時它將從那裏恢復。

如果這是從DB加載，初始模式=「LAZY/EAGER」如何影響地圖加載？ Lazy將僅加載分區數據（默認情況下爲數據的1/271）與Eager，它將加載完整的映射（數據的271/271）

將該丟失分區遷移到備份節點是可用的還是可以遷移到全新的節點？ 備份將立即從丟失的服務器恢復分區。現在主要的備份將請求新的備份。

2）當另一個節點中沒有任何備份時，節點崩潰並丟失分區 如果您未能設置[backup-count]和[async-backup-count]和MapStore，並且您沒有使用HotRestart，丟失數據。但是你必須改變我們的默認值才能創建這種情況。

在這種情況下，丟失的分區數據將從DB加載 當沒有任何備份時，初始模式=「LAZY/EAGER」如何影響映射加載？ 它再次確定將加載多少地圖數據，並且如果您有地圖存儲，則意味着將在您的數據庫上調用多少加載（鍵）。

希望這會有所幫助，