クラスタ管理 FAQ

選挙に関するFAQ

OceanBaseクラスタの選挙にはどのような種類があり、それぞれ誰が発起するのですか？

OceanBaseクラスタの実装には、主不在時の選挙、主の再任、主の改選（リーダー切り替え）の3つの部分が含まれます。そのうち、主不在時の選挙はクラスタ起動時やリーダーの再任失敗時にのみ実施されます。手動でのリーダー切り替えおよび主不在時の選挙を除き、その他の自動選挙はすべてPaxosグループのリーダーによって発起されます。Paxos集合を構成する3つのメンバーレプリカのうち、リーダー切り替え操作は各Paxosグループのリーダーが制御します。リーダーがリニューアル契約プロセスで、あるフォロワーの優先度が自身よりも高いことを検出した場合、そのフォロワーに「譲位」するためのリーダー切り替えプロセスを実行します。

どのようなレプリカが選挙に参加できますか？

V4.xバージョンでは、OceanBaseデータベースのレプリカタイプはフル機能レプリカ(FULL)、読み取り専用レプリカ(ReadOnly)、カラムストアレプリカ(COLUMNSTORE)の3種類があります。フル機能レプリカのみが選挙におけるリーダー候補者(Candidate)となり、データベースサービスを提供する主となることができます。

OceanBaseクラスタの選挙モジュールはインフラに対してどのような要件を持ちますか？

OceanBaseデータベース4.0.0バージョン以降、選挙ではクロック偏差に関する要件はありません。OceanBaseクラスタは強力なリーダー方式を採用しており、リース期間には制限があります。デフォルト設定ではリース期間は4秒です。環境内の任意の2つのレプリカ間のアプリケーション層における最大往復メッセージ遅延は1秒を超えてはなりません。しかし、実際の環境ではネットワークの階層化やオペレーティングシステム・上位アプリケーションの実装問題により、IP層でのメッセージ遅延がアプリケーション層で増幅されることがあります。この増幅倍率には参考となる指標がないため、環境のping遅延をできるだけ低く保つ必要があります。

OceanBaseクラスタの選挙モジュールは、RTOを8秒以内に保証する仕組みは何ですか？

デフォルト設定では、OceanBaseクラスタにおけるリーダー選挙のリース期間は4秒です。リーダーがダウンした場合、リース期間が満了するまで最大で4秒の遅延が生じる可能性があります。過半数のレプリカはリース期間満了を待った後、次の選挙を速やかに開始し、参照優先度が最も高いクラスタ内のレプリカが新しいリーダーとして選出されます。同時に、選挙モジュールはリーダーダウン後の主不在時の選挙に特別な最適化を施しており、選挙層のリーダーがダウンした後の平均主不在時間はリース期間とほぼ等しくなります。 選挙が成功してからクラスタサービスが回復するまでには、一連の追加のワークフローが必要です。例えば、新しいリーダーはPaxosのreconfirmフェーズでログを補完する必要があります（このフェーズの所要時間は、新しいリーダーが古いリーダーに対して遅延しているログの量に依存します。選挙は、ログが大幅に遅延しているレプリカを選出しないようにすることを保証します）。また、新しいリーダー上で未コミットの古いリーダーのトランザクション状態を復元する必要があります。さらに、Root Serviceにリーダーの位置情報を報告する必要があります。obproxyが設定されている場合は、Proxyが正しいリーダー位置情報を更新するのを待ってから、後続のSQL文を正しいリーダー位置にルーティングする必要があります。 OceanBaseクラスタの選挙モジュールは、元のリーダーレプリカが再任に成功した場合、元のリーダーが連続してリーダーレプリカサービスを提供できるようにします。元のリーダーレプリカがオフラインになり、リーダーの再任に失敗した場合、OceanBaseクラスタは主不在時の選挙を行い、新しいリーダーの就任は8秒以内に完了します。8秒のRTO時間のうち、選挙層では約4秒が消費され、残りの時間は他の段階の復旧に使用されます。他の段階の復旧プロセスは、ログの量の差や未コミットトランザクションの規模に正比例しますが、通常は各段階が100msを超えることはなく、全体のサービス復旧時間は8秒以内に保証されます。

