メインコンテンツまでスキップ
バージョン: 3.1

メタデータのリカバリ

このトピックでは、FE ノードがさまざまな例外に遭遇したときに、StarRocks クラスターのメタデータをリカバリする方法について説明します。

一般的に、次のいずれかの問題が発生した場合にのみ、メタデータのリカバリを行う必要があります。

遭遇した問題を確認し、対応するセクションで提供されている解決策に従い、推奨されるアクションを実行してください。

FE が再起動に失敗する​

FE ノードは、メタデータが破損しているか、ロールバック後にクラスターと互換性がない場合、再起動に失敗することがあります。

ロールバック後のメタデータの非互換性​

StarRocks クラスターをダウングレードすると、メタデータがダウングレード前と互換性がない場合、FEs が再起動に失敗することがあります。

クラスターをダウングレードする際に次の例外が発生した場合、この問題を特定できます。

UNKNOWN Operation Type xxx

次の手順に従ってメタデータをリカバリし、FE を起動できます。

  1. すべての FE ノードを停止します。

  2. すべての FE ノードのメタデータディレクトリ meta_dir をバックアップします。

  3. すべての FE ノードの設定ファイル fe.conf に設定 ignore_unknown_log_id = true を追加します。

  4. すべての FE ノードを起動し、データとメタデータが無事かどうかを確認します。

  5. データとメタデータが無事であれば、次のステートメントを実行してメタデータのイメージファイルを作成します。

    ALTER SYSTEM CREATE IMAGE;

  6. 新しいイメージファイルがすべての FE ノードのディレクトリ meta/image に転送された後、すべての FE 設定ファイルから設定 ignore_unknown_log_id = true を削除し、FE ノードを再起動できます。

メタデータの破損​

BDBJE メタデータと StarRocks メタデータの両方の破損は、再起動の失敗を引き起こします。

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. この例外を投げる FE ノードのメタデータディレクトリ meta_dir をクリアします。

  2. Leader FE ノードをヘルパーとして使用して FE ノードを再起動します。

    # <leader_ip> を Leader FE ノードの IP アドレス (priority_networks) に置き換え、
    # <leader_edit_log_port> (デフォルト: 9010) を Leader FE ノードの edit_log_port に置き換えます。
    ./fe/bin/start_fe.sh --helper <leader_ip>:<leader_edit_log_port> --daemon
ヒント
  • このバグは StarRocks 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​

FE ログ fe.log からキーワード removeReplicaDb に基づいてこの問題を特定できます。

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:?]

この問題は、失敗した FE ノードの BDBJE バージョン (v18.3.16) が Leader FE ノードのバージョン (v7.3.7) と一致しない場合に発生します。

次の手順に従ってこの問題を修正できます。

  1. 失敗した Follower または Observer ノードを削除します。

    -- Follower ノードを削除するには、<follower_host> を Follower ノードの IP アドレス (priority_networks) に置き換え、
    -- <follower_edit_log_port> (デフォルト: 9010) を Follower ノードの edit_log_port に置き換えます。
    ALTER SYSTEM DROP FOLLOWER "<follower_host>:<follower_edit_log_port>";

    -- Observer ノードを削除するには、<observer_host> を Observer ノードの IP アドレス (priority_networks) に置き換え、
    -- <observer_edit_log_port> (デフォルト: 9010) を Observer ノードの edit_log_port に置き換えます。
    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> を Leader FE ノードの IP アドレス (priority_networks) に置き換え、
    # <leader_edit_log_port> (デフォルト: 9010) を Leader FE ノードの edit_log_port に置き換えます。
    ./fe/bin/start_fe.sh --helper <leader_ip>:<leader_edit_log_port> --daemon

  5. 失敗したノードが正常な状態に回復した後、クラスター内の BDBJE パッケージを starrocks-bdb-je-18.3.16.jar にアップグレードする必要があります (または StarRocks クラスターを v3.0 以降にアップグレードします)。この際、まず Follower を、次に Leader をアップグレードします。

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 ノードまたは Follower ノードが過剰なメモリリソースを使用し、Full GC を引き起こす場合に発生します。

