Datastax OpsCenter 5.1 не может выполнить резервное копирование "All Keyspaces"

Недавно мы обновили серверы нашей компании (Datastax Enterprise 4.5.3) до DSE 4.6.0. Единственная проблема, с которой мы сталкиваемся, - это новая служба резервного копирования, в которой мы не можем создать резервную копию для "всех пространств ключей". Тем не менее, резервное копирование пространств клавиш по одному работает как шарм. Кажется, ошибка исходит от агента (ов) datastax, установленного на узлах, и я прилагаю столько деталей, сколько я могу вспомнить ниже.

Журнал событий OpsCenter:

Сбой резервного копирования всех пространств ключей: Сбой резервного копирования всех пространств ключей для следующих назначений: снимок

Снимок всех пространств ключей на узле не выполнен: clojure.lang.Compiler$CompilerException: java.lang.ClassFormatError: Неверный метод Длина кода 96939 в файле класса clojure/core$eval87, компиляция:(NO_SOURCE_PATH:0:0) (<узел-IP>)

Снимок всех пространств ключей на узле не выполнен: clojure.lang.Compiler$CompilerException: java.lang.ClassFormatError: Неверный метод Длина кода 96939 в файле класса clojure/core$eval87, компиляция:(NO_SOURCE_PATH:0:0) (<узел-IP>)

Вышеуказанная ошибка (снимок всех пространств ключей...) немного длиннее, поскольку она возникает один раз для каждого доступного узла в кластере, и в конце появляется ошибка "Резервное копирование всех пространств ключей:...".

В то же время все агенты datastax выдают следующее сообщение об ошибке:

 ОШИБКА [qtp1549990111-47] 2015-02-13 18:35:50,887 Необработанный маршрут
 Исключение: clojure.lang.Compiler $ CompilerException:
 java.lang.ClassFormatError: Неверный метод Длина кода 96939 в классе
 файл clojure/core$eval87, компилирование:(NO_SOURCE_PATH:0:0)
                      Compiler.java:6567 clojure.lang.Compiler.analyzeSeq
                      Compiler.java:6361 clojure.lang.Compiler.analyze
                      Compiler.java:6616 clojure.lang.Compiler.eval
                      Compiler.java:6608 clojure.lang.Compiler.eval
                      Compiler.java:6582 clojure.lang.Compiler.eval
                           core.clj:2852 clojure.core/eval
                           маршруты.clj:58 opsagent.http.routes/fn
                             core.clj:94 compojure.core/make-route[fn]
                             core.clj:40 compojure.core/if-route[fn]
                             core.clj:25 compojure.core/if-метод [fn]
                            core.clj:107 compojure.core/routing[fn]
                           core.clj:2443 clojure.core/some
                            core.clj:107 compojure.core/routing
                         RestFn.java:139 clojure.lang.RestFn.applyTo
                            core.clj:619 clojure.core/apply
                            core.clj:112 compojure.core/routs[fn]
                            Var.java:415 clojure.lang.Var.invoke
                       middleware.clj:93 opsagent.http.middleware/wrap-application-error[fn]
                       middleware.clj:75 opsagent.http.middleware/wrap-content-type[fn]
                      middleware.clj:112 opsagent.http.middleware/wrap-content-error[fn]
                       middleware.clj:31 opsagent.http.middleware/wrap-request-logging[fn]
                       middleware.clj:17 opsagent.http.middleware/wrap-opscenter-id-check[fn]
                      middleware.clj:123 opsagent.http.middleware/wrap-version-header[fn]
                   keyword_params.clj:32 ring.middleware.keyword-params/wrap-keyword-params[fn]
                           params.clj:58 ring.middleware.params/wrap-params[fn]
                            jetty.clj:19 opsagent.http.jetty/proxy-handler[fn]
                        (Неизвестный источник) opsagent.http.jetty.proxy$org.eclipse.jetty.server.handler.AbstractHandler$0.handle
                 HandlerWrapper.java:111 org.eclipse.jetty.server.handler.HandlerWrapper.handle
                         Server.java:349 org.eclipse.jetty.server.Server.handle
         AbstractHttpConnection.java:452 org.eclipse.jetty.server.AbstractHttpConnection.handleRequest
         AbstractHttpConnection.java:894 org.eclipse.jetty.server.AbstractHttpConnection.content
         AbstractHttpConnection.java:948 org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content
                     HttpParser.java:857 org.eclipse.jetty.http.HttpParser.parseNext
                     HttpParser.java:235 org.eclipse.jetty.http.HttpParser.parseAvailable
             AsyncHttpConnection.java:76 org.eclipse.jetty.server.AsyncHttpConnection.handle
          SelectChannelEndPoint.java:609 org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle
           SelectChannelEndPoint.java:45 org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run
               QueuedThreadPool.java:599 org.eclipse.jetty.util.thread.QueuedThreadPool.runJob
               QueuedThreadPool.java:534 org.eclipse.jetty.util.thread.QueuedThreadPool$3.run
                        (Неизвестный источник) java.lang.Thread.run Причина: java.lang.ClassFormatError: Неверный метод Длина кода 96939 в
 файл класса clojure/core$eval87
                        (Неизвестный источник) java.lang.ClassLoader.defineClass1
                        (Неизвестный источник) java.lang.ClassLoader.defineClass
                        (Неизвестный источник) java.lang.ClassLoader.defineClass
              DynamicClassLoader.java:46 clojure.lang.DynamicClassLoader.defineClass
                      Compiler.java:4663 clojure.lang.Compiler$ObjExpr.getCompiledClass
                      Compiler.java:3819 clojure.lang.Compiler$FnExpr.parse
                      Compiler.java:6558 clojure.lang.Compiler.analyzeSeq

  ИНФОРМАЦИЯ [qtp1549990111-47] 2015-02-13 18:35:50,888 HTTP::post
 /ops/take-snapshot {:req-id "c13bb101-2f9e-4880-8b1f-efc178f49b3e"} -
 500

Вышеуказанное относится к производственному кластеру из 5 узлов в 2 центрах обработки данных (значения по умолчанию Datastax, контроллеры домена Cassandra/Analytics и DseSimpleSnitch). DC аналитики работает с Spark и CFS. Я пробовал ту же процедуру (путь обновления 4.5.3->4.6.0-> Резервное копирование всех пространств ключей) в мой локальный кластер из 2 компьютеров (один Cassandra, один Analytics) с массивным набором данных меньшего размера, и он работает как чудо.

1 ответ

Решение

В OpsCenter 5.1 есть (известная) ошибка, которая приводит к сбою резервного копирования в определенных сценариях. К сожалению, похоже, у вас есть. Исправление будет в OpsCenter 5.1.1, которое скоро будет выпущено.

Обнаруженный вами обходной путь (резервное копирование для каждого пространства ключей) должен работать надежно.

Другие вопросы по тегам