过半数のレプリカがダウンした場合、OceanBaseクラスタの選挙モジュールは依然としてリーダーレプリカを選出し、高可用性を保証できますか？

OceanBaseクラスタ内の過半数のレプリカが同時にダウンした場合、OceanBaseクラスタはリーダーレプリカを選出して外部にデータサービスを提供することができません。

OceanBaseクラスタの選挙モジュールには、運用保守操作が必要ですか？

実際には、OceanBaseデータベースはユーザーが選挙モジュールを介入する方法やインターフェースを提供していません。例えば、過半数の選挙ルールを制御することなどです。 クラスタの正常な運用過程では、データベース管理者や管理者が人為的な操作や介入を行って、OBServerノードの選挙モジュールがその機能を果たすことを制御または影響する必要はありません。クラスタ管理操作を実行する際、例えばOBServerを停止したり、新しいOBServerをオンラインにしたり、テナントのプライマリゾーン設定を変更したりすると、選挙モジュールが選挙をトリガーし、テナント内のデータレプリカにリーダーレプリカが存在し、外部にデータサービスを提供することを保証する可能性があります。現時点では、管理者が直接選挙モジュールに対して運用保守介入を行う必要があるシステム運用状況はありません。

選挙ではどのレプリカがリーダーに選出されるのでしょうか？また、選出されたリーダーレプリカがより優れた選択肢であることをどのように保証するのでしょうか？

OceanBaseクラスタの選挙では、レプリカの優先順位を比較し、可能な限り健康状態が良好で優れたマシンをリーダーレプリカとして選出するようにします。現在、OceanBaseクラスタの優先順位は、レプリカがリーダーの合法的候補者であるかどうか、レプリカの健康スコア、レプリカメンバーリストのバージョン番号、およびレプリカのログ同期状況の4つの側面を主に考慮しています。これは、OceanBaseクラスタが自動的にトリガーする選挙を通じて、最終的にはより健康で、バージョンが最新の合法的な選出レプリカがリーダーに選ばれることを意味します。OceanBaseデータベースV4.0.0バージョンでは、無主選挙と有主改選の優先順位が統一され、メンバー変更バージョン番号が最高優先順位となります。同時に、これは選挙プロトコル内部に組み込まれた唯一の優先順位でもあります。バージョン番号が大きいレプリカは、自身よりバージョン番号が小さいレプリカに投票しません。

どのような場合に自動リーダー切り替えが発生しますか？

リーダーレプリカは、リースを継続する過程で定期的にフォロワーレプリカとやり取りを行います。このやり取りの過程で、フォロワーレプリカの方が高い優先順位を持っていることが検出された場合、リーダーはリーダー切り替えアクションをトリガーし、対応するフォロワーに「譲位」します。リーダー切り替えが発生する一般的な原因は以下のとおりです：

• primary_zone に変更が生じた場合。

• Stop Server/Stop Zoneの操作が実行された場合。

• OBServerが停止した場合（kill -15を受信した場合）。

• ログストリームの移行が発生した場合。

リーダー切り替えがトリガーされた原因を確認する方法は何ですか？

DBA_OB_SERVER_EVENT_HISTORYビューを使用して、特定のログストリームの選挙モジュールで発生したイベントを確認できます。

無主選挙を確認する方法は何ですか？

DBA_OB_SERVER_EVENT_HISTORYビューを確認することができます。このテーブルには、無主選挙、リーダー切り替え、メンバー変更など、すべてのログストリームのすべての選挙イベントが記録されています。

OceanBaseクラスタエラー -4038 の意味は何ですか？

4038 エラーコードの定義は not master です。4038 エラーが発生した後には、次の2つの可能性があります：

1. 現在のリーダーは存在しますが、リーダーが実行プロセスが配置されているサーバー上にいない場合（上位モジュールの問題を調査する必要があります）。

