当备份目录中有大量文件时,恢复cassandra增量备份的过程是什么

tzxcd3kk  于 2021-06-13  发布在  Cassandra
关注(0)|答案(1)|浏览(641)

我提出这个问题,因为我没有看到任何具体的方法对datasax文件。
我在拍摄快照后启用了备份,现在我看到备份目录中有大约200k个文件。我不知道什么是最好的方法来恢复他们。
将它们全部复制到keyspace表目录并执行 nodetool refresh <ks> <tbl> 但我不认为它像预期的那样工作,它抛出了stackoverflow异常。有办法解决这个问题吗?
我现在用的是16gxmx。我在下面的日志中看到一些错误。jvm参数就是这样吗?
错误[gbp-cass-49][参考-reaper:1]2020-07-29 18:49:01704参考。java:223 - 检测到泄漏:引用(org.apache.cassandra.utils.concurrent)。ref$state@156d6370)类org.apache.cassandra.utils.concurrent。wrappedsharedcloseable$tidy@464162733:[memory@[0..80),memory@[0..a00)]未在垃圾收集引用之前释放 nodetool refresh 在stdout上引发了以下错误:

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)
bkkx9g8r

bkkx9g8r1#

你的问题中确实没有足够的可操作的信息来提供有意义的答案,但我会尽力回答。
增量备份允许您将数据副本卸载到非服务器存储。但是,由于cassandra将每个刷新的memtable硬链接到 backups/ 目录,它的内容可以很快地增长,所以你需要管理它。这就解释了为什么最终会有20万个备份。
增量备份意味着与快照结合使用,快照相当于大多数人认为的传统意义上的完全备份。将快照视为类似于冷备份,将增量备份视为自上次快照以来的增量备份。
这意味着每次在节点上创建快照时,都需要清除 backups/ 目录。接着,当您恢复增量备份时,您需要恢复相应的快照(也称为完全备份),然后应用增量备份(快照之后的“增量”备份)。
为了回答你提出的其他问题,你需要解释你所说的“我认为它没有按预期工作”是什么意思。另外,异常的完整错误消息和完整堆栈跟踪是什么?为了做出一个有意义的诊断而不是“它不起作用”,需要这种程度的细节。
你发布的错误可以忽略。这只是一个信息 Reference-Reaper 线程成功地找到孤立引用并将它们释放回池。它真的应该被记录在 INFO 而不是 ERROR 水平。
我希望这有帮助。干杯!
[编辑]您在更新中发布给我的堆栈跟踪看起来您有文件系统权限问题。c*无法重命名文件,因此可能(a)拥有错误的所有权,(b)不正确的权限,或(c)两者都有。干杯!

相关问题