この問題を解決するには、JVM ヒープサイズを増やすか、G1 GC アルゴリズムを使用することができます。

InsufficientLogException​

次のエラーメッセージに基づいてこの問題を特定できます。

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

この問題は、Follower ノードが完全なメタデータ同期を必要とする場合に発生します。次のいずれかの状況が発生した場合に発生する可能性があります。

  • Follower ノードのメタデータが Leader ノードのメタデータよりも遅れており、Leader ノードがすでにメタデータのチェックポイントを行っている。Follower ノードはメタデータの増分更新を行えず、完全なメタデータ同期が必要です。
  • 元の Leader ノードがメタデータを書き込み、チェックポイントを行ったが、ハングする前に Follower FE ノードに同期できなかった。再起動後、Follower ノードになり、汚れたメタデータがチェックポイントされているため、Follower ノードはメタデータの増分削除を行えず、完全なメタデータ同期が必要です。

この例外は、新しい Follower ノードがクラスターに追加されたときにスローされます。この場合、何もアクションを取る必要はありません。この例外が既存の Follower ノードまたは Leader ノードに対してスローされた場合、ノードを再起動するだけで済みます。

HANDSHAKE_ERROR: 2 つのノード間のハンドシェイク中のエラー​

次のエラーメッセージに基づいてこの問題を特定できます。

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 GC アルゴリズムを使用することができます。

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 メタデータ用に専用のディスクを割り当てるか、高性能なディスクに交換することができます。

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:?]

この問題は、FE 設定ファイル fe.conf に metadata_failure_recovery = true を追加した場合に発生します。

この問題を解決するには、設定を削除してノードを再起動する必要があります。

StarRocks メタデータの破損​

次のいずれかのエラーメッセージに基づいて StarRocks メタデータの破損問題を特定できます。

failed to load journal type xxx

または

catch exception when replaying
警告

以下の解決策に従ってメタデータをリカバリする前に、StarRocks コミュニティの技術専門家に支援を求めることを強くお勧めします。この解決策は データ損失 を引き起こす可能性があります。

次の手順に従ってこの問題を修正できます。

  1. すべての FE ノードを停止します。

  2. すべての FE ノードのメタデータディレクトリ meta_dir をバックアップします。

  3. すべての FE ノードの設定ファイル fe.conf に設定 metadata_enable_recovery_mode = true を追加します。このモードではデータロードが禁止されています。

  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. 新しいイメージファイルがすべての FE ノードのディレクトリ meta/image に転送された後、すべての FE 設定ファイルから設定 metadata_enable_recovery_mode = true を削除し、FE ノードを再起動できます。

FE がサービスを提供できない​

Follower FE ノードが Leader 選出を実行できない場合、FE はサービスを提供しません。この問題が発生すると、次のログレコードが繰り返されることがあります。

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

  • BDBJE ログから Follower ノードの総数を確認できます。

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

    # この例の出力は、クラスターに 3 つの 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 アドレスをランダムに選択します。BDBJE メタデータに記録された IP アドレスがノードの起動に使用されたものと異なる場合、FE はサービスを提供しません。

  • BDBJE メタデータに記録された IP アドレスを 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 が BDBJE メタデータに記録された IP アドレスです。

  • FE ログからノードの起動に使用された IP アドレスを確認できます。

    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

この問題を解決するには、FE 設定ファイル fe.conf のノードの priority_networks を fe/meta/image/ROLE に記録された IP アドレスに設定し、ノードを再起動する必要があります。

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. 利用可能なディスク容量が不足している​

StarRocks を v3.0 以降にアップグレードするか、BDBJE を v18 以降にアップグレードした後、meta_dir を格納するディスクの空き容量が 5 GB 未満の場合、ノードが再起動に失敗することがあります。

