0
A
回答
0
899表示rowid已被分配。 由於NDB集羣的分佈式特性,這是一個問題。通常這是一個臨時問題,在幾微秒後消失。
如果它仍然存在,那麼可能有一些錯誤導致 主副本和備份副本不一致。
如果是這樣的情景讓 恢復正常運行的最佳方法是做到以下幾點: 1)取一個備份 2)執行數據節點 之一的初始節點重啓(假定你有2個數據節點)。
這個問題應該有希望消失。 備份只是爲了確保您有最新的備份 ,如果發生更多情況。
相關問題
- 1. 得到錯誤,同時從Excel
- 2. 'headers already'錯誤,同時使用restify與socket.io
- 3. 當Laravel使用php-resque時出現「Constant CRLF already defined」錯誤
- 4. 在wordpress中收到錯誤消息「headers already sent」
- 5. ndbCluster和Azure
- 6. 得到錯誤
- 7. 錯誤得到
- 8. 得到錯誤
- 9. 得到錯誤
- 10. 得到錯誤
- 11. 面臨CORS錯誤
- 12. 臨時文件中的rpmbuild錯誤
- 13. 錯誤 - ç採取的臨時
- 14. 臨時OTA分發安裝錯誤
- 15. Gmail SMTP錯誤 - 臨時阻止?
- 16. 臨時名稱解析錯誤
- 17. Oracle臨時表訪問錯誤
- 18. 錯誤:HTTP/1.1 302臨時移動
- 19. C + +錯誤:「臨時陣列的地址」
- 20. 錯誤在SQL Server本地臨時表
- 21. 錯誤:以臨時地址[-fpermissive]
- 22. 臨時表中不存在錯誤
- 23. 的Linux的rpmbuild臨時文件錯誤
- 24. 得到錯誤的sigabart誤差在iPhone上編譯時聲明
- 25. 「usermod:UID'0'already exists」why?
- 26. 從存儲引擎得到錯誤-1
- 27. 得到錯誤#1242,而從表
- 28. AndEngine錯誤TexturePackParser剛從github得到它
- 29. 我從MKRoute得到了錯誤的expectedTravelTime
- 30. 從SQL Python的選擇得到錯誤
我終於發現問題發生在幾天後,我發佈了這個問題。我有4個數據節點,其中一個節點在複製過程中遇到延遲,因爲我觀察到集羣啓動時頁面的複製。我已關閉受感染的節點,並且我的進程再次開始正常工作。謝謝btw – Dan