Перейти к основному содержимому
Версия: 2.0.x

Восстановление метаданных

В этом разделе описывается, как восстановить метаданные в ваших cluster Selena, когда узлы FE сталкиваются с различными исключениями.

Как правило, прибегать к восстановлению метаданных необходимо только при возникновении одной из следующих проблем:

Проверьте возникшую проблему, следуйте решению, предоставленному в соответствующем разделе, и выполните рекомендуемые действия.

FE не удаётся перезапустить​

Узлы FE могут не перезапускаться, если метаданные повреждены или несовместимы с cluster после отката версии.

Несовместимость метаданных после отката​

При понижении версии cluster Selena узлы FE могут не перезапускаться, если метаданные несовместимы с теми, что были до понижения версии.

Вы можете определить эту проблему, если столкнулись со следующим исключением при понижении версии cluster:

UNKNOWN Operation Type xxx

Выполните следующие шаги для восстановления метаданных и запуска FE:

  1. Остановите все узлы FE.

  2. Сделайте резервную копию директорий метаданных meta_dir всех узлов FE.

  3. Добавьте конфигурацию metadata_ignore_unknown_operation_type = true в конфигурационные файлы fe.conf всех узлов FE.

  4. Запустите все узлы FE и проверьте целостность ваших данных и метаданных.

  5. Если данные и метаданные целы, выполните следующую команду для создания файла образа метаданных:

    ALTER SYSTEM CREATE IMAGE;

  6. После того как новый файл образа будет передан в директорию meta/image всех узлов FE, вы можете удалить конфигурацию metadata_ignore_unknown_operation_type= true из всех конфигурационных файлов FE и перезапустить узлы FE.

Повреждение метаданных​

Повреждение метаданных BDBJE и метаданных Selena приводит к сбоям при перезапуске.

Повреждение метаданных BDBJE​

Ошибка VLSN​

Вы можете определить ошибку VLSN по следующему сообщению:

recoveryTracker should overlap or follow on disk last VLSN of 6,684,650 recoveryFirst= 6,684,652 UNEXPECTED_STATE_FATAL: Unexpected internal state, unable to continue. Environment is invalid and must be closed.

Выполните следующие шаги для исправления этой проблемы:

  1. Очистите директорию метаданных meta_dir узла FE, который выдаёт это исключение.

  2. Перезапустите узел FE, используя Leader FE в качестве helper.

    # Замените <leader_ip> на IP-адрес (priority_networks)
    # узла Leader FE, а <leader_edit_log_port> (по умолчанию: 9010) на
    # edit_log_port узла Leader FE.
    ./fe/bin/start_fe.sh --helper <leader_ip>:<leader_edit_log_port> --daemon
подсказка
  • Эта ошибка исправлена в Selena v1.5.2. Вы можете избежать этой проблемы, обновив cluster до версии v1.5.2 или более поздней.
  • Это решение не применимо, если более половины узлов FE столкнулись с этой проблемой. Вы должны следовать инструкциям, предоставленным в разделе Крайние меры, чтобы исправить проблему.
RollbackException​

Вы можете определить эту проблему по следующему сообщению об ошибке:

must rollback 1 total commits(1 of which were durable) to the earliest point indicated by transaction id=-14752149 time=2022-01-12 14:36:28.21 vlsn=28,069,415 lsn=0x1174/0x16e durable=false in order to rejoin the replication group. All existing ReplicatedEnvironment handles must be closed and reinstantiated. Log files were truncated to file 0x4467, offset 0x269, vlsn 28,069,413 HARD_RECOVERY: Rolled back past transaction commit or abort. Must run recovery by re-opening Environment handles Environment is invalid and must be closed.

Эта проблема возникает, когда Leader FE записывает метаданные BDBJE, но не успевает синхронизировать их с Follower FE до зависания. После перезапуска бывший Leader становится Follower, что приводит к повреждению метаданных.

Для решения этой проблемы достаточно перезапустить этот узел ещё раз, чтобы удалить повреждённые метаданные.

ReplicaWriteException​

Вы можете определить эту проблему по ключевому слову removeReplicaDb в журнале FE fe.log.

