[英]What is the procedure to follow to restore Cassandra incremental backup when I have large number of files in backup directory
我提出這個問題是因為我在 DataStax Docs 上沒有看到任何特定的方法。
我在拍攝快照后啟用了備份,現在我看到備份目錄中有大約 20 萬個文件。 我不確定恢復它們的最佳方法是什么。
將它們全部復制到 Keyspace 表目錄並執行nodetool refresh <ks> <tbl>
但我沒有看到它按預期工作並且它拋出 StackOverflow 異常。 有沒有辦法解決這個問題?
到目前為止,我正在使用 16G Xmx。 我在日志中看到一些錯誤,如下所示。 這與 JVM 參數有關嗎?
ERROR [gbp-cass-49] [Reference-Reaper:1] 2020-07-29 18:49:01,704 Ref.java:223 - LEAK DETECTED: a reference (org.apache.cassandra.utils.concurrent.Ref$State @156d6370) to class org.apache.cassandra.utils.concurrent.WrappedSharedCloseable$Tidy@464162733:[Memory@[0..80), Memory@[0..a00)] was not released before the reference was garbage collected
nodetool refresh
在標准輸出上引發了以下錯誤:
error: null
-- StackTrace --
java.lang.AssertionError
at org.apache.cassandra.io.util.FileUtils.renameWithConfirm(FileUtils.java:178)
at org.apache.cassandra.io.util.FileUtils.renameWithConfirm(FileUtils.java:173)
at org.apache.cassandra.io.sstable.format.SSTableWriter.rename(SSTableWriter.java:273)
at org.apache.cassandra.db.ColumnFamilyStore.loadNewSSTables(ColumnFamilyStore.java:714)
at org.apache.cassandra.db.ColumnFamilyStore.loadNewSSTables(ColumnFamilyStore.java:658)
at org.apache.cassandra.service.StorageService.loadNewSSTables(StorageService.java:4555)
at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1466)
at javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1307)
at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1399)
at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:828)
at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323)
at sun.rmi.transport.Transport$1.run(Transport.java:200)
at sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$241(TCPTransport.java:683)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$177/1629407070.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
您的問題中確實沒有足夠的可操作信息來提供有意義的答案,但我會盡力做出回應。
增量備份允許您將數據副本卸載到服務器外存儲。 但是,由於 Cassandra 將每個刷新的 memtable 硬鏈接到backups/
目錄,因此它的內容可能會迅速增長,因此您需要對其進行管理。 這可以解釋為什么您最終得到 200K 備份。
增量備份旨在與快照結合使用,快照相當於大多數人認為的傳統意義上的完整備份。 將快照視為類似於冷備份,將增量備份視為自上次快照以來的增量。
這意味着每次在節點上拍攝快照時,都需要清除backups/
目錄中的增量備份。 接下來,當您恢復增量備份時,您需要恢復相應的快照(也稱為完整備份),然后應用增量備份(快照后的“增量”備份)。
為了回應您提出的其他觀點,您需要解釋“我認為它沒有按預期工作”的意思。 此外,完整的錯誤消息和異常的完整堆棧跟蹤是什么? 為了做出有意義的診斷,而不是“它不起作用”,需要這種詳細程度的細節。
您發布的錯誤可以忽略不計。 這只是Reference-Reaper
線程成功找到孤立引用並將它們釋放回池的消息。 它確實應該記錄在INFO
而不是ERROR
級別。
我希望這有幫助。 干杯!
[編輯]您在更新中發布給我的堆棧跟蹤看起來像您有文件系統權限問題。 C* 無法重命名文件,因此可能 (a) 擁有錯誤的所有權,(b) 不正確的權限,或 (c) 兩者兼而有之。 干杯!
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.