Перейти к основному содержимому

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

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

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

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

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

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

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

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

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

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 в качестве помощника.

    # Замените <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 v3.1. Вы можете избежать этой проблемы, обновив ваш кластер до v3.1 или более поздней версии.
  • Это решение не применимо, если более половины узлов 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) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.dbi.DbTree.checkReplicaWrite(DbTree.java:880) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.dbi.DbTree.doCreateDb(DbTree.java:579) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.dbi.DbTree.createInternalDb(DbTree.java:507) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.cleaner.ExtinctionScanner.openDb(ExtinctionScanner.java:357) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.cleaner.ExtinctionScanner.prepareForDbExtinction(ExtinctionScanner.java:1703) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.dbi.DbTree.doRemoveDb(DbTree.java:1208) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.dbi.DbTree.removeReplicaDb(DbTree.java:1261) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.impl.node.Replay.applyNameLN(Replay.java:996) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.impl.node.Replay.replayEntry(Replay.java:722) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.impl.node.Replica$ReplayThread.run(Replica.java:1225) ~[starrocks-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. Добавьте неисправный узел обратно в кластер.

    -- Добавить узел 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 в качестве помощника.

    # Замените <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 в вашем кластере до starrocks-bdb-je-18.3.16.jar (или обновить ваш кластер Selena до v3.0 или более поздней версии), следуя порядку сначала Followers, а затем 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 записывает и создает контрольную точку своих метаданных, но не может синхронизировать их с узлами Follower FE до того, как он зависнет. После перезапуска он становится узлом Follower. С грязными метаданными в контрольной точке узел Follower не может выполнить инкрементальное удаление своих метаданных, поэтому требуется полная синхронизация метаданных.

Обратите внимание, что это исключение будет выброшено при добавлении нового узла Follower в кластер. В этом случае вам не нужно предпринимать никаких действий. Если это исключение выбрасывается для существующего узла 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) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.dbi.EnvironmentImpl.checkIfInvalid(EnvironmentImpl.java:1835) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.dbi.EnvironmentImpl.checkOpen(EnvironmentImpl.java:1844) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.Environment.checkOpen(Environment.java:2697) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.Environment.getDatabaseNames(Environment.java:2455) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.starrocks.journal.bdbje.BDBEnvironment.getDatabaseNamesWithPrefix(BDBEnvironment.java:478) ~[starrocks-fe.jar:?]
        at com.starrocks.journal.bdbje.BDBJournalCursor.refresh(BDBJournalCursor.java:177) ~[starrocks-fe.jar:?]
        at com.starrocks.server.GlobalStateMgr$5.runOneCycle(GlobalStateMgr.java:2148) ~[starrocks-fe.jar:?]
        at com.starrocks.common.util.Daemon.run(Daemon.java:115) ~[starrocks-fe.jar:?]
        at com.starrocks.server.GlobalStateMgr$5.run(GlobalStateMgr.java:2216) ~[starrocks-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) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.stream.ReplicaFeederHandshake.execute(ReplicaFeederHandshake.java:250) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.impl.node.Replica.initReplicaLoop(Replica.java:709) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.impl.node.Replica.runReplicaLoopInternal(Replica.java:485) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.impl.node.Replica.runReplicaLoop(Replica.java:412) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.impl.node.RepNode.run(RepNode.java:1869) ~[starrocks-bdb-je-18.3.16.jar:?]

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

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

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) [StarRocksFE.start():186] StarRocksFE start failed
com.sleepycat.je.DatabaseNotFoundException: (JE 18.3.16) _jeRepGroupDB
        at com.sleepycat.je.rep.impl.RepImpl.openGroupDb(RepImpl.java:1974) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.impl.RepImpl.getGroupDb(RepImpl.java:1912) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.impl.RepGroupDB.reinitFirstNode(RepGroupDB.java:1439) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.impl.node.RepNode.reinitSelfElect(RepNode.java:1686) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.impl.node.RepNode.startup(RepNode.java:874) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.impl.node.RepNode.joinGroup(RepNode.java:2153) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.impl.RepImpl.joinGroup(RepImpl.java:618) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.ReplicatedEnvironment.joinGroup(ReplicatedEnvironment.java:558) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.ReplicatedEnvironment.<init>(ReplicatedEnvironment.java:619) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.ReplicatedEnvironment.<init>(ReplicatedEnvironment.java:464) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.ReplicatedEnvironment.<init>(ReplicatedEnvironment.java:538) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.util.DbResetRepGroup.reset(DbResetRepGroup.java:262) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.starrocks.journal.bdbje.BDBEnvironment.initConfigs(BDBEnvironment.java:188) ~[starrocks-fe.jar:?]
        at com.starrocks.journal.bdbje.BDBEnvironment.setup(BDBEnvironment.java:174) ~[starrocks-fe.jar:?]
        at com.starrocks.journal.bdbje.BDBEnvironment.initBDBEnvironment(BDBEnvironment.java:153) ~[starrocks-fe.jar:?]
        at com.starrocks.journal.JournalFactory.create(JournalFactory.java:31) ~[starrocks-fe.jar:?]
        at com.starrocks.server.GlobalStateMgr.initJournal(GlobalStateMgr.java:1201) ~[starrocks-fe.jar:?]
        at com.starrocks.server.GlobalStateMgr.initialize(GlobalStateMgr.java:1150) ~[starrocks-fe.jar:?]
        at com.starrocks.StarRocksFE.start(StarRocksFE.java:129) ~[starrocks-fe.jar:?]
        at com.starrocks.StarRocksFE.main(StarRocksFE.java:83) ~[starrocks-fe.jar:?]

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

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

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

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

