選出に関するFAQ
OceanBaseクラスタの選挙にはどのようなものがあり、それぞれ誰が開始するのですか？
OceanBaseクラスタの実装には、主なものとして無主選挙、有主連任、有主改選（リーダー切り替え）が含まれます。その中で無主選挙は、クラスタ起動時またはリーダー連任失敗時にのみ行われます。手動リーダー切り替えおよび無主選挙を除き、他の自動選挙はすべてPaxosグループのリーダーによって開始されます。Paxos集合を構成する3つのメンバーレプリカの中で、リーダー切り替え操作は各Paxosグループのリーダーが制御し、リーダーが更新プロセス中にあるフォロワーの優先順位が自身よりも高いことを検出した場合、そのフォロワーに「譲位」するためのリーダー切り替えプロセスを実行します。
どのようなレプリカが選挙に参加できるのですか？
V4.x系では、OceanBaseデータベースのレプリカタイプにはフル機能レプリカ(FULL)、読み取り専用レプリカ(ReadOnly)、カラムストアレプリカ(COLUMNSTORE)があります。フル機能レプリカのみが選挙におけるリーダー候補(Candidate)となり、データベースサービスを提供することができます。
OceanBaseクラスタの選挙モジュールはインフラに対してどのような要件がありますか？
OceanBaseデータベース4.0.0以降では、選挙において時計のずれに関する要件はありません。OceanBaseクラスタは強力なリーダー方式を採用しており、リース期間に制限があります。デフォルト設定ではリース期間は4秒です。環境内の任意の2つのレプリカ間のアプリケーション層における最大一方向メッセージ遅延は1秒を超えてはなりません。しかし、実際の環境ではネットワークの階層化やOSおよび上位アプリケーションの実装により、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を導入したり、テナントのPrimary Zone設定を変更したりすると、選挙モジュールが選挙を開始し、テナント内のデータレプリカにリーダーとなるレプリカが存在し、外部にデータサービスを提供できるようにするためです。現時点では、管理者が直接選挙モジュールに対して運用保守を行う必要があるシステム運用状況はありません。
選挙においてどのレプリカがマスターとして選ばれるのか、また選出されたリーダー・レプリカがより良い選択であることをどのように保証するのか？
OceanBaseクラスタの選挙では、レプリカの優先順位を比較し、可能な限り健康状態の良好なマシンをリーダー・レプリカとして選出します。現在、OceanBaseクラスタの優先順位は主に、レプリカがリーダーの合法的候補者であるかどうか、レプリカのヘルススコア、レプリカメンバーリストのバージョン番号、およびレプリカログの同期状況の4つの側面を考慮しています。これはまた、OceanBaseクラスタが自動的にトリガーする選挙を通じて、最終的により健康で、バージョンが最新の合法的な選挙レプリカがマスターとして選ばれることを意味します。OceanBaseデータベースバージョン4.0.0では、マスターなし選挙とマスター変更選挙の優先順位が統一され、メンバー変更バージョン番号が最も高い優先順位となり、同時に選挙プロトコル内部に組み込まれた唯一の優先順位でもあります。バージョン番号が大きいレプリカは、自身よりバージョン番号が小さいレプリカに投票しません。
どのような場合に自動マスター切り替えが発生するのか？
リーダー・レプリカは、リースを継続する過程で定期的にフォロワー・レプリカとやり取りを行います。その際、フォロワー・レプリカの方が高い優先順位を持っていることが判明した場合、リーダーはマスター切り替えアクションをトリガーし、対応するフォロワーに「譲位」します。一般的なマスター切り替えの原因には以下のものがあります：
primary_zoneに変更が生じた場合。Stop Server/Stop Zoneの操作が発生した場合。
OBServer Stopped（kill -15）の操作が発生した場合。
日志ストリームの移行が発生した場合。
マスター切り替えの原因をどのように確認するのか？
DBA_OB_SERVER_EVENT_HISTORYビューを使用して、特定のログストリーム選挙モジュールで発生したイベントを確認できます。
マスターなし選挙はどのように確認するのか？
DBA_OB_SERVER_EVENT_HISTORYビューを使用して確認できます。このテーブルには、マスターなし選挙、マスター切り替え、メンバー変更など、すべてのログストリームのすべての選挙イベントが記録されています。
OceanBaseクラスタエラー -4038 とはどのような意味でしょうか？
4038エラーコードの定義はnot masterです。4038エラーが発生した後には、次の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 層で発生する主要な動作を簡単に説明します：
アプリケーションがトランザクション Tnx1 を開始します。
Tnx1 トランザクション内で、DML リクエスト DML1 と DML2 が順次実行されると仮定します。
DML1 と DML2 は、SQL 層を実行してトランザクションのコンテキストを更新し、データ変更を MemTable に更新します。
DML1 と DML2 が SQL 層での実行に成功し、アプリケーションが COMMIT を開始すると、Tnx1 はトランザクションコミット段階に入ります。
リーダー複製が clog の永続化を開始し、同時に clog をフォロワー複製に同期します。
リーダーとフォロワーが clog の多数派を形成して永続化されると、トランザクションのコミットが成功し、アプリケーション側に返されます。
フォロワー複製は、clog を受信して永続化された後、リーダー複製から「clog の多数派永続化完了」という確認メッセージを受信するまで待機し、その後非同期再生を開始して clog の内容を MemStore にフラッシュバックします。これにより、弱い一貫性読み取りに対するデータサービスが提供されます。
OBServerノードのスライディングウィンドウがフリーズしたり、上限になったりした場合、どのようなエラーが発生し、どのような結果になるのでしょうか。また、どのようにチューニングすればよいでしょうか？
clogスライディングウィンドウ（Sliding Window）の上限は主に以下の2つのケースに分けられます：
| clogスライディングウィンドウ上限シナリオ | 結果および重要なログ |
|---|---|
| リーダーパーティションのclogスライディングウィンドウ上限 | リーダーパーティションはトランザクション層にlog_idを割り当てることができなくなり、observer.logにsubmit log error.*\\-4023メッセージが出力されます。リーダーのclogスライディングウィンドウが上限状態になり、自動的に緩和されない場合、トランザクションコミット時にリクエストをclogスライディングウィンドウに格納できなくなり、トランザクションの応答時間（RT）全体が上昇する問題が発生します。 |
| フォロワーパーティションのclogスライディングウィンドウ上限 | フォロワーパーティションはリーダーから送信されるclogの受信を一時停止し、clogがウィンドウから滑り落ちるまでobserver.logにcheck_can_receive_log, now can not recieve logメッセージが出力されます。長時間にわたってフォロワーノードのスライディングウィンドウが上限状態になり、自動的に緩和されない場合、多数派のclogコミットに影響を与え、さらにトランザクションコミットにも影響を及ぼします。少数派のclogコミットに影響を与えると、フォロワーノードのclogが常に遅れることになります。フォロワーのclogが継続的に遅れると、他の少数派レプリカに障害が発生した場合、そのレプリカが限定的に選出されてリーダーレプリカになることができなくなります。 |
全体として、clogスライディングウィンドウが上限になると、clogの永続化の進行に影響を与えます。この場合、アプリケーション側ではslow transや「ロック待機」（ログに-6005やlock_for_write conflict.*\-4023というメッセージが表示される）などの問題が発生し、パフォーマンスにも明らかな影響が出ます。分析のアプローチとしては、以下のような方法があります：
clogのコミット書き込みが大幅に増加しているかどうかを分析します。例えば、システムに新たに高同時実行のバッチ処理シナリオが導入された場合、clogスライディングウィンドウへの同時実行の負荷が非常に高くなります。そのため、まず業務ロジックから高同時実行のバッチ処理が本当に必要かどうかを確認する必要があります。業務上許容される場合は、並列処理を低減してテストし、問題を緩和することができます。これは通常、比較的安全で最も迅速に最適化効果を得られる方法です。
ビジネスの同時実行が急激に増加していないにもかかわらず、この問題が発生した場合は、clogスライディングウィンドウのスライドアウトにボトルネックがないかどうかを診断する必要があります。例えば、フォロワーがダンプ速度が遅く、メモリ不足でログ再生がメモリに入らない場合、clogスライディングウィンドウが上限になる可能性があります。このような状況が発生した場合は、OceanBaseデータベースのテクニカルサポートに連絡して分析を依頼する必要があります。
ホットパーティションの分割
すべてのスライディングウィンドウのサイズはパーティション単位で設定されているため、データのホットスポットが集中しているほど、スライディングウィンドウが上限になりやすくなります。そのため、データのホットスポットを複数のテーブルやパーティションに分散させることで、スライディングウィンドウが上限になる確率を効果的に低減できます。一般的に注目されるメインテーブルのホットパーティションに加えて、「グローバル」インデックスのホットスポットにも特に注意が必要です。これには以下が含まれます：
グローバル「非パーティション」インデックスで、インデックスデータが1つのパーティションに集中している場合。
パーティションキーが不適切なグローバルパーティションインデックスで、例えばインデックスキー上のNDVが小さすぎる、あるいは深刻なデータの偏り（特定のキー値のレコード数が多すぎる）がある場合も、インデックスデータが少数のパーティション、あるいは1つのパーティションに集中してしまいます。
CLOG再確認が失敗するシナリオとその影響、およびCLOG再確認失敗のシナリオをどのように分析するか
OceanBaseデータベースは分散型データベースであり、パーティションが正常に読み書きサービスを提供するためには、必ずリーダーを選出する必要があります。リーダー選出プロセスの概要は以下の通りです：
OceanBaseデータベースの選出モジュールがレプリカのリーダーを選出します。
clogモジュールは選出モジュールから現在のリーダーを知らされ、リーダーは就任前にclog再確認プロセスを実行し、データが最新であることを確認します。
リーダーがTakeoverなどの操作を実行した後、正式に就任します。
新しいリーダーがOceanBaseデータベースの選出モジュールによってすでに選出されている場合でも、何らかの理由によりclog再確認が失敗した場合、最終的に対応するデータパーティションもデータサービスを提供できなくなります。
clog再確認プロセスの主な目的は、スライディングウィンドウ内に残された未確認ログを再確認し、フォロワーレプリカに同期させることです。OceanBaseデータベースでは、トランザクションコミット時にclogが過半数のレプリカに正常に同期されれば、トランザクションはコミット成功となります。この時点でリーダーがダウンした場合、まだ稼働しているレプリカ内には、MemTableへの確認が完了していないclogが存在する可能性があります。clog再確認は、リーダー切り替えのシナリオにおいて、すべてのレプリカのclogが確認済みであり、過半数のclogが同期されている状態を保証し、今後のトランザクションコミットに影響を与えないようにします。clog再確認プロセスには以下のいくつかの段階が含まれます：
| ステージ | ステージ名 | ステージのアクション |
|---|---|---|
| 1 | INITEDステージ | 確認済みのログをコミットしてリプレイし、ローカルにprepareログと今回のリーダー選出のマーカー情報を書き込む。 |
| 2 | FLUSHING_PREPARE_LOGステージ | リーダー選出のマーカー情報をすべてのフォロワーに送信し、フォロワーからそれぞれのログの返答を待つ。過半数の返答を受け取った後、次のステージに進む。 |
| 3 | FETCH_MAX_LSNステージ | レプリカの最大コミットログmax_flushed_log_idが過半数（自身を含む）に達するまで待機し、受信した最大max_flushed_id値を集計し、いくつかの準備作業を行う。 |
| 4 | RECONFIRMINGステージ | 最初に、スライディングウィンドウの左側にある確認済みのログをスライディングウィンドウから滑り出させてコミットし、最初の未確認ログに遭遇するまでリプレイを続ける。その後、すべての未確認ログに対して再確認プロセスを実行する。具体的には、過半数のメンバーからそのログの内容を収集・確定し、すべてのフォロワーに同期する。最後にSTART_WORKING状態に移行し、start_workingログを書き込む。 |
| 5 | START_WORKINGステージ | start_workingログが過半数に達するまで待機する。 |
| 6 | FINISHEDステージ | 終了。 |
上記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再確認プロセスのタイムアウト時間は10秒です。つまり、10秒以内に完了しない場合、ERRORレベルのタイムアウトログが出力され、キーワードはis_reconfirm_role_change_or_sync_timeoutとなります。clog再確認は通常、上記の各段階でフリーズし、タイムアウトすることが多いです。フリーズの主な原因としては、リプレイのコミットができない、ネットワーク不通、ログディスク上限などが挙げられます。 clog再確認がフリーズする主な原因と重要なログ情報は以下の通りです
| 主な原因 | 原因の説明 | キーログおよび診断方法 |
|---|---|---|
| clog再生が詰まる | reconfirmプロセスでは、スライディングウィンドウの左側にある確認済みのログをすべてコミットして再生する必要があります。再生がメモリ割り当て失敗や再生エラーなどのさまざまな異常によって詰まると、スライディングウィンドウにログが滞留し始めます。滞留したログ数がしきい値（現在は2万件）に達すると、スライディングウィンドウが上限となり、新しいログを受信できなくなり、reconfirmも正常に実行できなくなります。 | スライディングウィンドウ内にコミットして再生する必要がある確認済みのログがある場合、observer.logのCLOGモジュールから[ERROR]レベルのエラーコード-4023が報告されます。ログのキーワードは以下のとおりです：there are confirmed logs in sw, try again(partition_key={tid:1106108697592670, partition_id:0, part_cnt:1}, ret=-4023, new_start_id=371801833, start_id=371802703)再生が詰まる原因は多岐にわたり、例えばalloc memory failedのようなメモリ割り当てエラーやreplay errorのような再生エラーなどが考えられます。さらにobserver.logを用いて調査する必要があります。 grep ERROR observer.log | grep STORAGE | grep 'alloc memory' 、 grep ERROR observer.log | grep STORAGE | grep replay |
| clogディスク上限 | clog reconfirmプロセスでは、prepareやstart_workingなどのログを書き込む必要があり、また過半数の確認を得る必要があります。もしServerのclogディスクが上限でこれらのログを書き込めない場合、残りの正常なServerが過半数に達しないため、reconfirmも失敗します。 | clogがディスク上限になると、observer.logのCLOGモジュールから[ERROR]レベルのエラーコード-4264が報告されます。ログのキーワードは以下のとおりです：log outof disk space(partition_key={tid:1102810162709414, partition_id:46, part_cnt:0}, server=“xx.xx.xx.xx:29432”, ret=-4264, free_quota=-3381817344) |
| clog同期ネットワーク不通 | clog reconfirmプロセスでは、候補リーダーが複数の段階で各フォロワーと通信する必要があるため、ネットワークに問題が発生し、パケットの送受信ができない、または送受信の遅延が大きすぎる場合、reconfirmも失敗する可能性があります。 | ネットワーク不通により、reconfirmの複数の段階で失敗することがあります。例えば、PREPAREログを送信した後、フォロワーからの返信が届かない場合、タイムアウトによる失敗が発生するまで、次のキーワードのログが継続的に出力されます：max_log_ack_list not majorityその後のstart_workingログの書き込みも、ネットワーク異常により過半数のackを受信できず、タイムアウトによる失敗につながる可能性があります。 ネットワーク不通の原因は多岐にわたります。調査手順は以下のとおりです：
|
| 500テナントリクエストキューの滞留 | 500リクエストキューに滞留が発生し、新しいRPCリクエストを処理できない場合、reconfirm関連のメッセージ処理も停止し、リーダー側のログに表示され、フォロワーは一切のリクエストに対して返信しません。この時点で、キューの滞留状況とその原因をさらに分析する必要があります。 | キューの滞留状況を確認する：リーダー/フォロワーのobserver.logを検索し、キーワードはdump tenant info(tenant={id:500, となります。検索キーワードを使用することで、500テナントのキュー状況を確認できます。その中でreq_queueフィールドの後に続く内容がキューの状況となります。通常、500テナントのキューにリクエストキューの滞留が発生した場合、さらにキュー滞留の原因を分析する必要があります。この時、obstackを使用して現在のOBServerノードのスタック情報を出力し、その情報を同時にOceanBaseデータベース技術サポートに送付して問題の診断を行うことができます。 |
| ワーカースレッド不足 | - | 以下のeasyパッケージ処理タイムアウトのログが存在するかどうかを確認します：[20XX-XX-XX 11:12:12.103] easy_request.c:420(tid:7fe2cdc9f700)[57136] rpc time, packet_id :2425446521, pcode :4096, client_start_time :1517541127590356, start_send_diff :8, send_connect_diff: 0, connect_write_diff: 5, request_fly_ts: 188, arrival_push_diff: 2, wait_queue_diff: 4508603, pop_process_start_diff :2, process_handler_diff: 4184, process_end_response_diff: 1, response_fly_ts: 447, read_end_diff: 1, client_end_time :1517541132103797, dst: 10.101.X.X:XXXXXwait_queue_diffが数秒に達していることから、ワーカースレッドの処理が遅いことがわかります。cpu_quota（cpu_quota_concurrency、workers_per_cpu_quota）関連の構成パラメータが過小に設定されていないか確認してください。 |
上記の診断方法でclog再確認失敗の原因が特定できない場合は、OceanBaseデータベースのテクニカルサポートに連絡して診断を依頼してください。
CLOGディスクが上限になった場合、どのように問題分析と緊急対応を行うべきでしょうか？
パーティション数が多く、書き込み負荷が高いクラスタでは、ダンプ処理が遅延したり（フリーズしたり）、またはテナントユニットの仕様が異種である場合、一部のレプリカのclogファイルの回収が適時に行われず、ディスク容量が95％に達する可能性があります。この状況では、OBServerノードは自動的に書き込みを停止し、その結果、このマシン上の多くのレプリカが同期されなくなります。 通常、clogディスク容量は約80％を維持します。80％を超えた場合、ログファイルの回収が遅延しているか、またはフリーズしていることを意味します。clogファイルの回収条件は、そのファイル内のすべてのパーティションログに対応するデータがすでにSSTableにダンプされていることです。したがって、通常clogディスクが上限になる原因は、一部のパーティションのダンプ処理がフリーズしていることです。 clogディスク容量がアラートを開始した後、以下の手順に従って、回収がブロックされているパーティションを確認します：
以下のコマンドの結果を確認します：
grep can_skip_base observer.log検索結果から
need_recordがTrueのレコードを見つけます。その中にpartition_keyが含まれている場合、このパーティションのログは回収できないことを示します。アラートログの直近の時間点から検索を開始し、検索結果に含まれるパーティションが現在ブロックされている回収対象のパーティションであり、その中から
partition_keyを取得します。
上記の
partition_keyを使用して、そのパーティションのログを検索します：grep partition_key observer.logログ分析を通じて、ダンプポイントが進まない理由を特定します。
緊急対応策
clogディスクが上限になり、多数派ノードに影響が及び、トランザクションのコミットに影響が出ると、システム全体でHangや応答不能な状態が発生し、業務側には大量の同時実行DMLトランザクションが流入します。この場合、業務負荷を一時的に停止し、clogサービスを復旧することを推奨します。
もしclogディスクが上限になる操作が少数派にのみ影響を与えた場合、まずノードにIO層やネットワーク層（インフラ層）の重大なボトルネックがないか迅速に分析してください。
もし存在する場合は、少数派ノードを隔離してから、IOボトルネックとネットワークボトルネックを解決してください。
もしIO層やネットワーク層（インフラ層）のボトルネックがない場合でも、依然として少数派ノードで問題が発生する可能性があるため、技術サポート担当者に連絡し、調査を依頼してください。
考えられる原因
運用保守上の問題。
clogディスクが配置されている領域が他のユーザーのファイルに占有されており、利用可能な空き容量が不足しています。
ダンプ処理の継続的な失敗は、clogディスクが上限になる最も一般的な原因です。
clogに含まれるパーティションデータがすべてSSTableにダンプされ、かつパーティションのメタ情報が永続化され、ダウンタイム再起動時の開始ポイントに達した場合、clogファイルを回収できます。したがって、ダンプ処理が失敗し、ダウンタイム再起動時のclogの開始再生ポイントが進まない場合、CLOGファイルは回収できません。ダンプ処理の継続的な失敗の原因シナリオと具体的な原因のロジックは比較的複雑であるため、このような状況に遭遇した場合は、OceanBaseデータベースの技術サポートに連絡し、診断を依頼してください。
OBServerノードの再起動時にCLOGの初期化に失敗した場合、どのようなエラーが表示されますか？また、OBServerノードの起動時に初期化に失敗した場合、システムを復旧するためにはどのような操作を行えばよいでしょうか？
| エラーの説明 | エラーログ | 復旧方法 |
|---|---|---|
| clog_shm（共有メモリファイル内の記録flush_pos_がclogの最後のファイルの有効位置を超える） | observer.log CLOGモジュールは[ERROR]レベルの-4016エラーコードを報告し、エラーキーワードはThe clog start pos is unexpected, (ret=-4016, file_id=1018, offset=51658630 |
storeディレクトリ内のclog_shmファイルを削除してから再起動します。 |
| clogファイルのイテレーションにエラーが発生しました。これは通常、clogファイル自体に問題があるためです | observer.log CLOGモジュールは[ERROR]レベルの-4016エラーコードを報告し、ログエラーキーワードには以下のものが含まれます：
|
このようなエラーは通常、clogファイルまたはclogファイルのイテレーションに問題があるために発生します：
例えば、3レプリカ環境で、そのうちの1つのレプリカにエラーが発生した場合。 復旧方法1： 類似のマシンを見つけて迅速にOceanBaseクラスタに追加すると、OceanBaseクラスタは自動的に3番目のレプリカを補完します。構成パラメータ enable_rereplicationが有効になっていることを確認する必要があります。問題のあるマシンは最終的に永続的にオフラインになります。復旧方法2： 問題のあるマシンを永続的にオフラインにする手順に従って、障害マシン上のデータを安全にクリーンアップし、新しいマシンとして再びクラスタに追加します。
|
ストレージに関するFAQ
OceanBaseデータベースのストレージエンジンと従来のデータベースとの違いは何ですか？
OceanBaseデータベースは、読み書きを分離したアーキテクチャを採用しており、データをベースラインデータと増分データに分けています。増分データはメモリ（MemTable）に、ベースラインデータはSSD（SSTable）に格納されます。データの変更はすべて増分データであり、メモリへのみ書き込まれます。そのため、DML操作は完全にメモリ上で行われ、パフォーマンスが非常に高くなります。読み取り時には、メモリ内に更新されたバージョンと永続化ストレージ内にベースラインバージョンが存在し、両者をコンパクションして最新バージョンを取得する必要があります。同時に、メモリ内ではブロックキャッシュと行キャッシュが実装されており、ベースラインデータへのランダムアクセスを回避します。メモリ内の増分データが一定規模に達すると、増分データとベースラインデータのコンパクションがトリガーされ、増分データがディスクに書き込まれます。また、毎晩のアイドルタイムには、システムが自動的に日次コンパクションも行います。
OceanBaseデータベースでは、データはどのように保存されますか？
OceanBaseデータベースのデータファイルは、マクロブロック（Macro Block）単位でデータが整理されており、各マクロブロックのサイズは2MBです。マクロブロック内部にはさらに多くの16KB（圧縮前のサイズ）のマイクロブロック（Micro Block）が分割されており、各マイクロブロックには複数の行（Row）が含まれます。OceanBaseデータベース内部のI/Oの最小単位はマイクロブロックです。
パーティションテーブルを使用すべきでしょうか？
パーティションテーブルを使用するかどうかは、以下の情報を参考に判断できます：
予想される将来において、あるテーブルのデータ量が200GBを超える見込みがある場合は、パーティションテーブルの使用を推奨します。
テーブルに明確な時間帯がある場合は、パーティションテーブルの使用を推奨します。
OceanBaseデータベースにおいて、ローカルインデックスとグローバルインデックスの実装上の違いは何ですか？
ローカルインデックスとグローバルインデックスの違いは以下の通りです：
ローカルインデックス：単一のテーブルまたはパーティションテーブルの最小サブパーティションに結びつけられ、OceanBaseデータベースのシステムテナント内に追加のパーティションレコードを作成することはありません。ローカルインデックスに基づくSQLは基本的にすべてローカルで実行されます。
グローバルインデックス：OceanBaseデータベースのシステムテナント内に追加のパーティションレコードを作成する必要があり、これは別のテーブルとして理解でき、追加のパーティション割り当てを消費します。グローバルインデックスは独自のパーティショニングポリシーを持つことができ、ローカリティも主テーブルに結びつけられません。単一のテーブルであっても、グローバルインデックスは主テーブルとは別のノードに独立して保存することが可能です。このようにすることで、SQLを分散型SQLにすることも容易になります。