2. 現在のリーダーが存在しない場合。問題の調査経験に基づくと、基本的にはネットワーク接続状態に問題があることが原因です（ここではログストリームレベルの接続状態を指します）。例えば：

   • テナントがメモリ不足でメッセージを受信できないが、送信は可能なため、一方向のネットワーク接続が発生する。

   • ワークキューの積み上がりによりメッセージを受信できない。

   • サーバーがStop状態にあるためメッセージを受信できない。

   • その他の原因によるネットワーク接続問題。

CLOGモジュールはレプリカ選挙に影響しますか？どのように影響しますか？

OceanBaseデータベースV4.0.0バージョンでは、clogの異常状態が選挙優先順位の一部として扱われます。リーダーのclogに異常が発生すると、リーダー選挙の優先順位が低下し、フォロワーの優先順位がリーダーよりも高い場合、リーダーはリーダー切り替えをトリガーします。

主動的なリーダー辞任後、CLOGは再選挙を行いますか？

OceanBaseデータベースV4.0.0バージョンでは、clogによって開始される主動的な辞任アクションはなくなりました。もし clog のディスク書き込みがフングした場合、failure イベントが記録され、リーダーの優先順位が低下します。その後、最適なレプリカが自動的に選択され、直接リーダーが切り替えられます。リーダー切り替えイベントは DBA_OB_SERVER_EVENT_HISTORY ビューに記録されます。

CLOG FAQ

OceanBase CLOG同期圧縮機能における異なる圧縮アルゴリズムの違いと選択方法は何ですか？

OceanBaseデータベースは log_transport_compress_func を使用してトランザクションログ同期の圧縮アルゴリズムを制御し、デフォルトは lz4_1.0 です。ログ同期圧縮を有効にすると、clogはアルゴリズムに従ってログを圧縮して転送します。現在、clogがサポートする圧縮アルゴリズムは lz4_1.0、zstd_1.0、zstd_1.3.8 です。異なる圧縮アルゴリズムでは、clogを異なる比率で圧縮・転送することで、帯域幅への負荷を軽減します。ただし、clogの処理はすべて圧縮操作を経由する必要があるため、一定のパフォーマンスコストが伴います。 異なるシナリオでは、各圧縮アルゴリズムによる圧縮効果とパフォーマンスコストが異なります。デフォルト値である lz4_1.0 圧縮アルゴリズムは、許容範囲内のパフォーマンスコストで比較的大きな圧縮率を実現できるため、OceanBaseデータベースの構成パラメータ log_transport_compress_func のデフォルト値は lz4_1.0 に設定されています。異なるシナリオでより高い圧縮率を求める場合や、より高いパフォーマンスコストを許容できる場合は、異なる圧縮アルゴリズムを選択できます。

トランザクションの実行からコミットまでのプロセスにおいて、データ変更はどのようにしてMemStore、永続層にコミットされ、clogに保存されるのですか？

データベーストランザクションにDMLリクエストが含まれる場合、データ変更はリーダーフォロワー構成のMemTableに反映されます。トランザクションのコミットが成功すると、OceanBaseデータベースのトランザクション処理は、データ変更が多数派のclogにフラッシュされ、フォロワーフォロワー構成のMemStoreに再配置されることを保証します。OceanBase MemStoreの使用量が一定のしきい値を超えると、メモリダンプが実行され、MemStoreのデータがSSTableに永続化されます。 以下に、ストレージ層（MemTable、SSTable）およびclog層で発生する主要な処理の流れを簡潔に説明します：

1. アプリケーションがトランザクションTnx1を開始します。

2. Tnx1トランザクション内で、DMLリクエストDML1とDML2が順次実行されるものと仮定します。

3. DML1とDML2はSQL層を実行し、トランザクションのコンテキストを更新し、データ変更をMemTableに反映します。

4. DML1とDML2がSQL層で正常に実行された後、アプリケーションがCOMMITを発行し、Tnx1はトランザクションのコミット段階に入ります。

5. リーダーフォロワー構成のリーダーフォロワーがclogのフラッシュを開始し、同時にclogをフォロワーフォロワー構成のフォロワーフォロワーに同期します。