failed to load journal type xxx

Или

catch exception when replaying
warning

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

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

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

  1. Выключите все узлы FE.

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

  3. Найдите ошибочный ID журнала в логах. xxx в следующем логе представляет ошибочный 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. Если запуск снова не удается, определите новый неудачный ID журнала через Шаг 3, добавьте его в fe.conf, а затем перезапустите узлы с неизменными предыдущими конфигурациями.

    metadata_journal_skip_bad_journal_ids=xxx,yyy

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

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

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

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

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

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

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

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

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

    SHOW PROC '/meta_recovery';

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

  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 не являются Followers.

  • Вы можете определить роль каждого узла 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

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

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

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 до v3.0 или более поздней версии, или обновления 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​

Вы можете просмотреть использование памяти 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 недостаточен.

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

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, либо использовать алгоритм сборки мусора G1.

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) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.util.ReplicationGroupAdmin.getMasterSocket(ReplicationGroupAdmin.java:186) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.util.ReplicationGroupAdmin.doMessageExchange(ReplicationGroupAdmin.java:607) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.sleepycat.je.rep.util.ReplicationGroupAdmin.getGroup(ReplicationGroupAdmin.java:406) ~[starrocks-bdb-je-18.3.16.jar:?]
        at com.starrocks.ha.BDBHA.getElectableNodes(BDBHA.java:178) ~[starrocks-fe.jar:?]
        at com.starrocks.common.proc.FrontendsProcNode.getFrontendsInfo(FrontendsProcNode.java:96) ~[starrocks-fe.jar:?]
        at com.starrocks.common.proc.FrontendsProcNode.fetchResult(FrontendsProcNode.java:80) ~[starrocks-fe.jar:?]
        at com.starrocks.sql.ast.ShowProcStmt.getMetaData(ShowProcStmt.java:74) ~[starrocks-fe.jar:?]
        at com.starrocks.qe.ShowExecutor.handleShowProc(ShowExecutor.java:872) ~[starrocks-fe.jar:?]
        at com.starrocks.qe.ShowExecutor.execute(ShowExecutor.java:286) ~[starrocks-fe.jar:?]
        at com.starrocks.qe.StmtExecutor.handleShow(StmtExecutor.java:1574) ~[starrocks-fe.jar:?]
        at com.starrocks.qe.StmtExecutor.execute(StmtExecutor.java:688) ~[starrocks-fe.jar:?]
        at com.starrocks.qe.ConnectProcessor.handleQuery(ConnectProcessor.java:336) ~[starrocks-fe.jar:?]
        at com.starrocks.qe.ConnectProcessor.dispatch(ConnectProcessor.java:530) ~[starrocks-fe.jar:?]
        at com.starrocks.qe.ConnectProcessor.processOnce(ConnectProcessor.java:838) ~[starrocks-fe.jar:?]
        at com.starrocks.mysql.nio.ReadListener.lambda$handleEvent$0(ReadListener.java:69) ~[starrocks-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/starrocks-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 правильно запущен и добавлен в кластер.
    • Если поле Role имеет значение LEADER, этот узел FE является узлом Leader FE.

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

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

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

    # Замените <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 обратно в кластер.

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

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

Восстановить метаданные на новом узле 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 в качестве помощника.

    # Замените <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

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

подсказка

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