BDBJE バージョンは .jar パッケージから fe/lib ディレクトリで確認できます。

この問題を解決するには、ディスクを拡張するか、FE メタデータ用により大容量の専用ディスクを割り当てることができます。

5. edit_log_port が変更された​

BDBJE メタデータに記録された edit_log_port が fe.conf に設定されたものと異なる場合、FE はサービスを提供しません。

BDBJE メタデータに記録された edit_log_port を 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

2 番目のアンダースコアの前の値 9312 が BDBJE メタデータに記録された edit_log_port です。

この問題を解決するには、FE 設定ファイル fe.conf のノードの edit_log_port を fe/meta/image/ROLE に記録された edit_log_port に設定し、ノードを再起動する必要があります。

6. JVM ヒープサイズが不足している​

jstat コマンドを使用して JVM メモリ使用量を確認できます。

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. 最後の手段​

警告

以下の解決策は、前述の解決策がすべて機能しない場合にのみ、最後の手段として試すことができます。

この解決策は、次のような極端なケースにのみ設計されています。

  • Follower ノードの過半数が再起動できない。
  • Follower ノードが BDBJE のバグにより Leader 選出を実行できない。
  • 前述のセクションで言及されていない例外。

次の手順に従ってメタデータをリカバリします。

  1. すべての FE ノードを停止します。

  2. すべての FE ノードのメタデータディレクトリ meta_dir をバックアップします。

  3. FE ノードをホストするすべてのサーバー で次のコマンドを実行し、最新のメタデータを持つノードを特定します。

    • StarRocks v2.5 以前の場合:

      java -jar fe/lib/je-7.3.7.jar DbPrintLog -h meta/bdb/ -vd

    • StarRocks v3.0 以降の場合:

      # コマンドでノードが使用する正確な .jar パッケージを指定する必要があります。
      # パッケージは StarRocks のバージョンによって異なります。
      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. 最新のメタデータを持つ FE ノードの役割 (Follower または Observer) を 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. クラスターに再追加する FE ノードのメタデータディレクトリ meta_dir をクリアします。

  2. 新しい Leader FE ノードをヘルパーとして使用して、新しい Follower ノードを起動します。

    # <leader_ip> を Leader FE ノードの IP アドレス (priority_networks) に置き換え、
    # <leader_edit_log_port> (デフォルト: 9010) を Leader FE ノードの edit_log_port に置き換えます。
    ./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_ip> を新しい FE ノードの IP アドレス (priority_networks) に置き換え、
    # <fe_edit_log_port> (デフォルト: 9010) を新しい FE ノードの edit_log_port に置き換えます。
    ./fe/bin/start_fe.sh --helper <fe_ip>:<fe_edit_log_port> --daemon

  4. 現在の FE ノードが Leader FE ノードであるかどうかを確認します。

    SHOW FRONTENDS;

    フィールド Role が LEADER の場合、この FE ノードは Leader FE ノードです。IP アドレスが現在の FE ノードのものであることを確認してください。

  5. データとメタデータが無事であり、ノードの役割が Leader である場合、設定 bdbje_reset_election_group を削除し、ノードを再起動する必要があります。

  6. メタデータバックアップを使用して新しい Leader FE ノードを正常に起動しました。新しい Leader FE ノードをヘルパーとして使用して、新しい Follower ノードを追加できます。

    # <leader_ip> を Leader FE ノードの IP アドレス (priority_networks) に置き換え、
    # <leader_edit_log_port> (デフォルト: 9010) を Leader FE ノードの edit_log_port に置き換えます。
    ./fe/bin/start_fe.sh --helper <leader_ip>:<leader_edit_log_port> --daemon

メタデータリカバリ関連の設定​

ヒント

メタデータのリカバリが完了したら、次の設定を削除する必要があります。