6. リーダーフォロワー構成において、clogが多数派でフラッシュされると、トランザクションのコミットが成功し、アプリケーションに応答が返されます。

7. フォロワーフォロワー構成のフォロワーフォロワーは、clogを受信しフラッシュされた後、「clogが多数派でフラッシュされた」という確認メッセージをリーダーフォロワー構成のリーダーフォロワーから受信するまで待機し、その後非同期での再生を開始します。これにより、clogの内容がMemStoreに再配置され、弱い一貫性の読み取りに対するデータサービスが提供されます。

OBServerノードのスライディングウィンドウがフルになったり、停止したりした場合、どのようなエラーが発生し、どのような影響がありますか？どのようにチューニングすべきですか？

clogスライディングウィンドウ（Sliding Window）が満杯になる主なケースは以下の2つです：

全体として、clogスライディングウィンドウが満杯になると、clogの永続化の進行に影響します。この場合、アプリケーション側ではslow transや「ロック待機」（ログに-6005やlock_for_write conflict.*\-4023が表示される）などの問題が発生し、パフォーマンスも明らかに低下します。分析のアプローチは以下の通りです：

• clogのコミット書き込みが急激に増加していないか分析します。例えば、システムに新たに高並行性のバッチ処理シナリオが導入され、clogスライディングウィンドウへの同時実行負荷が非常に高い場合、まず業務ロジックから高並行性のバッチ処理が業務上必要かどうかを確認する必要があります。業務上許容される場合、並行数を削減してテスト問題を緩和することを試みることができます。これは通常、比較的安全で最も迅速に最適化効果を得られる方法です。

• 業務の並行数が急激に増加していないにもかかわらず、この問題が発生した場合、clogスライディングウィンドウのスライドアウトにボトルネックがないか診断する必要があります。例えば、Followerがメモリ不足でダンプが遅く、ログ再生がメモリに収まらない場合、clogスライディングウィンドウが満杯になる可能性があります。このようなシナリオに遭遇した場合は、OceanBaseデータベースの技術サポートに連絡して分析を依頼する必要があります。

• ホットパーティションの分割

すべてのスライディングウィンドウのサイズはパーティション単位で設定されているため、データのホットスポットが集中しているほど、スライディングウィンドウが満杯になりやすくなります。そのため、データのホットスポットを複数のテーブルやパーティションに分散させることで、スライディングウィンドウが満杯になる確率を効果的に低減できます。私たちがよく注目するメインテーブルのホットパーティションに加えて、「グローバル」インデックスのホット状況にも特に注意する必要があります。これには以下が含まれます：

• グローバルな「非パーティション」インデックスで、インデックスデータが1つのパーティションに集中している場合。

• パーティションキーが不適切なグローバルパーティションインデックスで、例えばインデックスキーのNDVが小さすぎる、またはデータの偏りが深刻である（特定のキー値のレコード数が多すぎる）場合も、インデックスデータが少数のパーティション、あるいは1つのパーティションに集中する原因となります。

CLOG reconfirmが失敗するシナリオとその影響、およびCLOG reconfirm失敗のシナリオを分析する方法

OceanBaseデータベースは分散型データベースであり、パーティションが正常に読み書きサービスを提供するためには、必ずリーダーを選出する必要があります。リーダー選出プロセスの概要は以下の通りです：

1. OceanBaseデータベースの選挙モジュールがレプリカのリーダーを選出します。

2. clogモジュールが選挙モジュールから現在のリーダーを取得し、リーダーは就任前にclog reconfirmプロセスを実行して、データが最新であることを確認します。

3. リーダーがTakeoverなどの操作を実行した後、正式に就任します。

新しいリーダーがOceanBaseデータベースの選挙モジュールによって選出されたものの、何らかの理由でclog reconfirmが失敗した場合、最終的に対応するデータパーティションもデータサービスを提供できません。