Caused by: com.sleepycat.je.rep.ReplicaWriteException: (JE 18.3.16) Problem closing transaction 25000090. The current state is:REPLICA. The node transitioned to this state at:Fri Feb 23 01:31:00 UTC 2024 Problem seen replaying entry NameLN_TX/14 vlsn=1,902,818,939 isReplicated="1"  txn=-953505106 dbop=REMOVE Originally thrown by HA thread: REPLICA 10.233.132.23_9010_1684154162022(6)
        at com.sleepycat.je.rep.txn.ReadonlyTxn.disallowReplicaWrite(ReadonlyTxn.java:114) ~[selena-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.dbi.DbTree.checkReplicaWrite(DbTree.java:880) ~[selena-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.dbi.DbTree.doCreateDb(DbTree.java:579) ~[selena-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.dbi.DbTree.createInternalDb(DbTree.java:507) ~[selena-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.cleaner.ExtinctionScanner.openDb(ExtinctionScanner.java:357) ~[selena-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.cleaner.ExtinctionScanner.prepareForDbExtinction(ExtinctionScanner.java:1703) ~[selena-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.dbi.DbTree.doRemoveDb(DbTree.java:1208) ~[selena-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.dbi.DbTree.removeReplicaDb(DbTree.java:1261) ~[selena-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.impl.node.Replay.applyNameLN(Replay.java:996) ~[selena-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.impl.node.Replay.replayEntry(Replay.java:722) ~[selena-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.impl.node.Replica$ReplayThread.run(Replica.java:1225) ~[selena-bdb-je-18.3.16.jar:?]

Эта проблема возникает, когда версия BDBJE неисправного узла FE (v18.3.*) не совпадает с версией Leader FE (v7.3.7).

Выполните следующие шаги для исправления этой проблемы:

  1. Удалите неисправный узел Follower или Observer.

    -- Для удаления узла Follower замените <follower_host> на IP-адрес (priority_networks)
    -- узла Follower, а <follower_edit_log_port> (по умолчанию: 9010) на
    -- edit_log_port узла Follower.
    ALTER SYSTEM DROP FOLLOWER "<follower_host>:<follower_edit_log_port>";

    -- Для удаления узла Observer замените <observer_host> на IP-адрес (priority_networks)
    -- узла Observer, а <observer_edit_log_port> (по умолчанию: 9010) на
    -- edit_log_port узла Observer.
    ALTER SYSTEM DROP OBSERVER "<observer_host>:<observer_edit_log_port>";

  2. Добавьте неисправный узел обратно в cluster.

    -- Добавить узел Follower:
    ALTER SYSTEM ADD FOLLOWER "<follower_host>:<follower_edit_log_port>";

    -- Добавить узел Observer:
    ALTER SYSTEM ADD OBSERVER "<observer_host>:<observer_edit_log_port>";

  3. Очистите директорию метаданных meta_dir неисправного узла.

  4. Перезапустите неисправный узел, используя Leader FE в качестве helper.

    # Замените <leader_ip> на IP-адрес (priority_networks)
    # узла Leader FE, а <leader_edit_log_port> (по умолчанию: 9010) на
    # edit_log_port узла Leader FE.
    ./fe/bin/start_fe.sh --helper <leader_ip>:<leader_edit_log_port> --daemon

  5. После восстановления неисправного узла до здорового состояния вам необходимо обновить пакеты BDBJE в вашем cluster до selena-bdb-je-18.3.16.jar (или обновить cluster Selena до версии v1.5.2 или более поздней), следуя порядку: сначала Follower, затем Leader.

InsufficientLogException​

Вы можете определить эту проблему по следующему сообщению об ошибке:

xxx INSUFFICIENT_LOG: Log files at this node are obsolete. Environment is invalid and must be closed.

Эта проблема возникает, когда узлу Follower требуется полная синхронизация метаданных. Это может произойти в одной из следующих ситуаций:

  • Метаданные на узле Follower отстают от метаданных узла Leader, который уже выполнил CheckPoint метаданных. Узел Follower не может выполнить инкрементное обновление метаданных, поэтому требуется полная синхронизация метаданных.
  • Бывший узел Leader записывает и выполняет checkpoint своих метаданных, но не успевает синхронизировать их с узлами Follower FE до зависания. После перезапуска он становится узлом Follower. С повреждёнными метаданными, для которых выполнен checkpoint, узел Follower не может выполнить инкрементное удаление своих метаданных, поэтому требуется полная синхронизация метаданных.

Обратите внимание, что это исключение будет выброшено при добавлении нового узла Follower в cluster. В этом случае никаких действий предпринимать не нужно. Если это исключение выбрасывается для существующего узла Follower или узла Leader, достаточно перезапустить узел.

HANDSHAKE_ERROR: Error during the handshake between two nodes​

Вы можете определить эту проблему по следующему сообщению об ошибке:

2023-11-13 21:51:55,271 WARN (replayer|82) [BDBJournalCursor.wrapDatabaseException():97] failed to get DB names for 1 times!Got EnvironmentFailureExce
com.sleepycat.je.EnvironmentFailureException: (JE 18.3.16) Environment must be closed, caused by: com.sleepycat.je.EnvironmentFailureException: Environment invalid because of previous exception: (JE 18.3.16) 10.26.5.115_9010_1697071897979(1):/data1/meta/bdb A replica with the name: 10.26.5.115_9010_1697071897979(1) is already active with the Feeder:null HANDSHAKE_ERROR: Error during the handshake between two nodes. Some validity or compatibility check failed, preventing further communication between the nodes. Environment is invalid and must be closed.
        at com.sleepycat.je.EnvironmentFailureException.wrapSelf(EnvironmentFailureException.java:230) ~[selena-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.dbi.EnvironmentImpl.checkIfInvalid(EnvironmentImpl.java:1835) ~[selena-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.dbi.EnvironmentImpl.checkOpen(EnvironmentImpl.java:1844) ~[selena-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.Environment.checkOpen(Environment.java:2697) ~[selena-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.Environment.getDatabaseNames(Environment.java:2455) ~[selena-bdb-je-18.3.16.jar:?]
        at com.selena.journal.bdbje.BDBEnvironment.getDatabaseNamesWithPrefix(BDBEnvironment.java:478) ~[selena-fe.jar:?]
        at com.selena.journal.bdbje.BDBJournalCursor.refresh(BDBJournalCursor.java:177) ~[selena-fe.jar:?]
        at com.selena.server.GlobalStateMgr$5.runOneCycle(GlobalStateMgr.java:2148) ~[selena-fe.jar:?]
        at com.selena.common.util.Daemon.run(Daemon.java:115) ~[selena-fe.jar:?]
        at com.selena.server.GlobalStateMgr$5.run(GlobalStateMgr.java:2216) ~[selena-fe.jar:?]
Caused by: com.sleepycat.je.EnvironmentFailureException: Environment invalid because of previous exception: (JE 18.3.16) 10.26.5.115_9010_1697071897979(1):/data1/meta/bdb A replica with the name: 10.26.5.115_9010_1697071897979(1) is already active with the Feeder:null HANDSHAKE_ERROR: Error during the handshake between two nodes. Some validity or compatibility check failed, preventing further communication between the nodes. Environment is invalid and must be closed. Originally thrown by HA thread: UNKNOWN 10.26.5.115_9010_1697071897979(1) Originally thrown by HA thread: UNKNOWN 10.26.5.115_9010_1697071897979(1)
        at com.sleepycat.je.rep.stream.ReplicaFeederHandshake.negotiateProtocol(ReplicaFeederHandshake.java:198) ~[selena-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.stream.ReplicaFeederHandshake.execute(ReplicaFeederHandshake.java:250) ~[selena-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.impl.node.Replica.initReplicaLoop(Replica.java:709) ~[selena-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.impl.node.Replica.runReplicaLoopInternal(Replica.java:485) ~[selena-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.impl.node.Replica.runReplicaLoop(Replica.java:412) ~[selena-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.impl.node.RepNode.run(RepNode.java:1869) ~[selena-bdb-je-18.3.16.jar:?]

Эта проблема возникает, когда бывший узел Leader зависает и снова становится активным, в то время как выжившие узлы Follower пытаются выбрать нового Leader. Узлы Follower попытаются установить новое соединение с бывшим узлом Leader. Однако узел Leader отклонит запрос на соединение, потому что старое соединение всё ещё существует. После отклонения запроса узел Follower установит окружение как недействительное и выбросит это исключение.

Для решения этой проблемы вы можете либо увеличить размер JVM heap, либо использовать алгоритм G1 GC.

DatabaseNotFoundException​

Вы можете определить эту проблему по следующему сообщению об ошибке:

2024-01-05 12:47:21,087 INFO (main|1) [BDBEnvironment.ensureHelperInLocal():340] skip check local environment because helper node and local node are identical.
2024-01-05 12:47:21,339 ERROR (MASTER 172.17.0.1_9112_1704430041062(-1)|1) [SelenaFE.start():186] SelenaFE start failed
com.sleepycat.je.DatabaseNotFoundException: (JE 18.3.16) _jeRepGroupDB
        at com.sleepycat.je.rep.impl.RepImpl.openGroupDb(RepImpl.java:1974) ~[selena-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.impl.RepImpl.getGroupDb(RepImpl.java:1912) ~[selena-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.impl.RepGroupDB.reinitFirstNode(RepGroupDB.java:1439) ~[selena-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.impl.node.RepNode.reinitSelfElect(RepNode.java:1686) ~[selena-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.impl.node.RepNode.startup(RepNode.java:874) ~[selena-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.impl.node.RepNode.joinGroup(RepNode.java:2153) ~[selena-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.impl.RepImpl.joinGroup(RepImpl.java:618) ~[selena-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.ReplicatedEnvironment.joinGroup(ReplicatedEnvironment.java:558) ~[selena-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.ReplicatedEnvironment.<init>(ReplicatedEnvironment.java:619) ~[selena-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.ReplicatedEnvironment.<init>(ReplicatedEnvironment.java:464) ~[selena-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.ReplicatedEnvironment.<init>(ReplicatedEnvironment.java:538) ~[selena-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.util.DbResetRepGroup.reset(DbResetRepGroup.java:262) ~[selena-bdb-je-18.3.16.jar:?]
        at com.selena.journal.bdbje.BDBEnvironment.initConfigs(BDBEnvironment.java:188) ~[selena-fe.jar:?]
        at com.selena.journal.bdbje.BDBEnvironment.setup(BDBEnvironment.java:174) ~[selena-fe.jar:?]
        at com.selena.journal.bdbje.BDBEnvironment.initBDBEnvironment(BDBEnvironment.java:153) ~[selena-fe.jar:?]
        at com.selena.journal.JournalFactory.create(JournalFactory.java:31) ~[selena-fe.jar:?]
        at com.selena.server.GlobalStateMgr.initJournal(GlobalStateMgr.java:1201) ~[selena-fe.jar:?]
        at com.selena.server.GlobalStateMgr.initialize(GlobalStateMgr.java:1150) ~[selena-fe.jar:?]
        at com.selena.SelenaFE.start(SelenaFE.java:129) ~[selena-fe.jar:?]
        at com.selena.SelenaFE.main(SelenaFE.java:83) ~[selena-fe.jar:?]

Эта проблема возникает, когда вы добавляете конфигурацию metadata_failure_recovery = true в конфигурационный файл FE fe.conf.

Для решения этой проблемы необходимо удалить конфигурацию и перезапустить узел.

Повреждение метаданных Selena​

Вы можете определить проблему повреждения метаданных Selena по одному из следующих сообщений об ошибке:

failed to load journal type xxx

Или

catch exception when replaying
warning

Перед тем как приступить к восстановлению метаданных, следуя приведённому ниже решению, настоятельно рекомендуется обратиться за помощью к техническим экспертам сообщества Selena, поскольку это решение может привести к потере данных.

Выполните следующие шаги для исправления этой проблемы:

Игнорирование ошибочного Journal ID (предпочтительно)​

  1. Остановите все узлы FE.

  2. Сделайте резервную копию директорий метаданных всех узлов FE.

  3. Найдите ошибочный journal ID в журналах. xxx в следующем журнале представляет ошибочный journal ID.

    got interrupt exception or inconsistent exception when replay journal xxx, will exit

  4. Добавьте следующую конфигурацию во все файлы fe.conf и запустите узлы FE.

    metadata_journal_skip_bad_journal_ids=xxx

  5. Если запуск снова завершится неудачей, определите новый неудачный journal ID через шаг 3, добавьте его в fe.conf и перезапустите узлы с предыдущими конфигурациями без изменений.

    metadata_journal_skip_bad_journal_ids=xxx,yyy

  6. Если система всё ещё не запускается после вышеуказанных шагов, или если слишком много неудачных journal ID, перейдите к режиму восстановления.

Режим восстановления​

  1. Остановите все узлы FE.

  2. Сделайте резервную копию директорий метаданных meta_dir всех узлов FE.

  3. Добавьте конфигурацию metadata_enable_recovery_mode = true в конфигурационные файлы fe.conf всех узлов FE. Обратите внимание, что загрузка данных запрещена в этом режиме.

  4. Запустите все узлы FE и выполните запросы к таблицам в cluster, чтобы проверить целостность ваших данных.

    Необходимо дождаться завершения восстановления метаданных, если при запросе этих таблиц возвращается следующая ошибка:

    ERROR 1064 (HY000): capture_consistent_versions error: version already been compacted.

    Вы можете выполнить следующую команду с узла Leader FE для просмотра прогресса восстановления метаданных:

    SHOW PROC '/meta_recovery';

    Эта команда покажет partition, которые не удалось восстановить. Вы можете следовать возвращённым рекомендациям для восстановления partition. Если ничего не возвращается, это означает успешное восстановление.

  5. Если данные и метаданные целы, выполните следующую команду для создания файла образа метаданных:

    ALTER SYSTEM CREATE IMAGE;

  6. После того как новый файл образа будет передан в директорию meta/image всех узлов FE, вы можете удалить конфигурацию metadata_enable_recovery_mode = true из всех конфигурационных файлов FE и перезапустить узлы FE.

FE не может предоставлять сервисы​

FE не будет предоставлять сервисы, когда узлы Follower FE не могут выполнить выборы Leader. При возникновении этой проблемы вы можете обнаружить повторяющуюся запись в журнале:

wait globalStateMgr to be ready. FE type: INIT. is ready: false

Различные исключения могут вызвать эту проблему. Настоятельно рекомендуется устранять проблему поэтапно, следуя разделам ниже. Применение неподходящих решений усугубит проблему и, вероятно, приведёт к потере данных.

1. Большинство узлов Follower не работают​

Если большинство узлов Follower не работают, группа FE не будет предоставлять сервисы. Здесь «большинство» означает 1 + (количество узлов Follower/2). Обратите внимание, что узел Leader FE сам является Follower, но узлы Observer не являются Follower.

  • Вы можете определить роль каждого узла FE из файла fe/meta/image/ROLE:

    cat fe/meta/image/ROLE

    #Fri Jan 19 20:03:14 CST 2024
    role=FOLLOWER
    hostType=IP
    name=172.26.92.154_9312_1705568349984

  • Вы можете просмотреть общее количество узлов Follower из журнала BDBJE:

    grep "Current group size" fe/meta/bdb/je.info.0

    # Пример вывода показывает, что в cluster три узла Follower.
    2024-01-24 08:21:44.754 UTC INFO [172.26.92.139_29917_1698226672727] Current group size: 3

Для решения этой проблемы необходимо запустить все узлы Follower в cluster. Если их невозможно перезапустить, обратитесь к разделу Крайние меры.

2. IP-адрес узла изменился​

Если priority_networks узла не настроен, узел FE случайным образом выберет доступный IP-адрес при перезапуске. Если IP-адрес, записанный в метаданных BDBJE, отличается от того, который используется для запуска узла, FE не будет предоставлять сервисы.

  • Вы можете просмотреть IP-адрес, записанный в метаданных BDBJE, из файла fe/meta/image/ROLE:

    cat fe/meta/image/ROLE

    #Fri Jan 19 20:03:14 CST 2024
    role=FOLLOWER
    hostType=IP
    name=172.26.92.154_9312_1705568349984

    Значение 172.26.92.154 перед первым подчёркиванием — это IP-адрес, записанный в метаданных BDBJE.

  • Вы можете просмотреть IP-адрес, используемый для запуска узла, из журнала FE:

    grep "IP:" fe/log/fe.log

    2024-02-06 14:33:58,211 INFO (main|1) [FrontendOptions.initAddrUseIp():249] Use IP init local addr, IP: /172.17.0.1
    2024-02-06 14:34:27,689 INFO (main|1) [FrontendOptions.initAddrUseIp():249] Use IP init local addr, IP: /172.17.0.1

Для решения этой проблемы необходимо установить priority_networks узла в конфигурационном файле FE fe.conf на IP-адрес, записанный в fe/meta/image/ROLE, и перезапустить узел.

3. Системные часы между узлами не синхронизированы​

Вы можете определить эту проблему по следующему сообщению об ошибке из fe.out, fe.log или fe/meta//bdb/je.info.0:

com.sleepycat.je.EnvironmentFailureException: (JE 7.3.7) Environment must be closed, caused by: com.sleepycat.je.EnvironmentFailureException: Environment invalid because of previous exception: (JE 7.3.7) 172.26.92.139_29917_1631006307557(2180):xxx Clock delta: 11020 ms. between Feeder: 172.26.92.154_29917_1641969377236 and this Replica exceeds max permissible delta: 5000 ms. HANDSHAKE_ERROR: Error during the handshake between two nodes. Some validity or compatibility check failed, preventing further communication between the nodes. Environment is invalid and must be closed. fetchRoot of 0x1278/0x1fcbb8 state=0 expires=never

Необходимо синхронизировать системные часы на всех узлах.

4. Недостаточно свободного места на диске​

После обновления Selena до версии v1.5.2 или более поздней, или обновления BDBJE до версии v18 или более поздней, узел может не перезапуститься, если свободное пространство на диске, где хранится meta_dir, составляет менее 5 ГБ.

Вы можете просмотреть версию BDBJE из пакета .jar в директории fe/lib.

Для решения этой проблемы вы можете расширить диск или выделить отдельный диск большей ёмкости для метаданных FE.

5. edit_log_port изменён​

Если edit_log_port, записанный в метаданных BDBJE, отличается от того, который настроен в fe.conf, FE не будет предоставлять сервисы.

Вы можете просмотреть edit_log_port, записанный в метаданных BDBJE, из файла fe/meta/image/ROLE:

cat fe/meta/image/ROLE

#Fri Jan 19 20:03:14 CST 2024
role=FOLLOWER
hostType=IP
name=172.26.92.154_9312_1705568349984

Значение 9312 перед вторым подчёркиванием — это edit_log_port, записанный в метаданных BDBJE.

Для решения этой проблемы необходимо установить edit_log_port узла в конфигурационном файле FE fe.conf на edit_log_port, записанный в fe/meta/image/ROLE, и перезапустить узел.

6. Недостаточный размер JVM heap​

Вы можете просмотреть использование памяти JVM с помощью команды jstat:

jstat -gcutil pid 1000 1000

  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
  0.00 100.00  27.78  95.45  97.77  94.45     24    0.226     1    0.065    0.291
  0.00 100.00  44.44  95.45  97.77  94.45     24    0.226     1    0.065    0.291
  0.00 100.00  55.56  95.45  97.77  94.45     24    0.226     1    0.065    0.291
  0.00 100.00  72.22  95.45  97.77  94.45     24    0.226     1    0.065    0.291
  0.00 100.00  88.89  95.45  97.77  94.45     24    0.226     1    0.065    0.291
  0.00 100.00   5.26  98.88  97.80  94.45     25    0.231     1    0.065    0.297
  0.00 100.00  21.05  98.88  97.80  94.45     25    0.231     1    0.065    0.297
  0.00 100.00  31.58  98.88  97.80  94.45     25    0.231     1    0.065    0.297
  0.00 100.00  47.37  98.88  97.80  94.45     25    0.231     1    0.065    0.297
  0.00 100.00  63.16  98.88  97.80  94.45     25    0.231     1    0.065    0.297
  0.00 100.00  73.68  98.88  97.80  94.45     25    0.231     1    0.065    0.297

Если проценты в поле O остаются высокими, это указывает на недостаточный размер JVM heap.

Для решения этой проблемы необходимо увеличить размер JVM heap.

7. Latch timeout. com.sleepycat.je.log.LogbufferPool_FullLatch​

Вы можете определить эту проблему по следующему сообщению об ошибке:

Environment invalid because of previous exception: xxx Latch timeout. com.sleepycat.je.log.LogbufferPool_FullLatch xxx'
        at com.sleepycat.je.EnvironmentFailureException.unexpectedState(EnvironmentFailureException.java:459)
        at com.sleepycat.je.latch.LatchSupport.handleTimeout(LatchSupport.java:211)
        at com.sleepycat.je.latch.LatchWithStatsImpl.acquireExclusive(LatchWithStatsImpl.java:87)
        at com.sleepycat.je.log.LogBufferPool.bumpCurrent(LogBufferPool.java:527)
        at com.sleepycat.je.log.LogManager.flushInternal(LogManager.java:1373)
        at com.sleepycat.je.log.LogManager.flushNoSync(LogManager.java:1337)
        at com.sleepycat.je.log.LogFlusher$FlushTask.run(LogFlusher.java:232)
        at java.util.TimerThread.mainLoop(Timer.java:555)
        at java.util.TimerThread.run(Timer.java:505)

Эта проблема возникает при чрезмерной нагрузке на локальный диск узла FE.

Для решения этой проблемы вы можете выделить отдельный диск для метаданных FE или заменить диск на более производительный.

8. InsufficientReplicasException​

Вы можете определить эту проблему по следующему сообщению об ошибке:

com.sleepycat.je.rep.InsufficientReplicasException: (JE 7.3.7) Commit policy: SIMPLE_MAJORITY required 1 replica. But none were active with this master.

Эта проблема возникает, когда узел Leader FE или узлы Follower FE используют чрезмерные ресурсы памяти, что приводит к Full GC.

Для решения этой проблемы вы можете либо увеличить размер JVM heap, либо использовать алгоритм G1 GC.

9. UnknownMasterException​

Вы можете определить эту проблему по следующему сообщению об ошибке:

com.sleepycat.je.rep.UnknownMasterException: (JE 18.3.16) Could not determine master from helpers at:[/xxx.xxx.xxx.xxx:9010, /xxx.xxx.xxx.xxx:9010]
        at com.sleepycat.je.rep.elections.Learner.findMaster(Learner.java:443) ~[selena-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.util.ReplicationGroupAdmin.getMasterSocket(ReplicationGroupAdmin.java:186) ~[selena-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.util.ReplicationGroupAdmin.doMessageExchange(ReplicationGroupAdmin.java:607) ~[selena-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.util.ReplicationGroupAdmin.getGroup(ReplicationGroupAdmin.java:406) ~[selena-bdb-je-18.3.16.jar:?]
        at com.selena.ha.BDBHA.getElectableNodes(BDBHA.java:178) ~[selena-fe.jar:?]
        at com.selena.common.proc.FrontendsProcNode.getFrontendsInfo(FrontendsProcNode.java:96) ~[selena-fe.jar:?]
        at com.selena.common.proc.FrontendsProcNode.fetchResult(FrontendsProcNode.java:80) ~[selena-fe.jar:?]
        at com.selena.sql.ast.ShowProcStmt.getMetaData(ShowProcStmt.java:74) ~[selena-fe.jar:?]
        at com.selena.qe.ShowExecutor.handleShowProc(ShowExecutor.java:872) ~[selena-fe.jar:?]
        at com.selena.qe.ShowExecutor.execute(ShowExecutor.java:286) ~[selena-fe.jar:?]
        at com.selena.qe.StmtExecutor.handleShow(StmtExecutor.java:1574) ~[selena-fe.jar:?]
        at com.selena.qe.StmtExecutor.execute(StmtExecutor.java:688) ~[selena-fe.jar:?]
        at com.selena.qe.ConnectProcessor.handleQuery(ConnectProcessor.java:336) ~[selena-fe.jar:?]
        at com.selena.qe.ConnectProcessor.dispatch(ConnectProcessor.java:530) ~[selena-fe.jar:?]
        at com.selena.qe.ConnectProcessor.processOnce(ConnectProcessor.java:838) ~[selena-fe.jar:?]
        at com.selena.mysql.nio.ReadListener.lambda$handleEvent$0(ReadListener.java:69) ~[selena-fe.jar:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) ~[?:?]
        at java.lang.Thread.run(Thread.java:829) ~[?:?]

При выполнении SHOW FRONTENDS, если узел Leader FE не может быть найден, может быть несколько причин:

  • Если наблюдается, что более половины узлов FE проходят Full GC, и продолжительность заметно велика.
  • Или если журнал содержит ключевое слово java.lang.OutOfMemoryError: Java heap space.

Это связано с недостаточным объёмом памяти. Необходимо увеличить выделение памяти JVM.

10. Крайние меры​

warning

Вы можете попробовать следующее решение как крайнюю меру только тогда, когда ни одно из предыдущих решений не работает.

Это решение предназначено только для экстремальных случаев, таких как:

  • Большинство узлов Follower не могут быть перезапущены.
  • Узлы Follower не могут выполнить выборы Leader из-за ошибок BDBJE.
  • Исключения, отличные от упомянутых в предыдущих разделах.

Выполните следующие шаги для восстановления метаданных:

  1. Остановите все узлы FE.

  2. Сделайте резервную копию директорий метаданных meta_dir всех узлов FE.

  3. Выполните следующие команды на всех серверах, на которых размещены узлы FE, чтобы определить узел с самыми последними метаданными.

    # Вам необходимо указать точный пакет .jar, который использует узел, в команде,
    # так как пакет варьируется в зависимости от версии Selena.
    java -jar fe/lib/selena-bdb-je-18.3.16.jar DbPrintLog -h meta/bdb/ -vd

    Пример вывода:

    <DbPrintLog>
    file 0x3b numRepRecords = 24479 firstVLSN = 1,434,126 lastVLSN = 1,458,604
    file 0x3c numRepRecords = 22541 firstVLSN = 1,458,605 lastVLSN = 1,481,145
    file 0x3d numRepRecords = 25176 firstVLSN = 1,481,146 lastVLSN = 1,506,321
    ......
    file 0x74 numRepRecords = 26903 firstVLSN = 2,927,458 lastVLSN = 2,954,360
    file 0x75 numRepRecords = 26496 firstVLSN = 2,954,361 lastVLSN = 2,980,856
    file 0x76 numRepRecords = 18727 firstVLSN = 2,980,857 lastVLSN = 2,999,583
    ... 0 files at end
    First file: 0x3b
    Last file: 0x76
    </DbPrintLog>

    Узел с наибольшим значением lastVLSN имеет самые последние метаданные.

  4. Найдите роль (Follower или Observer) узла FE с самыми последними метаданными из файла fe/meta/image/ROLE:

    cat fe/meta/image/ROLE

    #Fri Jan 19 20:03:14 CST 2024
    role=FOLLOWER
    hostType=IP
    name=172.26.92.154_9312_1705568349984

    Если несколько узлов имеют самые последние метаданные, рекомендуется продолжить с узлом Follower. Если несколько узлов Follower имеют самые последние метаданные, вы можете продолжить с любым из них.

  5. Выполните соответствующие операции в зависимости от роли узла FE, который вы выбрали на предыдущем шаге.

Если узел Follower имеет самые последние метаданные, выполните следующие операции:

  1. Добавьте следующие конфигурации в fe.conf:

    bdbje_reset_election_group = true

  2. Перезапустите узел и проверьте целостность ваших данных и метаданных.

  3. Проверьте, является ли текущий узел FE узлом Leader FE.

    SHOW FRONTENDS;
    • Если поле Alive имеет значение true, этот узел FE правильно запущен и добавлен в cluster.
    • Если поле Role имеет значение LEADER, этот узел FE является узлом Leader FE.

  4. Если данные и метаданные целы, и роль узла — Leader, вы можете удалить добавленную ранее конфигурацию и перезапустить узел.

  1. Очистите директории метаданных meta_dir узлов FE, которые вы хотите добавить обратно в cluster.

  2. Запустите новые узлы Follower, используя новый Leader FE в качестве helper.

    # Замените <leader_ip> на IP-адрес (priority_networks)
    # узла Leader FE, а <leader_edit_log_port> (по умолчанию: 9010) на
    # edit_log_port узла Leader FE.
    ./fe/bin/start_fe.sh --helper <leader_ip>:<leader_edit_log_port> --daemon

  3. Добавьте узлы Follower обратно в cluster.

    ALTER SYSTEM ADD FOLLOWER "<new_follower_host>:<new_follower_edit_log_port>";

После того как все узлы добавлены обратно в cluster, метаданные успешно восстановлены.

Восстановление метаданных на новом узле FE из резервной копии​

Выполните следующие шаги, если вы хотите запустить новый узел FE с резервной копией метаданных:

  1. Скопируйте резервную копию директории метаданных meta_dir на новый узел FE.

  2. В конфигурационном файле узла FE установите bdbje_reset_election_group в значение true.

    bdbje_reset_election_group = true

  3. Запустите узел FE.

    ./fe/bin/start_fe.sh

  4. Проверьте, является ли текущий узел FE узлом Leader FE.

    SHOW FRONTENDS;

    Если поле Role имеет значение LEADER, этот узел FE является узлом Leader FE. Убедитесь, что его IP-адрес соответствует адресу текущего узла FE.

  5. Если данные и метаданные целы, и роль узла — Leader, вы должны удалить конфигурацию bdbje_reset_election_group и перезапустить узел.

  6. Теперь вы успешно запустили новый узел Leader FE с резервной копией метаданных. Вы можете добавить новые узлы Follower, используя новый Leader FE в качестве helper.

    # Замените <leader_ip> на IP-адрес (priority_networks)
    # узла Leader FE, а <leader_edit_log_port> (по умолчанию: 9010) на
    # edit_log_port узла Leader FE.
    ./fe/bin/start_fe.sh --helper <leader_ip>:<leader_edit_log_port> --daemon

Конфигурации, связанные с восстановлением метаданных​

подсказка

Вы должны удалить следующие конфигурации после завершения восстановления метаданных.