45 Oracle Globally Distributed DatabaseのMAAベスト・プラクティス
Oracle Globally Distributed Databaseの選択
お客様は、主に次の理由から、分散データベース・アーキテクチャを選択します:
- スケーラビリティと俊敏性(ハイパースケーリング)
- アプリケーションに変更を加えずに、シャード(ノード)をさらに追加することで、データを水平方向にスケーリングして、増加するデータ・ボリュームとユーザー・ロードに対応できます
- アプリケーションの透過性を保ちながらシャードを追加または削除できます
- 各シャードがアプリケーションに対してオープンでありアクティブです。
-
常時オンの継続的なデータベース可用性による高可用性
-
一部のシャードまたはノードが停止してもデータベースが動作し続けるようにするための、シャード間での自動フェイルオーバーおよびデータ・レプリケーション
- データ・センター、可用性ドメイン(AD)または可用性ゾーン(AZ)の障害からの保護など、フォルト・トレランスおよびシャード間の分離
- データベース障害の場合の、数秒での、または非常に低いリカバリ時間目標でのフェイルオーバー
- データ損失ゼロ
- シャード・データベース・インスタンスまたはノードの障害の場合のアプリケーションへの影響が5秒未満であることがMAAで観測された。「高可用性に関する推奨事項と観測結果」を参照してください。
-
-
シームレスな分散アプリケーション統合
- 分散アプリケーションは、当初には、データ操作にシャード・キーを使用して設計されおり、問合せは、シャードのスコープ指定に対応するように調整される場合があります。
- データベース・シャードの数のスケーリングや調整の際にアプリケーションに変更を加える必要はありません。
- アプリケーションの観点からは、分散データベースは単一のデータベースのように見えます。シャードの数と、それらのシャード間でのデータ分散は、アプリケーションに対して完全に透過的です。
-
一貫性とトランザクションのサポート
- アプリケーションでの必要性に応じて、すべてのシャードにわたり、必要なレベルのトランザクション保証(強力、最終的など)とともに、一貫したデータ読取り/書込みをサポートします。
- シャード・アプリケーションの外部一貫性とは、必ずトランザクションが、それらのコミットのリアルタイム(つまり"実時間")での順序を尊重した順序で、一度に1回実行されているように見えるようにするという特性です。これは、グローバルに分散されシャード化されたデータベースの場合の重要かつ困難な要件です。これにより、どのシャードと相互作用するかに関係なく、すべてのオブザーバに、同一の、グローバルに一貫したトランザクション履歴が表示されるようにします。
-
管理と監視の容易さ
- シャードのオーケストレーション、監視、バックアップ/リストア、高可用性、ソフトウェア更新およびスケーリング操作のためのシンプルな操作。
Raftレプリケーションを使用するOracle Globally Distributed Database 23aiでは、前述のすべての利点が提供されます。
分散データベース用のMAAは、可用性とスケーラビリティを最大限に高めるための、高可用性およびアプリケーションのベスト・プラクティスの提供に重点を置いた、MAAの新しいクラスです。
Raftレプリケーションを使用するグローバル分散データベースは、オラクル社の戦略的な、お薦めの分散データベース・ソリューションです。Oracle Globally Distributed Databaseの詳細は、Oracle Globally Distributed AI Databaseガイドを参照してください。
Raftレプリケーションを使用するOracle Globally Distributed DatabaseのMAAベスト・プラクティス
このトピックの範囲は、Oracle Database 23ai機能である、Raftレプリケーションを使用するOracle Globally Distributed DatabaseについてのMAAベスト・プラクティスであり、Oracle Real Application Clusters、Oracle Data GuardまたはOracle GoldenGateを利用する代替Oracle分散データベース・オプションは含まれません。
ノート: 既存のMAAアーキテクチャで実行されているアプリケーションや、様々なOracle Database機能(Oracle Real Application Clusters、Data Guard、Oracle GoldenGateなど)を使用するアプリケーションでは、引き続き、他のトピックで示されている既存のMAAベスト・プラクティスを使用する必要があります。
Oracle Maximum Availability Architecture (MAA)では、次のトピックを扱うベスト・プラクティスが編成されています:
- アーキテクチャと計画
- ネットワークに関する考慮事項とベスト・プラクティス
- アプリケーションのベスト・プラクティス
- 構成のベスト・プラクティス
- 高可用性に関する推奨事項と観測結果
- スケーリングに関する推奨事項と観測結果
- ソフトウェア更新に関する推奨事項と観測結果
- 監視とアラート
アーキテクチャと計画
Raftレプリケーションを使用するグローバル分散データベースのアーキテクチャ・コンポーネント
次の図に、Oracle Globally Distributed Databaseの主要なアーキテクチャ・コンポーネントを示します。
これらのコンポーネントは、理解しやすいように3つの層に分けることができます。
図45-1 Oracle Globally Distributed Databaseのアーキテクチャ
アプリケーション層
Oracle Globally Distributed Databaseにより、様々なアプリケーションに対して利点がもたらされます。このようなアプリケーションには、リアルタイムのOLTPシステム、グローバルに分散されたアプリケーション、データ・ストリーミング・プラットフォーム、高度な分析、および機械学習のワークロードが含まれている場合があります。
分散データベースの場合のアプリケーション・デプロイメントは、一般に、通常のOracle Databaseの場合のデプロイメントと同じプロセスに従います。アプリケーションは、グローバル・データ・サービス(GDS)によって定義されているグローバル・サービスを使用して、分散データベースに接続します。
Oracle接続プールおよびドライバでは、障害発生時のアプリケーションへの影響を5秒未満に抑える、高可用性機能を備えたOracle Globally Distributed Databaseがサポートされています。
グローバル分散データベースに関するアプリケーション・デプロイメントおよび構成のベスト・プラクティスについては、「アプリケーションのベスト・プラクティス」を参照してください
ルーティング層
Oracle Global Data Services (GDS)により、分散データベースでのルーティング層が管理されます。Oracle Database 23aiの導入により、GDSで、Raftレプリケーションを使用するOracle Global Distributed Databaseがサポートされています。
GDSでは、GDSCTLユーティリティを使用して分散データベースのシャード、Raftレプリケーション、グローバル・サービス・マネージャ(GSM)インスタンスおよびグローバル・サービスを管理するフレームワークが提供されます。
分散データベースのコンテキストでのGSMは、シャード・ディレクタと呼ばれます。シャード・ディレクタは、GSMの特殊な実装であり、分散データベースに接続するクライアント用のリージョナル・リスナーとして機能します。シャード・ディレクタにより、分散データベースの現在のトポロジ・マップが維持されます。接続リクエスト中に渡されたシャーディング・キーに基づいて、シャード・ディレクタによって、適切なシャードに接続がルーティングされます。
分散データベースの場合は、リージョンごとに3つのグローバル・サービス・マネージャを構成することをお薦めします。GDSでは、シャード・カタログ・データベースを使用して、分散データベース構成のレイアウトとステータスに関連するメタデータが格納されます。可用性を最大限に高めるために、シャード・カタログ・データベースを個別にデプロイし、Oracleの高可用性機能(Oracle Real Application Clusters (Oracle RAC)やOracle Data Guardなど)を使用してシャード・カタログ・データベースを停止から保護することをお薦めします。
GDSの実装と構成については、MAAの「Oracle Maximum Availability Architectureでのグローバル・データ・サービス」のガイドラインに従ってください。
データ層
データ層は複数のシャードからなり、それらは別々のホストにデプロイされたOracleデータベースです。すべてのシャードが一体になって、分散データベースと呼ばれる単一の論理データベースを形成しています。それらのシャードでは、ソフトウェアやハードウェアが共有されることはなく、他のシャードとの間の障害分離が実現されています。
シャード・データベースはどのプラットフォームにでもデプロイできます。Oracle Exadata Database Machineにデプロイした場合は、I/Oが非常に低遅延になることから、大きな利点がもたらされます。Exadataプラットフォーム上のシャードでは、Exadataスマート・スキャンおよびオフロードのパフォーマンスに関する利点と、Oracle Exadataの組込みの高可用性機能とデータ保護機能を活用することもできます。Oracle RestartやOracle Clusterwareでは、シャード・データベース・インスタンスまたはノードが停止した場合の再起動機能を提供できます。
各シャードには複数のレプリケーション・ユニット(RU)があり、それらは、1つのリーダーと複数のフォロワを使用してRaftレプリケーションによって保護されています。Raftレプリケーションは、シャード間のリーダーとフォロワのバランスのとれた分散を維持しようとします。アプリケーションにより、リーダーRUに対して透過的に書込みと読取りが実行されます。
Raftレプリケーションは、Raftグループ内の参加者の数またはレプリカの数を決定する特定のレプリケーション・ファクタ(RF)を使用して構成されます。この数には、リーダーとそのフォロワが含まれます。デフォルトでは、RaftシャードはRF 3でデプロイされます。つまり、データまたはレプリケーション・ユニットでは、3つのレプリカが、3つのシャードにわたり分散されます。
分散データベース・シャードの構成の詳細は、シャード・データベースの作成を参照してください。
計画
Raftレプリケーションを使用するOracle Globally Distributed Databaseデプロイメントを計画するには、いくつかの重要な要因を慎重に考慮する必要があります。
データ分散方法
Raftレプリケーションがレプリケーション方法として選択されている場合、重要な計画ステップは、データ分散計画の選択です。
まず、アプリケーションに最適なデータ分散方法がどれであるかを分析します。データ分散方法によって、アプリケーション・スキーマ表をどのようにパーティション化するかが決まります。また、その分散方法によって、シャードでのデータの配置も制御されます。
Raftレプリケーションでは、現時点では、システムによって管理されている(ハッシュ)分散方法と、複合データ分散方法がサポートされています。
各分散方法の詳細は、データ分散方法を参照してください。
レプリケーション
分散データベースの場合のレプリケーション計画は、主に、アプリケーションのワークロードの要件、待機時間の許容範囲およびリカバリ目標に基づいて選択されます。
Raftレプリケーションでは、シャード間の同期データ・レプリケーション、複数のレプリカによる高可用性、データの一貫性、および障害発生からのほぼゼロのリカバリ時間が実現されます。
このドキュメントでは、Raftレプリケーションを使用するグローバル分散データベースのみについて説明します。
トポロジ
グローバル分散データベース・コンポーネントの適切な配置は、ネットワーク待機時間の最適化、可用性の確保および操作の簡略化において重要な役割を果たします。
分散データベース・コンポーネントの配置を計画する際には、次の点を考慮してください:
- 最良の障害分離を実現するために、複数の可用性ドメインまたはゾーンにわたりシャードをデプロイします
- 様々なデータベース・シャードを使用しているときは、アプリケーションのレスポンス時間が許容範囲内であることを確認します。アプリケーションで、障害発生中やメンテナンス中に任意のシャードを利用できます。
- Oracle Data Guardでてシャード・カタログ・データベースを構成して高可用性とデータ保護を確保します。
- 高可用性とロード・バランシングを実現するために、複数のシャード・ディレクタ(GSMインスタンス)を使用します
容量
各シャードのサイズは、ワークロードのその部分を処理するのに十分なシステム・リソースに加えて、メンテナンスや停止で1つ以上のシャードを使用できないときにワークロードを処理できるようさらに30%余裕を持たせて設定する必要があります。ワークロードが増えた場合は、それに応じてサイズを変更します。
ネットワーク容量を計画する際には、アプリケーション・データ、シャード間通信、Raftレプリケーションのトラフィックおよびバックアップ・データのために必要な帯域幅を考慮してください。
容量の詳細は、ホストおよびオペレーティング・システムのプロビジョニングと構成を参照してください。
最後に、監視手順やフェイルオーバー手順など、分散環境を管理し操作するための明確な方法論を確立します。
計画フェーズの間にこれらの側面に対処することで、より回復力のあるスケーラブルかつ効率的なデプロイメントになります。
ネットワークに関する考慮事項とベスト・プラクティス
Raftレプリケーションを使用するOracle Globally Distributed Databaseでは、ネットワーク待機時間は、軽量な同期Raftレプリケーションを活用しながら許容可能なアプリケーション・パフォーマンスを確保する上で重要な要素です。トランザクションは、Raftリーダー1つとフォロワの半数によって変更内容がRaftログに書き込まれたときのみ完了します。コミット待機時間は、Raftリーダーと、そのトランザクションを完了するための定足数に含まれている最も遅いフォロワとの間の、ネットワーク・ラウンド・トリップ時間に影響を受けます。
ネットワーク待機時間が長くなると、ユーザー・トランザクションのレスポンス時間に影響する可能性があり、障害検出とロール・トランジションのタイミングにも影響する可能性があります。
Raftレプリケーションを使用するグローバル分散データベースのMAAネットワーク・ベスト・プラクティスの一部を次に示します:
- 使用可能なネットワーク帯域幅でアプリケーション・ワークロードに対応できることを確認します。
- シャード間の待機時間を考慮して同期Raftレプリケーションでのアプリケーション・パフォーマンス要件を満たせることを確認します。
- すべてのシャード・レプリカ間で安定したネットワーク接続を確保します。
- ネットワーク冗長性を実装して単一障害点をなくします。これには、冗長なネットワーク・インタフェース、スイッチ、および多様なネットワーク・パスを含めることができます。
- SLOの定義: ターゲットのコミット待機時間、読取り待機時間、RPO=0、地域損失のRTO。
iperfまたはoratcptestツールを使用してシャード間のネットワーク待機時間を検証します。- パフォーマンスを高め影響を最小限に抑えるために、次のネットワーク構成ベスト・プラクティスを実装します(特に、シャード間の距離が近い場合):
- Raftレプリケーションの論理変更レコードを送受信するネットワークインタフェースについて、最適なMTUサイズを検証します。実験では、複数の地理的地域にわたりレプリケーション・データを送信するときに、MTU=9000の使用により、一部のネットワーク・トポロジでメリットがある可能性があることがわかりました。oratcptestを使用してパフォーマンス・テストを実行し、その結果をデフォルトのMTU設定、およびMTU=9000の設定と比較します。これにより、不要なネットワーク・ラウンドトリップが削減され、全体的なスループットが向上する可能性があります。
- オペレーティング・システムのソケット・バッファの最大サイズを増やすと、単一のプロセス・スループットが2から8倍増加する可能性があります。複数のRaftシャード・ノードで様々なソケット・バッファ・サイズでテストして、どの値で最良の結果が得られるかを確認します(たとえば、より大きいTCPソケット・バッファ・サイズである64MBや128MB)。帯域幅遅延積とは、チャネルのネットワーク・リンク容量とラウンドトリップ時間(つまり、待機時間)の積です。ソケット・バッファ・サイズの最小推奨値は、特に待機時間の長い高帯域幅ネットワークの場合、3*BDPです。oratcptestを使用して、シャード・ノードでのソケット・バッファ・サイズをチューニングします。
- SDUにより、Oracle Net Services通信の最大パケット・サイズが決まります。大量のデータをレプリケートするときは、SDUが大きいと、いくつか利点があります。シャード・データベース・ノードにある
sqlnet.oraファイル内とtnsnames.oraファイル内でSDUサイズを設定します。SDUサイズをより大きい値(たとえば、65535)に設定し、そのアプリケーション・ワークロードで検証します。
ネットワーク・パフォーマンスの評価と最適化の詳しい例は、「ネットワーク・パフォーマンスの評価および最適化」と「ネットワーク評価」を参照してください。
アプリケーションのベスト・プラクティス
OLTPアプリケーションの場合は、シャーディング・キーを選択して最適なデータ分散を実現し、トランザクションが複数のシャードにまたがることを防ぎます。
シャードへの直接ルーティングは、最良のパフォーマンスを実現するためのお薦めのアプリケーション構成です。ルーティングの詳細は、シャードへの直接ルーティングを参照してください。
グローバル分散データベースとの最良の統合を実現するには、最新のOracle 23ai UCPおよびJDBCドライバを使用します。高可用性、および非常に短いリカバリ時間を実現するには、最新のドライバが必要です。接続プール、ドライバおよびAPIの互換性の詳細は、直接ルーティングをサポートするAPIを参照してください。
次の表では、様々な停止の場合に非常に短いアプリケーション・ブラウンアウトおよびブラックアウト(5秒未満)を実現するための、MAA評価に基づく重要なUCPパラメータと推奨値を説明します:
ノート:
次の特定のパラメータの値は、アプリケーションのSLA要件を満たすように調整できます。| UCP接続プールのパラメータ | 推奨値 | ノート |
|---|---|---|
initialPoolSize |
(アプリ・スレッドの合計数) * (シャード数) |
初期プール・サイズを推奨値に設定します。 また、静的接続プールを使用したReal-World Performanceの最適化で、オラクル社のReal-World Performanceグループからの、静的接続プールに関するベスト・プラクティス・ガイドラインを確認します。 |
minPoolSize |
initialPoolSizeと同じ | 静的接続プールの構成の場合は、初期プール・サイズと同じ値にします。 |
maxPoolSize |
minPoolSizeと同じ | アプリケーション要件に基づいた最大接続プール・サイズでピーク時のワークロードに対応できるようにします |
abandonedConnectionTimeout |
1秒 |
接続が一定時間使用されなかったときに、流用された接続を接続プールによって回収できるようにします。 デフォルトは0であり、機能は無効です。 |
connectionValidationTimeout |
1秒 |
このタイムアウトは、接続がプールから流用されているときに接続検証操作のために許可される最大期間を示しています。指定した期間内に検証が完了しなかった場合、接続は無効とみなされます。 デフォルトは15秒です。ハングした接続をより迅速に検出し可用性を高めるには、より小さい値にすることをお薦めします。 |
connectionWaitDuration |
1秒 |
プールからの使用可能な接続をリクエストが待つ最大時間(秒)を指定します。 接続の可用性をより積極的に検出するために、この値をミリ秒単位で指定することもできます。 このパラメータはOracle 23aiで新しく導入されました。パラメータ |
timeoutCheckInterval |
5秒 | 様々なタイムアウト・プロパティ(中止接続タイムアウト、存続時間接続タイムアウトおよび非アクティブ接続タイムアウトなど)が適用される頻度を制御します。 |
inactiveConnectionTimeout |
120秒 | 使用可能な接続がクローズされプールから削除される前にどのくらいの期間アイドル状態でいられるようにするかを指定します。デフォルト値は0であり、機能は無効です。 |
次の表では、JDBCのプロパティと推奨値を示します。
| JDBCのプロパティ | 推奨値 | ノート |
|---|---|---|
FastFailover |
true | このプロパティにより、高速アプリケーション通知(FAN)対応の高可用性動作が有効になります。それにより、接続プールでデータベース・ノードまたはサービスの障害を迅速に検出し対応できるようになります。 |
TcpNoDelay |
true | 有効になっている場合は、パケットが、それらのバッチ処理を待たずにすぐに送信されます。OLTPアプリケーションの待機時間を短縮するために役立つ可能性があります。 |
StatementCaching |
120 | 有効になっている場合は、キャッシュされた文を、データベースによって再解析するのではなく、再利用できます。それにより、効率が大幅に向上する可能性があります。 |
FetchSize |
30 | ネットワーク・ラウンドトリップの短縮に役立ちます。アプリケーション要件に基づいて値を調整します。 |
ReadTimeout |
30 |
データベース・ソケットからの読取り時にJDBCドライバが待機する最大時間(ミリ秒)を定義します。 アプリケーションのタイムアウト要件に従って、このパラメータの値を調整します。 |
oracle.jdbc.useShardingDriverConnection |
true | このJDBCプロパティにより、Oracle JDBCドライバに、接続に標準のJDBC Thinドライバではなくシャーディング・ドライバを使用するように指示します。Oracle Globally Distributed Databaseに接続する場合は、シャーディング・ドライバが必要です。 |
oracle.jdbc.allowSingleShardTransactionSupport |
true |
このプロパティが'true'に設定されている場合は、自動コミットが無効になっていると、データソースで、単一シャードでのローカル・トランザクションがサポートされます。 'false'に設定されている場合、トランザクションはカタログ・データベースで開始されます。 |
次の表では、Raftレプリケーション・ユニットおよびシャードのスイッチオーバー中とフェイルオーバー中にアプリケーションに発生するエラーの一部を示します。
アプリケーションでは、継続的に運用できるようにするために、これらのエラーに対する例外処理と、アプリケーション固有の要件に基づいた再試行ロジックを実装する必要があります。
| 例外コード | エラー・メッセージ | 説明 |
|---|---|---|
| ORA-03974 | シャード<shard_id> (レプリケーション・ユニット<ru_id>)へのスイッチオーバー中はDML操作を実行できません | このエラーは、レプリケーション・ユニットをあるシャードから別のシャードにスイッチオーバーしたことが原因で発生します。 |
| ORA-03838 | レプリケーション・ユニット<ru_id>のフォロワ・シャードでDML操作(<DML>)を実行できません。チャンクID <chunk_id> | このエラーは、レプリケーション・ユニットのスイッチオーバーの後に発生します。 |
| ORA-03996 | レプリケーション・ユニット<ru_id>のリーダーのリカバリ中にDML操作を実行できません |
このエラーは、フォロワ・シャードでLCRの適用が低速または不完全である場合(通常はリーダー・シャードのスイッチオーバー中かフェイルオーバー中)に発生します。 これは通常、アプリケーションの直接ルーティングではなく、プロキシ・ルーティングを使用してDMLを実行しているときに発生します。 |
| ORA-05048 | レプリケーション・ユニット<ru_id>のフォロワ・シャードでトランザクションをコミットできません。トランザクションID <txn_id> | このエラーは、レプリケーション・ユニットのフェイルオーバーが原因で発生します。 |
| ORA-45582 | チャンク<chunk_id>が見つからないか、別のシャードに移動されています | このエラーは、レプリケーション・ユニットのスイッチオーバーまたは移動操作が原因で発生します。 |
| ORA-17008 | クローズされた接続 | このエラーは、通常は、シャード・インスタンスまたはノードの障害の発生中に発生します。 |
| ORA-17002 | ネットワーク・アダプタは接続を確立できませんでした | このエラーは、シャード・ノードの障害またはネットワーク・エラーが原因で発生します。 |
| ORA-01013 | ユーザーが現在の操作の取消しをリクエストしました。 | 読取りタイムアウトまたはその他のタイムアウトが発生すると、進行中の問合せがUCPによって取り消され、そのコール元にORA-01013が返されます。 |
| UCP-29 | 接続を取得できませんでした | このエラーは、インスタンスまたはノードの障害が原因でシャードを使用できないため接続を取得できないときにUCPによって発生します。 |
構成のベスト・プラクティス
Raftログのサイズ設定と構成
Raftレプリケーションでは、変更内容はユーザー・トランザクションの一部として取得され、Raftログとも呼ばれるレプリケーション・ログに格納されます。オンラインREDOログやスタンバイREDOログと同様に、Raftログには、コミット済および未コミットのユーザー・トランザクションが含まれます。ユーザー・トランザクションは、フォロワの半数でそのコミット・レコードの確認応答が送信され、それがそれらのRaftログに保持されると、リーダー上で、コミット済とみなされます。
各レプリケーション・ユニットは、一連のRaftログ、およびRaftログを管理し変更内容をリーダーからフォロワにレプリケートするオペレーティング・システム・プロセスに関連付けられています。この設計により、複数のレプリケーション・ユニットが、単一シャード内の場合でも複数のシャードにわたる場合でも、独立してパラレルで機能できるようになっています。また、レプリケーション・ユニットの数を調整することでレプリケーションを柔軟にスケール・アップまたはスケール・ダウンできるようになっています。このアーキテクチャでは、同時実行性と障害分離が改善されるだけでなく、柔軟なスケーラビリティと高いパフォーマンスも実現されます。
Raftログのサイズ設定と配置は、シャード・データベースの予測可能なパフォーマンスとリカバリを維持するために重要です。Raftログは、db_create_file_destパラメータで制御される、シャード・データベース・ファイルとともに作成されます。最適なパフォーマンスを実現するために、Raftログを、待機時間が非常に短い、IOPSが大きいストレージ層に配置します。
デフォルトでは、各レプリケーション・ユニットは、3つのRaftログ(循環方式でローテーションされる)とともに作成されます。Raftプロトコルによって、フォロワが受け取るログ・レコードが、必ず、リーダーによって生成されたのと同じ順序になります。通常動作では、フォロワが、リーダーから次々と送られてくる変更内容を受け取ります。フォロワの1つがRaftレプリケーションにおいて遅れているか、計画停止や計画外停止のために再起動された場合は、そのフォロワのシャードでレプリケーション・プロセスが起動されると、リーダーによって、Raftログから変更レコードが送信されます。
フォロワのシャードが長期間停止したままであり、アプリケーション・ワークロードが原因でリーダーのRaftログがローテーションされたか上書きされた場合は、そのフォロワが、その再起動後に、欠落した変更内容と自動的には再同期できなくなくなります。この状況では、そのフォロワ・シャード上のレプリケーション・ユニットのリカバリが必要になります。これは通常は、別のフォロワ・レプリケーション・ユニット(リーダーと一致している)からのCOPY RU GDSCTLコマンドを使用して実行されます。オーバーヘッドと、リカバリにかかる時間の長さから、この状況を回避することをお薦めします。
次の表では、Raftログを管理するためのシャード・データベース・インスタンス・パラメータについてガイドラインを示します。
| パラメータ | デフォルト値 | 推奨値 | ノート |
|---|---|---|---|
shard_raft_logfile_size |
1GB | Raftログのサイズをシャード・データベースのREDOログと等しくします |
開始点として、データベースREDOログのサイズと一致するようにRaftログのサイズを設定することをお薦めします。 アプリケーション・ワークロードのピークの間の各Raftログのローテーション時間を分析することで、サイズをより適切に推定できます。 |
_shard_raft_log_retention_time_mins |
Null | 1440 (24h) | Raftログの保存ウィンドウを、シャードの計画停止および計画外停止に対応できる十分な大きさに設定します。Raftログの保存により、リーダーで、停止の後に変更内容をフォロワに送信して自動的に再同期できるようになります。 |
_shard_max_num_raft_logfile |
10 | 32 |
このパラメータにより、RU当たりのRaftログの合計数を制御します。パラメータ ピーク時のワークロードと保存ウィンドウに対応できるように、この値を大きい数値に設定することをお薦めします。最大値は32です。 ノート: Raftログの数が、保存時間枠に対応するのに十分な大きさでない場合は、Raftによってレプリケーション・ユニットが停止され、「 |
追加構成のベスト・プラクティス
Raftレプリケーションを使用するグローバル分散データベースについて追加構成のベスト・プラクティスを次に示します:
- シャード・データベースとRaftログのストレージ層のサイズを、次のことのための十分なI/O容量に対応できるように設定します:
- アプリケーション・ワークロード
MOVE RU操作またはCOPY RU操作のためのRMANバックアップおよびリモート・リストア操作。- Exadataでは、追加のI/O帯域幅、非常に短いコミット待機時間、Exadataスマート・フラッシュおよびExadataスマート・オフロードが提供されます。
- 各可用性ドメインまたはゾーンにおいて、高可用性を実現するために、複数のシャード・ディレクタをデプロイします。
- シャード・カタログ・データベースの保護と可用性のために、Data Guardファスト・スタート・フェイルオーバーを構成します。
- 柔軟性、容量管理およびワークロード・バランシングのために、シャードを追加でデプロイします。
- メンテナンスや停止のために1つのシャードを使用できないときでも許容可能なパフォーマンスが維持されるように、シャードのサイズを設定します。
- 様々なワークロードでのRaft同期レプリケーションのパフォーマンスを基準に従って評価します。
- Raftシャード・インスタンスの障害を自動的に検出し再起動するメカニズムを実装します。
- Oracle Restart、ExadataまたはOracle Clusterwareでは、これらの機能が提供され、単一インスタンス・データベースを管理することもできます。
- 障害分離の目標、および待機時間の割当てと一致するように、独立した複数の障害ドメインと可用性ドメインにわたりRaftシャードを配置します。
高可用性に関する推奨事項と観測結果
グローバル分散データベースの高可用性機能と回復性機能を検証することが不可欠です。Oracle MAAでは、Raftレプリケーションを使用するグローバル分散データベースの厳格で広範なテストが実施されており、次の推奨事項と考慮事項が提供されています。
- 計画停止と計画外停止の後のシャード・データベース・インスタンスについてアラート機能と自動再起動機能を追加します。
Oracle RestartやOracle Clusterwareは、この機能を提供しており、ローカル・リスナーやシャード・データベース・インスタンスの再起動のためにシームレスに機能します
- 次の停止シナリオを評価して、分散データベースでアプリケーションが透過的にフェイルオーバーされることを検証します:
- シャード・データベース・インスタンスまたはノードの障害
- ソフトウェア更新のメンテナンス・ウィンドウをシミュレートするためのシャード再起動
- Raftレプリケーションのハートビート損失タイムアウトおよび選出タイムアウトの値は、データベースによって自動的に管理されます。広範なハートビート障害が原因でOracleサポートから指示されないかぎり、内部パラメータを使用してそれを変更しないでください。
デフォルトのハートビート間隔は150-300ミリ秒の間です。複数のシャードで同時に選出がトリガーされるのを防ぐため、選出タイムアウトはランダムになっています(最大150ミリ秒)。
Oracle MAAでは、データベース・インスタンスとシャード・ノードの障害状態の下での分散データベースのRaftシャードのテスト中に、次のことが観測されました。
シャード・データベース・インスタンスの障害
- シャード・データベース・インスタンスの障害による影響は、約2秒であり、短いアプリケーション・ワークロード・ブラウンアウトがあります。
- リーダーRUは自動的に、存続しているシャード上のフォロワRUにフェイルオーバーされます。
- Oracle RestartまたはOracle Clusterwareによって障害が検出され、そのシャード・データベース・インスタンスが自動的に再起動されます。
- 再起動後、障害が発生したシャード・インスタンスにあるフォロワRUが、リーダーRUから変更内容を受け取ることで、そのレプリケーションと自動的に再同期されます。
シャード・ノードの障害
- シャード・ノードの障害による影響は、通常5秒未満であり、短期間の、より大きいアプリケーション・ワークロード・ブラウンアウトがあります。
- リーダーRUは自動的に、存続しているシャード上のフォロワRUにフェイルオーバーされます。
- シャード・ノードが障害からリカバリされると、Oracle RestartまたはOracle Clusterwareによって、シャード・データベース・インスタンスおよびローカル・リスナーが自動的に再起動されます。
- 再起動の後に、障害が発生したシャード・インスタンスにあるフォロワRUが、リーダーRUから受け取った変更内容を適用することで、そのレプリケーション・ストリームと自動的に再同期されます。
シャード・データベース・インスタンスおよびノードの障害のベスト・プラクティス
- アプリケーション・ワークロードのバランスを取るために、リーダーRUを、次の使用可能な機会に、リカバリされたシャードに戻します。
- シャード・データベース・インスタンスおよびノードの停止期間が長くなることを回避します。
シャードが長く停止しており、リーダーのRaftログがローテーションされた場合、障害が発生したシャードは、そのレプリケーションと自動的には再同期できなくなります。このシナリオでは、そのシャードにあるすべてのフォロワRUのリカバリが必要になります。シャードの自動検出と再起動は、この状況を回避するために役立つ可能性があります。
- シャード・データベース・インスタンスおよびノードの障害発生中に発生した特定のエラー・メッセージについて例外処理を実装します。
スケーリングに関する推奨事項と観測結果
Raftレプリケーションを使用するグローバル分散データベースでは、スケーラビリティとロード・バランシングのために、その構成に対してシャードを追加または削除できます。ADD SHARD操作やREMOVE SHARD操作は、データベース停止時間なしでオンラインで実行できます。Raftレプリケーションでは、データ分散と再配置が自動的に管理されます。
ADD SHARDプロセスの間に、新しいRUが作成され、既存のRUからのCHUNK表領域が、新しいRUに再配置されます。その後、それらの新しいRUが、追加するシャードに移動されます。
シャードを削除する前に、RUを、RUフォロワが存在しないシャードに再配置する必要があります。
分散データベース構成に対してシャードを追加または削除する方法の詳細なステップは、Raftレプリケーションによるスケーリングを参照してください。
Oracle MAAでは、様々なワークロードの下でRaftシャードのスケーリングの広範なテストが実行されており、シャードのスケーラビリティについて次の考慮事項と推奨事項が提供されています。
シャードの追加に関する推奨事項
- 新しいシャードと既存のシャードの間のネットワーク待機時間を評価して、レプリケーション・ユニットがその新しいシャードに移動された後のアプリケーション・レスポンス時間に対する影響の可能性を定量化します。
- 新しいシャードにRUを移動できるようにするための十分なI/OおよびCPU容量があることを確認します。新しいシャードへのRUの移動は、その新しいシャードから開始されたリモートRMANリストアおよびリカバリ・プロセスを使用して実行されます。
- 影響を最小限に抑えるために、アプリケーション・アクティビティが少ないときやメンテナンス・ウィンドウの間に
ADD SHARDプロセスを開始します。ワークロードが高い場合は、MOVE RU操作によって、複数の短いアプリケーション・ブラウンアウトが発生する可能性があります。
シャードの削除に関する推奨事項
- 削除するシャードからRUを取り込むための十分なコンピュート、ストレージおよびIOPS容量がターゲット・シャードにあることを確認します。
- RUの再分散の後、存続しているシャード間でアプリケーション・ワークロードのバランスが取れたままになるかどうかを確認します。
- 影響を最小限に抑えるために、アプリケーション・アクティビティが少ないときやメンテナンス・ウィンドウの間にREMOVE SHARDプロセスを開始します。ワークロードが高い場合は、MOVE RU操作によって、複数の短いアプリケーション・ブラウンアウトが発生する可能性があります。
計画メンテナンスまたはソフトウェア更新に関する推奨事項と観測結果
計画メンテナンス(ソフトウェア更新など)は、Oracle Globally Distributed Databaseコンポーネントのどれについても頻繁に発生する可能性があります。
次のMAAベスト・プラクティスとガイドラインでは、Raftレプリケーションを使用するOracle Globally Distributed Databaseの計画メンテナンスの間のアプリケーション停止時間をゼロにできます。
MAAベスト・プラクティスに従ってデプロイされた複数のGSMインスタンスにより、GDSを使用してグローバル分散データベースに接続するアプリケーションに、シームレスなローリング・ソフトウェア更新エクスペリエンスを提供できます。
Oracle RACおよびData Guardとともにデプロイされたシャード・カタログ・データベースの場合は、MAAの高可用性のベスト・プラクティスに従うことで、停止時間なしのメンテナンスが可能になります。
レプリケーション・ユニット・リーダーのスイッチオーバー
バランスの取れた構成では、すべてのシャード・データベースに1つ以上のRUリーダーがあり、アプリケーションではこれらに対して読み書きしています。
計画メンテナンス・アクティビティの前に、シャードからRUリーダーを切り替えることをお薦めします。Raftレプリケーション・ユニットのスイッチオーバーは、指定したタイムアウト値によって安全な方法で実行できます。この方法では、アプリケーション・トランザクションをそのシャードで完了してから、スイッチオーバーして別のシャード上のRUのリーダーシップを有効にできます。
次のワークフロー例では、あるシャードから別のシャードへのRUリーダーのスイッチオーバーを示します。
この例では、shard1からshard2への、RU # 1のスイッチオーバーが実行されます。
スイッチオーバーの前は、RUリーダー(RU1 - L)は、次に示すようにshard1にあります:
- RUのステータスをチェックして、RUフォロワが正常な状態であることを確認します。
GDSCTL> status ru -ru 1 Replication units ------------------------ Database RU# Role Term Log Index Status -------- --- ----- ---- --------- ----- shard1 1 Leader 155 123242128 Ok shard2 1 Follower 155 123242128 Ok shard3 1 Follower 155 123242128 Ok - GDSCTLの
SWITCHOVER RUコマンドを実行します。このコマンドでは、RUのどのメンバー(それが存在するシャードで指定)がリーダーであるかが変更されます。
-timeout値により、トランザクションを完了できるようになります。ターゲット・シャードのRUは、前のリーダーが読取り専用になるまで、読取り/書込みに使用できません。GDSCTL> switchover ru -ru 1 -shard shard2 -timeout 1 Switchover process has been started Switchover process completed The operation completed successfullyswitchoverコマンドの完了後は、次に示すように、RU #1のリーダーはshard2にあります:
- RU # 1のステータスをチェックします。
GDSCTL> status ru -ru 1 Replication units ------------------------ Database RU# Role Term Log Index Status -------- --- ----- ---- --------- ----- shard1 1 Follower 155 123242128 Ok shard2 1 Leader 155 123242128 Ok shard3 1 Follower 155 123242128 Ok
計画メンテナンスのベスト・プラクティス
計画メンテナンスのベスト・プラクティス・ガイドライン:
- シャードでのメンテナンスをローリング方式で実行します。
- シャードの容量を検証して、それらのシャードで、メンテナンス対象のシャードからRUリーダーがスイッチオーバーされたときに追加ワークロードに対応できることを確認します。
- 容量分析には、AHFの
oswatcherツールと、その他のオペレーティング・システム監視コマンドを使用できます。
- 容量分析には、AHFの
- 各シャードで、「グローバル分散データベースのヘルス・チェックと監視」で示されているGDSCTLコマンドまたはディクショナリ・ビューを使用して、Raftレプリケーションの適用ラグと適用エラーをチェックします。
- Raftレプリケーションの適用ラグが高い場合は、レプリケーション・ユニットのスイッチオーバーに時間がかかるか失敗する可能性があります。
- レプリケーション・ユニットのスイッチオーバーの前に、適用ラグの問題に対処します。
- メンテナンス対象のシャードにあるRUのリーダーシップ・ステータスを検証し、RUリーダーを、十分な容量がある別のシャード・データベースに切り替えます。
- GDSでGDSCTLの
STATUS RUコマンドを使用して、RUのリーダーシップ・ステータスをチェックします。「グローバル分散データベースのヘルス・チェックと監視」を参照してください - アプリケーションのエラーと影響を最小限に抑えるために、必ず、
SWITCHOVER RUコマンドでタイムアウト・オプション(1-2ミリ秒)を使用します。
- GDSでGDSCTLの
- ローリング・シャード・メンテナンスの間は、次のシャードを停止する前に、ヘルス・チェックを実行します。
- シャードがオンラインに戻ると、Raftレプリケーションによって自動的に再同期が開始されます。ただし、変更内容の数と停止の期間によっては、それが最新になるまでに時間がかかる場合があります。
- シャードがオンラインに戻ったら、GDSCTLユーティリティを使用して、そのシャード上のRUフォロワのステータスとログ索引を検証します。RUフォロワのログ索引が、リーダーのログ索引と同じかほぼ同じにならないと、フォロワは最新ではありません。
- Raftレプリケーションの変更内容の適用が開始された後、シャード上のレプリケーション・ユニットの適用ラグを検証します。
- シャードのローリング・メンテナンス中に、RUリーダーとアプリケーション・ワークロードのバランスを取るために、一部のRUメンバーを、更新されたシャードに戻します。
- ローリング・メンテナンスの最後に、残りのRUを正規化し均衡化します。
- シャードが3つでレプリケーション・ユニットが6つの場合、リバランスには少なくとも10回のスイッチオーバーが必要になり、アフィニティを使用したリバランスの場合や、RUリーダーを元のシャードに戻す場合は、12回のスイッチオーバーが必要になります。
ローリング・シャード・メンテナンスのワークフロー例
次の例では、3つのシャードと6つのRUがあるグローバル分散データベースの場合のローリング・シャード・メンテナンスを示します。
この例で使用されているシャード名は、shard1、shard2およびshard3です。この例でのRU番号は、1から6です。
バランスの取れた構成では、各シャードで、2つのRUリーダーと4つのRUフォロワがホストされます。
このタスクを完了するには、次のステップを実行します。
ステップ1: シャードのヘルスとRUのリーダーシップ・ステータスを確認する
GDSCTLを使用して、すべてのシャードにわたり、すべてのRUのヘルスとステータスをチェックします:
GDSCTL> status ru -sort「グローバル分散データベースのヘルス・チェックと監視」で示されている適用ラグ・チェック問合せを実行して、どのシャードにも適用ラグの問題がないことを確認します。
STATUS RUコマンドの出力ですべてのRUでOKステータスが報告されたことと、その適用ラグが数秒以内であることを確認した後のみ、次のステップに進みます。
ステップ2: 最初のシャードからRUリーダーをスイッチオーバーする
メンテナンス対象の最初のシャードで、RUのリーダーシップ・ステータスをチェックし、最初のシャードから他のシャードにRUリーダーを切り替えます。
GDSCTL> status ru -leaders -sort
Replication units
------------------------
Database RU# Role Term Log Index Status
-------- --- ---- ---- --------- ------
shard1 1 Leader 1 1 Ok
shard1 2 Leader 1 1 Ok
shard2 3 Leader 2 2 Ok
shard2 4 Leader 2 2 Ok
shard3 5 Leader 2 2 Ok
shard3 6 Leader 2 2 Okshard1でのみRUリーダーのステータスをチェックするには、次のコマンドを実行します:
GDSCTL> status ru -leaders -shard shard1タイムアウト・オプションを使用して、shard1から他のシャードにすべてのRUリーダーをスイッチオーバーします。
GDSCTL> switchover ru -ru 1 -shard shard2 -timeout 1
GDSCTL> switchover ru -ru 2 -shard shard3 -timeout 1最初のシャードにRUリーダーが残っていないことを確認します。
GDSCTL> status ru -leaders -shard shard1ステップ3: 最初のシャードでメンテナンスを実行し再起動する
Shard1は、メンテナンスのために停止でき、そのアクティビティが完了したら再起動できます。
ステップ4: 最初のシャードにあるRUフォロワがRaftレプリケーションで再同期されていることを確認する
シャードがオンラインに戻ると、そのシャード上のすべてのRUメンバーが、フォロワの役割を引き継ぎます。これらのRUフォロワで、自動的にRUリーダーから更新内容を受け取り、再同期が開始されます。
それらのRUフォロワで同期を完了できるようにする必要があります。続行する前に、それらのログ索引がRUリーダーのものと同じかほぼ同じであることを確認します。
GDSCTL STATUS RUコマンドの実行方法と、RUで使用されるログ索引の詳細は、「グローバル分散データベースのヘルス・チェックと監視」を参照してください。
GDSCTL> status ru -sort
GDSCTL> status ru -shard shard1ステップ5: 2番目のシャードからRUリーダーをスイッチオーバーする
ステップ2でリーダーの1つがshard1から切り替えられたため、2番目のシャードには3つのRUリーダーがあります。
shard2から他のシャードにすべてのRUリーダーをスイッチオーバーします。
GDSCTL> status ru -leaders -sort
Replication units
------------------------
Database RU# Role Term Log Index Status
-------- --- ---- ---- --------- ------
shard2 1 Leader 1 1 Ok
shard3 2 Leader 1 1 Ok
shard2 3 Leader 2 2 Ok
shard2 4 Leader 2 2 Ok
shard3 5 Leader 2 2 Ok
shard3 6 Leader 2 2 Okshard2でのみリーダーRUのステータスをチェックするには、次のコマンドを実行します:
GDSCTL> status ru -leaders -shard shard2タイムアウト・オプションを使用して、shard2から他のシャードにすべてのRUリーダーをスイッチオーバーします。RU # 1は、元のホストに再配置できるように、shard1に戻す必要があります。
GDSCTL> switchover ru -ru 1 -shard shard1 -timeout 1
GDSCTL> switchover ru -ru 3 -shard shard1 -timeout 1
GDSCTL> switchover ru -ru 4 -shard shard3 -timeout 12番目のシャードにRUリーダーが残っていないことを確認します。
GDSCTL> status ru -leaders -shard shard2ステップ6: 2番目のシャードでメンテナンスを実行し再起動する
Shard2は、メンテナンスのために停止でき、そのアクティビティが完了したら再起動できます。
ステップ7: 2番目のシャードにあるRUフォロワがRaftレプリケーションで再同期されていることを確認する
shard2でのメンテナンスの後は、それらのRUフォロワで同期を完了できるようにする必要があります。続行する前に、それらのログ索引がRUリーダーのものと同じかほぼ同じであることを確認します。
GDSCTL> status ru -sort
GDSCTL> status ru -shard shard2ステップ8: 3番目のシャードからRUリーダーをスイッチオーバーする
GDSCTL> status ru -leaders -sort
Replication units
------------------------
Database RU# Role Term Log Index Status
-------- --- ---- ---- --------- ------
shard1 1 Leader 1 1 Ok
shard3 2 Leader 1 1 Ok
shard1 3 Leader 2 2 Ok
shard3 4 Leader 2 2 Ok
shard3 5 Leader 2 2 Ok
shard3 6 Leader 2 2 Okshard3でのみRUリーダーのステータスをチェックするには、次のコマンドを実行します:
GDSCTL> status ru -leaders -shard shard3タイムアウト・オプションを使用して、shard3から他のシャードにすべてのRUリーダーをスイッチオーバーします。RU # 2のリーダーは、元のホストに再配置されるように、shard1に戻す必要があります。RU # 4のリーダーは、元のホストに再配置されるように、shard2に戻す必要があります。
GDSCTL> switchover ru -ru 2 -shard shard1 -timeout 1
GDSCTL> switchover ru -ru 4 -shard shard2 -timeout 1
GDSCTL> switchover ru -ru 5 -shard shard1 -timeout 1
GDSCTL> switchover ru -ru 6 -shard shard2 -timeout 13番目のシャードにRUリーダーが残っていないことを確認します。
GDSCTL> status ru -leaders -shard shard3ステップ9: 2番目のシャードでメンテナンスを実行し再起動する
Shard3は、メンテナンスのために停止でき、そのアクティビティが完了したら再起動できます。
ステップ10: 3番目のシャードにあるRUフォロワがRaftレプリケーションで再同期されていることを確認する
shard3でのメンテナンスの後は、それらのRUフォロワで同期を完了できるようにする必要があります。続行する前に、それらのログ索引がRUリーダーのものと同じかほぼ同じであることを確認します。
GDSCTL> status ru -sort
GDSCTL> status ru -shard shard3ステップ11: すべてのシャードにわたりRUリーダーをリバランスする
すべてのシャードでメンテナンスが完了したら、RUリーダーをそれらの元の場所にリバランスして、負荷の均一分散を元の状態に戻す必要があります。
GDSCTL> status ru -leaders -sort
Replication units
------------------------
Database RU# Role Term Log Index Status
-------- --- ---- ---- --------- ------
shard1 1 Leader 1 1 Ok
shard1 2 Leader 1 1 Ok
shard1 3 Leader 2 2 Ok
shard2 4 Leader 2 2 Ok
shard1 5 Leader 2 2 Ok
shard2 6 Leader 2 2 OkRUリーダーをshard1とshard2からshard3に切り替えてRUのバランスを取ります。
GDSCTL> switchover ru -ru 3 -shard shard2 -timeout 1
GDSCTL> switchover ru -ru 5 -shard shard3 -timeout 1
GDSCTL> switchover ru -ru 6 -shard shard3 -timeout 1別の方法として、単一のコマンドを使用してすべてのRUをそれらの元のシャードの場所に再配置するには、-rebalanceオプションを指定してSWITCHOVERコマンドを使用します。SWITCHOVER -rebalanceコマンドでは、RUの元のアフィニティが認識され、バックグラウンドで複数のスイッチオーバー・コマンドが発行されます。
GDSCTL> switchover ru -rebalanceスイッチオーバーの完了後に、すべてのRUのバランスが取れていることを確認します。
GDSCTL> status ru -sort
GDSCTL> status ru -leaders -sortグローバル分散データベースのヘルス・チェックと監視
- Raftレプリケーションのプロセスの情報と、特定のエラー・メッセージは、通常は、シャード・データベース・インスタンスのアラート・ログ内でレポートされます。ただし、
$DIAG_DIR/diag/rdbms/<dbname>/<sid_name>/logディレクトリにある、シャード・データベース・インスタンスのデバッグ・ログdebug_<sid>.logには、追加情報が記録されています。その例を次に示します:- Raftレプリケーションのプロセスの状態変化に関する情報。
- RUリーダーおよびフォロワのハートビート失敗とロール・トランジションに関するメッセージ。
- たとえば、"SNRロール変更RU_ID 1. CANDIDATE. 理由はハートビート損失"
- 包括的なネットワーク監視を実装して、帯域幅の使用率、待機時間、およびパフォーマンスに影響を与える可能性がある潜在的なネットワーク問題を追跡します。
- Raftレプリケーションに影響するネットワーク問題を管理者に通知するようにアラートを構成します。
- RUのヘルス・ステータスと適用ラグを監視します。
- 容量の追跡とパフォーマンスのトラブルシューティングには、シャード・データベースのAWR/ASHレポートを使用します。バランスの取れた構成で、シャードの追加と削除の場合に備えて、Raft RUリーダー配置のためのランブックを確立します。
次に、RUの全体的なヘルスとステータスをチェックするための、GDSCTLユーティリティを使用した便利なコマンドをいくつか示します。
例45-1 すべてのシャードにわたるレプリケーション・ユニットすべてのヘルスのチェック
すべてのシャードにわたりレプリケーション・ユニットすべてのヘルスをチェックするには、次のコマンドを実行します。
STATUS RUコマンドでは、各RUのステータスとログ索引が表示されます。ログ索引とは、RUによって確認応答が送信された、最新のRaftログ・エントリ索引を意味します。RUリーダーによってログ・エントリが割り当てられ、それらがRUフォロワにレプリケートされます。RUフォロワのログ索引は、通常動作ではRUリーダーのログ索引と同じかほぼ同じです。
GDSCTL> status ru -sort例45-2 すべてのレプリケーション・ユニット・リーダーのステータスのチェック
GDSCTL> status ru -leaders -sort例45-3 すべてのレプリケーション・ユニットへのチャンク割当てのチェック
GDSCTL> status ru -show_chunks -sort例45-4 レプリケーション・ユニットの詳細ステータスおよびエラーのチェック
GDSCTL> status ru -ru 1
GDSCTL> ru -ru 1 -show_errors例45-5 進行中のGDSタスクまたはジョブのステータスのチェック
GDSCTL> config task例45-6 GDSタスクの取消しまたは再開
GDSCTL> alter task -resume -task <no>
GDSCTL> alter task -cancel -task <no>有用なシャード・データベース問合せ:
例45-7 適用ラグのチェック
適用ラグをチェックするには、特権ユーザーとしてシャードPDBにログインし、次のSQLを実行します:
SELECT
ru_id,
state,
apply_name,
case
when (hwm_lcr_create_time > hwm_lcr_create_time) then 0
else NVL(( hwm_time - hwm_lcr_create_time ) * 86400, 0) end as latency_in_seconds,
to_char(hwm_lcr_create_time, 'HH24:MI:SS MM/DD/YY') AS message_creation_time,
to_char(hwm_time, 'HH24:MI:SS MM/DD/YY') AS apply_time,
hwm_lcr_log_index,
processed_lcr_log_index
FROM
v$shard_apply_coordinator;例45-8 転送ラグのチェック
転送ラグをチェックするには、特権ユーザーとしてシャードPDBにログインし、次のSQLを実行します:
SELECT
lcr_prdcr.ru_id AS ru_id,
ntwk_sndr.remote_peer_id as remote_peer_id,
'' as follower_shard,
ntwk_sndr.startup_time AS network_sender_startup,
lcr_prdcr.startup_time AS lcr_prdcr_startup,
ntwk_sndr.state AS network_sender_state,
lcr_prdcr.state AS lcr_prdcr_state,
lcr_prdcr.flwctrl_peers as flwctrl_peers,
case
when (ntwk_sndr.last_sent_lcr_time > lcr_prdcr.last_enqueued_lcr_time) then 0
else nvl( abs(lcr_prdcr.last_enqueued_lcr_time - ntwk_sndr.last_sent_lcr_time) * 86400, 0) end AS transport_lag_seconds,
( lcr_prdcr.last_enqueued_lcr_log_index - last_sent_lcr_log_index ) AS transport_lag_logindexes,
ntwk_sndr.elapsed_propagation_time elapsed_propagation_time,
ntwk_sndr.connect_error_count connect_error_count
FROM
v$shard_lcr_producer lcr_prdcr,
v$shard_network_sender ntwk_sndr
WHERE
lcr_prdcr.ru_id = ntwk_sndr.ru_id;例45-9 すべてのレプリケーション・ユニットのRaftログのステータスのチェック
すべてのレプリケーション・ユニットについてRaftログのステータスをチェックするには、シャードPDBにログインし、次のSQLを実行します。
値が'Y'のCURR_FILE列は、各レプリケーション・ユニットについて、どのRaftログが現在のファイルであるかを示しています。
set lines 200 pages 200
col name for a95
col start_time_timestamp for a35
select ru_id, name, rotd_idx, size_gb, curr_file, timestamp'1970-01-01 00:00:00' + numtodsinterval ( start_sec, 'second' ) start_time_timestamp
from v$shard_lcr_logs order by ru_id, curr_file, rotd_idx;
set lines 200 pages 200
col name for a95
col start_time_timestamp for a35
select ru_id, rotd_idx, size_gb, curr_file, STIDX_LOW, STIDX_HIGH, ENDIDX_LOW, ENDIDX_HIGH, timestamp'1970-01-01 00:00:00' + numtodsinterval ( start_sec, 'second' ) start_time_timestamp
from v$shard_lcr_logs order by ru_id, curr_file, rotd_idx;