clog reconfirmプロセスの主な目的は、スライディングウィンドウ内に残された未確認のログを再確認し、フォロワーレプリカに同期することです。OceanBaseデータベースでは、トランザクションコミットの過程で、もしそのclogが既に多数派に正常に同期されていれば、トランザクションは既にコミット成功となります。この時点でリーダーがダウンした場合、まだオンラインのレプリカの中には、clogの確認が完了せずMemTableに戻されていないものが存在する可能性があります。clog reconfirmは、リーダー切り替えのシナリオにおいて、すべてのレプリカのclogが確認完了していることを保証し、多数派のclogの同期状態が一致していることを保証することで、今後のトランザクションコミットへの影響を防ぎます。clog reconfirmプロセスには以下の段階が含まれます：

上記6段階のうち、重要な段階ではログがobserver.logに出力されます。例えば： 段階2で多数派からの応答を受信したことを示すログは次のとおりです（このログが見えない場合は、その段階で停止していることを意味します）：

[20XX-XX-XX 20:28:06.142985] INFO  [CLOG] ob_log_reconfirm.cpp:598 [127240][Y0-0000000000000000] [lt=25] max_log_ack_list majority(partition_key={tid:1099511627777, partition_id:0, part_cnt:1}, majority_cnt=2, max_log_ack_list=1{server:“10.101.XXX.XXX:261XXX”, timestamp:-1, flag:0})

単一のclog reconfirmプロセスのタイムアウト時間は10秒です。つまり、10秒以内に処理が完了しない場合、ERRORレベルのタイムアウトログが出力され、キーワードはis_reconfirm_role_change_or_sync_timeoutとなります。clog reconfirmは通常、上記の各段階で停止することでタイムアウトします。停止の主な原因は、コミット再生ができない、ネットワークが接続されていない、ログディスクが満杯などです。 clog reconfirmが停止する主な原因と重要なログ情報は以下のとおりです。

上記の診断方法でclog reconfirm失敗の原因が特定できない場合は、OceanBaseデータベースのテクニカルサポートにお問い合わせください。

CLOG ディスク満杯時の問題分析と緊急対応はどうすればよいですか？

パーティション数が多く、書き込み負荷が高いクラスタでは、ダンプが遅延する（停止する）場合や、テナントのUnit構成が異種である場合、一部のレプリカのclog回収が間に合わず、ディスク容量が95%に達することがあります。この状態では、OBServerノードは自動的に書き込みを停止し、そのマシン上の多くのレプリカが同期しなくなります。 通常、clogディスク容量は約80%を維持します。80%を超えた場合は、ログファイルの回収が遅延しているか、または停止していることを意味します。clogファイルが回収される条件は、そのファイル内のすべてのパーティションログに対応するデータがすでにSSTableにダンプされていることです。したがって、通常clogディスクが満杯になる原因は、一部のパーティションのダンプが停止していることです。 clogディスク容量がアラートを開始した後、以下の手順で回収がブロックされているパーティションを確認します：

1. 以下のコマンドの結果を確認します：

   grep  can_skip_base  observer.log
   

   • 検索結果から need_record が True のレコードを探します。その中に partition_key が含まれている場合、そのパーティションのログは回収できません。

   • アラートログの直近の時間点から検索を開始し、検索結果に含まれるパーティションが現在ブロックされている回収のパーティションです。その中から partition_key を取得します。

2. 上記の partition_key を使用して、そのパーティションのログを検索します：

   grep  partition_key  observer.log
   

   ログ分析を通じて、ダンプの進捗ポイントが前進しない原因を特定します。

緊急対応策

clogディスクが満杯となり、多数派ノードに影響が及び、トランザクションのコミットに影響を与え、システム全体がハングや応答なしの状態になった場合、かつ業務側から大量の同時DMLトランザクションが流入している場合は、まず業務負荷を一時停止し、clogサービスを復旧することを推奨します。

もしclogディスク満杯の影響が少数派のみに留まっている場合は、まずノードにIO層やネットワーク層（インフラ層）の重大なボトルネックがないか迅速に分析します。

もしそのようなボトルネックがある場合は、少数派ノードを隔離した上で、IOボトルネックとネットワークボトルネックを解消します。

もしIO層やネットワーク層（インフラ層）のボトルネックがなくても、少数派ノードで問題が発生している可能性があります。その場合は、技術サポートスタッフに連絡し、調査・診断を依頼してください。

考えられる原因

• 運用保守上の問題。

  clogディスクが配置されている領域が他ユーザーのファイルに占用されており、利用可能な空き容量が不足している。

• ダンプの継続的な失敗がclogディスク満杯の最も一般的な原因です。

  clogに関連するパーティションデータがすべてSSTableにダンプされ、かつパーティションのメタ情報が永続化され、ダウンから再起動までの再生開始ポイントが設定されている場合、clogファイルは回収できます。したがって、ダンプが失敗し、ダウンから再起動にかけてのclog再生開始ポイントが前進しない場合、CLOGファイルは回収できません。ダンプの継続的な失敗の原因シナリオと具体的なロジックは比較的複雑です。このような状況に遭遇した場合は、OceanBaseデータベースの技術サポートに連絡し、介入診断を依頼してください。

OBServerノードの再起動時にCLOGの初期化に失敗した場合、どのようなエラーが表示されますか？また、OBServerノードの起動時に初期化に失敗してエラーが発生した場合、システムを復旧するためにどのような操作を実行すればよいですか？

ストレージFAQ

OceanBaseデータベースのストレージエンジンは従来のデータベースとどのように異なりますか？

OceanBaseデータベースは読み書き分離アーキテクチャを採用しており、データをベースラインデータと増分データに分けています。増分データはメモリ内（MemTable）に、ベースラインデータはSSDディスク（SSTable）に格納されます。データの変更はすべて増分データに対して行われ、メモリにのみ書き込まれます。そのため、DML操作は完全にメモリ上で行われ、パフォーマンスが非常に高くなります。読み取り時には、メモリ内に更新済みのデータが存在し、永続化ストレージにはベースラインバージョンが存在する場合があります。最新バージョンを取得するためには、この2つのバージョンをマージする必要があります。同時に、メモリ内ではBlock CacheとRow Cacheが実装されており、ベースラインデータへのランダムな読み取りを回避します。メモリ内の増分データが一定の規模に達すると、増分データとベースラインデータのマージがトリガーされ、増分データがディスクにフラッシュされます。また、毎晩のアイドルタイムには、システムが自動的に日次マージを実行します。

データはOceanBaseデータベース内でどのように格納されますか？

OceanBaseデータベースのデータファイルは、マクロブロック（Macro Block）単位でデータを組織しており、各マクロブロックのサイズは2MBです。マクロブロック内部はさらに多数の16KB（圧縮前サイズ）のマイクロブロック（Micro Block）に分割されており、各マイクロブロックには複数の行（Row）が含まれます。OceanBaseデータベース内部のI/Oの最小単位はマイクロブロックです。

パーティションテーブルを使用すべきですか？

パーティションテーブルの使用については、以下の情報を参考に判断できます：

• あるテーブルのデータ量が予測可能な将来に200GBを超える見込みがある場合、パーティションテーブルの使用を推奨します。

• テーブルに明確な時間的周期性がある場合、パーティションテーブルの使用を推奨します。

OceanBaseデータベースにおいて、ローカルインデックスとグローバルインデックスの実装上の違いは何ですか？

ローカルインデックスとグローバルインデックスの違いは以下の通りです：

• ローカルインデックス：単一テーブルまたはパーティションテーブルの最小サブパーティションに結び付けられ、OceanBaseデータベースのシステムテナント内に追加のパーティションレコードを作成しません。そのため、ローカルインデックスに基づくSQLは基本的にローカルで実行されます。

• グローバルインデックス：OceanBaseデータベースのシステムテナント内に追加のパーティションレコードを作成する必要があり、別のテーブルと理解できます。これにより、追加のパーティションクォータが消費されます。グローバルインデックスは独自のパーティション戦略を持つことができ、ローカリティも主表とは結び付けられません。単一テーブルであっても、グローバルインデックスは主表とは別のノードに保存される可能性があります。もちろん、この場合はSQLが分散SQLになりやすくなります。