Skip to main content

シャーディング・リファレンス

このページでは、シャード構成の計画、導入、および使用に関する追加情報を紹介します。

InterSystems IRIS シャード・クラスタの計画

このセクションでは、基本的なシャード・クラスタの計画と、計算ノードの追加 (該当する場合) に関する一次ガイドラインを紹介します。完全な設計および計画プロセスに関する詳細な説明を目的としたものではありません。以下のタスクについて説明します。

シャーディングと垂直方向の拡張の併用

シャーディングについて計画する際には、一般に、システムごとのリソースと使用するシステム数との間のトレードオフを考慮する必要があります。極端に言えば、2 つの主なアプローチを以下のように説明できます。

  • 垂直方向に拡張して、各システムおよびインスタンスの性能をできるだけ高めてから、高性能なノードを追加して水平方向に拡張します。

  • 高度な構成の高性能な 1 つのシステムに代わるコスト効率の高い手段として、手ごろな価格であるが、性能が劣るシステムを複数使用して水平方向に拡張します。

実際には、ほとんどの場合、これらのアプローチを組み合わせると最も効果を発揮します。他の水平方向の拡張アプローチとは異なり、InterSystems IRIS のシャーディングは、InterSystems IRIS の優れた垂直方向の拡張性と容易に組み合わせることができます。多くの場合、4 ～ 16 台のデータ・ノードを含む、処理能力がかなり高いシステムでホストされているクラスタで最も大きな成果が得られます。

データ・ノードの基本的なクラスタの計画

下記のガイドラインを使用するには、クラスタに格納するデータの量に関連するいくつかの変数を見積もる必要があります。

  1. まず、クラスタに格納するデータを検討して、以下について見積もりを行います。

    1. クラスタに格納するシャード・テーブルすべて (インデックスを含む) の合計サイズ。

    2. クラスタに格納するシャード化されていないテーブルのうち、シャード・テーブルと頻繁に結合されるもの (インデックスを含む) の合計サイズ。

    3. クラスタに格納するシャード化されていないすべてのテーブル (インデックスを含む) の合計サイズ。(前の見積もりはこの見積もりのサブセットです。)

  2. 定期的にクエリが実行されるデータの割合に基づいて、これらの合計を、予測される作業セットに変換します。

    作業セットの見積もりは、複雑な問題である場合があります。既存のデータベース・キャッシュの過去の使用統計から、これらの作業セットに関する有用な情報を取得できることがあります。それに加えて、またはその代わりに、テーブルを 3 つのカテゴリに分け、以下の作業を行うことにより、それぞれについて大まかな作業セットを特定します。

    • テーブルに対して頻繁に実行される重要な SELECT 文について、WHERE 節を確認します。それらは通常、テーブルおよび列の統計に基づいてサイズを見積もることができる可能性があるデータのサブセットを調べますか。個々の SELECT 文によって取得されるサブセットは相互に重複していますか、それとも相加的ですか。

    • 重要な INSERT 文のサイズと頻度を確認します。これらを作業セットに変換するのはさらに難しい場合がありますが、簡単なアプローチとして、1 時間あたりの平均取り込み速度を MB 単位で見積もり (1 秒あたりのレコード数 * レコードの平均サイズ * 3600)、それをテーブルの作業セットに加算します。

    • 返される結果を具体的に見積もることができる可能性がある他の高頻度のクエリを検討します。

    • シャード化されていないテーブルとシャード・テーブルを結合するクエリは作業セット NonshardSizeJoinedWS に反映され、シャード化されていない同じデータ・テーブルに対するクエリのうち、シャード化されていないテーブルをシャード・テーブルに結合しないものは作業セット NonshardSizeTotalWS に反映される点に留意してください。シャード化されていない同じデータが両方のタイプのクエリによって返されることがあるため、両方の作業セットに反映されます。

    その後、これらの見積もりを合計して各テーブルの作業セットについて 1 つの見積もりを作成し、それらの見積もりを加算することで全体的な作業セットを大まかに計算できます。これらの全体的な見積もりはかなり大まかである可能性があり、プロダクション環境では調整が必要になることがあります。50% の安全係数を各見積もりに加算し、最終的な合計データ・サイズと作業セットを以下の変数として記録します。

    クラスタの計画に関する変数

    変数

    値

    ShardSize、ShardSizeWS

    シャード・テーブルの合計サイズと作業セット (安全係数を含む)

    NonshardSizeJoined、NonshardSizeJoinedWS

    シャード・テーブルに頻繁に結合されるシャード化されていないテーブルの合計サイズと作業セット (安全係数を含む)

    NonshardSizeTotal、NonshardSizeTotalWS

    シャード化されていないテーブルの合計サイズと作業セット (安全係数を含む)

    NodeCount

    データ・ノード・インスタンスの数

下記のテーブルのガイドラインを確認する際には、以下の点に留意してください。

  • 一般的に言えば、他の条件がすべて同じであれば、シャードが多い方が並列処理が増えるため、パフォーマンスが向上します。ただし、通常はデータ・ノードが 16 台ほどになるとオーバーヘッドが発生するため、パフォーマンスは低下します。

  • 紹介しているガイドラインは、最小要件ではなく、理想的、または最も効果的な構成を表しています。

    例えば、"シャーディングの効果の評価" に記載しているように、シャーディングによってパフォーマンスが向上するのは、1 つには、シャード化されていない単一インスタンスですべてのデータがキャッシュされるのではなく、複数のシステム間でデータがキャッシュされることによります。定期的に使用されるデータが大きすぎて、シャード化されていないインスタンスのデータベース・キャッシュに収まらない場合、効果が最も大きくなります。ガイドラインに示しているように、最適なパフォーマンスを得るには、クラスタ内の各データ・ノード・インスタンスのデータベース・キャッシュが、シャード・データ作業セットと頻繁に結合されるシャード化されていないデータ作業セットの合計サイズ以上になるようにします。合計キャッシュ・サイズが小さくなると、パフォーマンスが低下します (他の条件がすべて同じである場合)。ただし、すべてのデータ・ノード・キャッシュの合計が、シャード化されていない指定の単一インスタンスのキャッシュ・サイズ以上である限り、シャード・クラスタは、シャード化されていないインスタンスよりも優れたパフォーマンスを発揮します。したがって、例えば、推奨値と等しいデータベース・キャッシュ・メモリをデータ・ノードで割り当てることができない場合は、できる限り近づけてください。さらに、初期見積もりは、実践では調整が必要になることがあります。

  • データベース・キャッシュとは、各インスタンスに対して行う必要があるデータベース・キャッシュ (グローバル・バッファ・プール) のメモリ割り当てを指します。インスタンスのデータベース・キャッシュは、以下のように割り当てることができます。

    • いずれかの自動導入方法を使用する場合、導入の一部として既定の globals 設定をオーバーライドできます。

    • %SYSTEM.Cluster API または管理ポータルを使用して手動で導入する場合は、"メモリと開始設定" で説明されている手動手順を使用できます。

    InterSystems IRIS インスタンスのルーチン・キャッシュとデータベース・キャッシュおよび共有メモリ・ヒープにメモリを割り当てる際のガイドラインは、"共有メモリの割り当て" を参照してください。

  • 既定のグローバル・データベースは、関連するデータベースのターゲット・サイズを示します。これは、予想される最大サイズに、予想を超える増大を見越したマージンを加えたものです。データベースをホストするファイル・システムは、この合計に対応できるサイズでなければなりません。また、安全マージンも確保する必要があります。InterSystems IRIS データベースのサイズと拡張、InterSystems IRIS データベースに対する空き容量の管理、および手動でインスタンスを構成する際のデータベース・サイズやその他特性の指定手順についての一般情報は、"ローカル・データベースの構成" および "ローカル・データベースの管理" を参照してください。

    IKO を使用して導入する場合、インスタンスのデータ用のストレージ・ボリューム・サイズを指定できます。これはマスタ・ネームスペースとクラスタ・ネームスペースの既定のグローバル・データベースが導入の一部として配置される場所です。これは、既定のグローバル・データベースのターゲット・サイズに対応できる十分な大きさである必要があります。

    Important:

    手動で導入する場合、すべてのインスタンスでデータベース・ディレクトリとジャーナル・ディレクトリが個別のストレージ・デバイスに配置されるようにします。これは、大量のデータ取り込みがクエリの実行と同時に行われる場合に特に重要です。ジャーナル・ストレージなど、ファイル・システムおよびストレージの構成のガイドラインについては、"ストレージの計画"、"ファイル・システムの分離"、および "ジャーナリングの最善の使用方法" を参照してください。

  • データ・ノードの数 (NodeCount) と各データ・ノードのデータベース・キャッシュ・サイズは、どちらも変数です。シャードの数と各データ・ノードのデータベース・キャッシュ・サイズを変えることにより、データ・ノードのデータベース・キャッシュ・サイズの合計と合計作業セットの見積もりの間に必要な関係を作成できます。この選択は、システム・コストとメモリ・コストの間のトレードオフなどの要因に基づいて行うことができます。メモリ・リソースが少ない多数のシステムが使用可能な場合は、少量のメモリをデータベース・キャッシュに割り当てることができます。システムごとのメモリが多い場合は、少数のサーバを構成できます。一般的に言えば、他の条件がすべて同じであれば、シャードが多い方が並列処理が増えるため、パフォーマンスが向上します。ただし、ある時点になると、パフォーマンスは低下します (原因の一部は、増加したシャーディング・マネージャのオーバーヘッド)。通常、最も効果的な構成は、シャードが 4 ～ 16 の範囲である場合です。つまり、他の要因を除くと、例えば、8 台のデータ・ノードがあり、それぞれのメモリが M である場合、64 台のシャードがあり、それぞれのメモリが M/8 である場合よりも優れたパフォーマンスを発揮する可能性があります。

  • クラスタにデータがロードされた後にデータ・ノードを追加する必要がある場合は、シャード・データを新しいサーバにわたって自動的に再分散できることに留意してください。これにより、パフォーマンスが最適化されます。詳細は、"データ・ノードの追加とデータの再分散" を参照してください。一方、シャード・データがあるデータ・ノードは削除できず、サーバのシャード・データは自動的に別のデータ・ノードに再分散できません。したがって、プロダクションのクラスタへのデータ・ノードの追加は、データ・ノードの数の削減 (すべてのシャード・テーブルを削除してからデータ・ノードを削除し、データを再ロードする) に比べ、かなり少ない労力ですみます。

  • クエリの並列処理の速度は、最も低速なデータ・ノードと同じ速度にしかなりません。したがって、シャード・クラスタ内のすべてのデータ・ノードの仕様とリソースが同じであるか、少なくともほぼ同等であるようにすることをお勧めします。さらに、クラスタ内のすべての InterSystems IRIS インスタンスの構成が一貫している必要があります。確実に正しい SQL クエリ結果が返されるようにするには、インスタンス・レベルで構成される照合などのデータベース設定やそれらの SQL 設定 (既定の日付形式など) がすべてのノードで同じでなければなりません。標準化された手順や自動導入方法を使用すると、この一貫性を簡単に確保できます。

以下のテーブルの推奨事項は、前述の合計データ・サイズと作業セット・サイズの見積もり手順を、各変数について計算結果に 50% の安全係数を加算することを含め、実行済みであることを前提としています。

クラスタの計画に関するガイドライン

対象

必要な最小サイズ

 注

データ・ノード上のデータベース・キャッシュ

(ShardSizeWS / NodeCount) + NonshardSizeJoinedWS

 この推奨は、アプリケーションで 100% のメモリ内キャッシュを必要としていることを前提としています。代わりにソリッドステート・ドライブなどの高速ストレージから読み取ることのできる範囲によっては、キャッシュのサイズを削減できます。

各データ・ノードのクラスタ・ネームスペースの既定グローバル・データベース

ShardSize / NodeCount に、予想される増大に対応するためのスペースを加えたもの

 データ取り込みのパフォーマンスが重要な考慮事項である場合は、データベースの初期サイズを予想される最大サイズと等しくなるように構成し、自動的なデータベースの拡張によるパフォーマンスの影響を回避することを検討してください。ただし、クラウド環境で実行している場合は、使用していないストレージの支払いによるコスト面での影響も検討する必要があります。

ノード 1 上のマスタ・ネームスペースの既定のグローバル・データベース ("ネームスペースの構成" を参照)

NonshardSizeTotal および、可能であれば、予想される増大に対応するためのスペース

 シャード化されていないデータは、シャード・データに比べ、時間が経ってもあまり増大しない傾向がありますが、もちろんこれは、アプリケーションによります。

各データ・ノード上の IRISTEMP データベース (マスタ・ネームスペースおよびクラスタ・ネームスペース用の一時ストレージ・データベース)

特定のガイドラインはありません。理想的な初期サイズはデータ・セット、作業負荷、およびクエリ構文により異なりますが、おそらく 100 GB を超え、これよりはるかに大きい場合もあります。

 このデータベースは必ず、大幅な拡張に対応できる大きな領域がある、可能な限り最速のストレージに配置してください。T

CPU

具体的な推奨値はありません。

InterSystems IRIS サーバはすべて、シャーディングが含まれるかどうかに関係なく、CPU を増やすことでパフォーマンスが向上します。CPU、メモリ、およびストレージ・リソースの垂直方向の拡張は、常に、シャーディングと組み合わせて使用することでさらに大きな効果をもたらしますが、特に必要ではなく、一般的なコストとパフォーマンスのトレードオフによって制御されます。
Important:

シャード・クラスタ内のすべての InterSystems IRIS インスタンスは、同じバージョンである必要があり、シャーディング・ライセンスを有する必要があります。

シャード・クラスタ内のすべてのデータ・ノードの仕様とリソースが同じであるか、少なくともほぼ同等である必要があります。クエリの並列処理の速度は、最も低速なデータ・ノードと同じ速度にしかなりません。さらに、クラスタ内のすべての InterSystems IRIS インスタンスの構成が一貫している必要があります。確実に正しい SQL クエリ結果が返されるようにするには、インスタンス・レベルで構成される照合などのデータベース設定やそれらの SQL 設定 (既定の日付形式など) がすべてのノードで同じでなければなりません。標準化された手順や自動導入方法を使用すると、この一貫性を簡単に確保できます。

アプリケーションは任意のデータ・ノードのクラスタ・ネームスペースに接続して、全データセットをローカルのものであるかのように利用できるので、一般的なベスト・プラクティスとして、クラスタ内のすべてのデータ・ノード間でアプリケーション接続を負荷分散することをお勧めします。IKO は、一般的なシナリオの場合、必要に応じてデータ・ノードのロード・バランサを自動的にプロビジョニングし、構成します。他の手段でシャード・クラスタを導入する場合は負荷分散メカニズムが必要となります。複数のデータ・ノードにわたってアプリケーション接続を分散する Web サーバ層の負荷分散に関する重要な説明は、"負荷分散、フェイルオーバー、ミラー構成" を参照してください。

クラスタのパフォーマンスを最大限に発揮させるためのベスト・プラクティスは、すべてのデータ・ノード間に低遅延のネットワーク接続を構成することです。例えば、すべてのデータ・ノードを同じデータ・センターまたはアベイラビリティ・ゾーン内の同じサブネットに配置します。

計算ノードの計画

"InterSystems IRIS のシャーディングの概要" に記載されているように、計算ノードがデータ・ノードに格納されているデータをキャッシュし、自動的に読み取り専用クエリを処理する一方、すべての書き込み操作 (挿入、更新、削除、および DDL 操作) はデータ・ノードで実行されます。計算ノードをクラスタに追加することで効果が得られる可能性が最も高いシナリオは、以下のとおりです。

  • 大量のデータ取り込みが大量のクエリの実行と同時に行われる場合、データ・ノードあたり 1 つの計算ノードにすると、データ取り込みの作業負荷 (データ・ノード) からクエリの作業負荷 (計算ノード) が分離され、パフォーマンスが向上します。

  • 多数のユーザによる大量のクエリがパフォーマンス低下の重大な要因である場合、データ・ノードあたり複数の計算ノードとすることで、基盤となる各データ・ノード上のデータに対して複数の同時シャード・クエリを実行できるようになり、全体的なクエリのスループット (および結果としてパフォーマンス) が向上します (一度に 1 つずつ、個別のシャード・クエリを実行する際のパフォーマンスは、計算ノードが複数になっても向上しません。多数のユーザによるクエリの作業負荷が関与しない限り、これは有益ではないためです)。計算ノードが複数あると、1 つの計算ノードに障害が発生した場合に、そのデータ・ノードに割り当てられた残りの計算ノードでクエリを処理できるため、作業負荷の分離を維持することもできます。

計算ノードを計画する際は、以下の要素について検討します。

  • 計算ノードの導入を検討する場合、一般的には、基本的なシャード・クラスタの動作を評価してから、クラスタにとって計算ノードの追加が有益であるかどうかを決定することをお勧めします。計算ノードは、"クラスタの自動導入方法" で説明されている自動導入方法の 1 つを使用するか、%SYSTEM.Cluster API を使用して、既存のクラスタに簡単に追加できます。計算ノードの追加の詳細は、"作業負荷の分離とクエリ・スループットの向上のための計算ノードの導入" を参照してください。

  • 最適なパフォーマンスを得るには、クラスタの計算ノードをデータ・ノードと同じ場所 (つまり、同じデータ・センターまたはアベイラビリティ・ゾーン内) に配置して、ネットワーク遅延を最小化する必要があります。

  • 計算ノードがクラスタに追加されると、これらはデータ・ノード間でできる限り均等に自動分散されます。計算ノードを追加することによってパフォーマンスが大幅に向上するのは、データ・ノードごとに計算ノードが少なくとも 1 つある場合のみであることに注意してください

  • 各データ・ノードに同じ数の計算ノードを割り当てることをお勧めします。したがって、例えば 8 つのデータ・ノードを計画している場合、計算ノード数の推奨選択肢には、0、8、16 などが含まれます。

  • 計算ノードではクエリの実行のみがサポートされ、データは格納されないので、メモリと CPU を重視し、ストレージを最小限に抑えるなど、ニーズに合わせてハードウェア・プロファイルを調整できます。シャード・クラスタ内のすべての計算ノードの仕様とリソースは、ほぼ同等である必要があります。

  • 計算ノードに対し、データ・ノードのデータベース・キャッシュ・サイズの推奨事項 ("データ・ノードの基本的なクラスタの計画" を参照) に従います。各計算ノードが、割り当てられているデータ・ノードと同じサイズのデータベース・キャッシュを持つのが理想的です。

データ・ノードと計算ノードの区別は、アプリケーションに対して完全に透過的です。アプリケーションは任意のノードのクラスタ・ネームスペースに接続して、全データセットをローカルのものであるかのように利用できます。したがって、アプリケーションの接続は、クラスタ内のすべてのデータ・ノードおよび計算ノードで負荷分散でき、ほとんどのアプリケーション・シナリオで、これが最も効果的なアプローチです。特定のシナリオで実際に何が最適であるかは、クエリの処理とデータの取り込みのどちらを最適化したいのかにより異なります。シャード・クエリが最も重要である場合は、計算ノードのリソースについて、アプリケーションがシャードローカル・クエリと競合しないように、データ・ノード間で負荷分散することにより、シャード・クエリを優先させることができます。並列ロードを使用した高速取り込みが最も重要である場合は、計算ノード間で負荷分散することで、データ・ノードでのアプリケーション・アクティビティを回避できます。クエリとデータ取り込みが同じように重要である場合、またはそれらを組み合わせた状態が予測できない場合は、すべてのノードで負荷分散します。

IKO では、データ・ノードまたは計算ノードの定義に自動的にロード・バランサを追加できます。また、独自の負荷分散配置を作成することもできます。複数のデータ・ノードにわたってアプリケーション接続を分散する Web サーバ層の負荷分散に関する重要な説明は、"負荷分散、フェイルオーバー、ミラー構成" を参照してください。

シャード・クラスタの調整されたバックアップとリストア

InterSystems IRIS シャード・クラスタの場合のように、複数のシステムにわたってデータを分散する場合、バックアップおよびリストアの手順で複雑さが増す可能性があります。シャード・クラスタ間のデータの厳格な整合性が必要な場合、個々のノードを個別にバックアップしてリストアすることでは不十分です。バックアップすべてが、論理的な同じ時点で作成されているとは限らないからです。これにより、障害の後にクラスタ全体をリストアする際に、確実に順序を保持し、それによってリストアしたデータベースの論理整合性を確保することは不可能になります。

例えば、データ・ノード S1 上のデータの更新 A が、データ・ノード S2 上のデータの更新 B より前に実行されたとします。バックアップからのクラスタのリストアの後に、論理整合性では、更新 B が認識可能であれば、更新 A も認識可能である必要があります。ところが、S1 と S2 のバックアップが個別に実行されると、S2 のバックアップが B のコミット後に行われても、S1 のバックアップが A のコミット後に行われたことを保証するのは不可能です。したがって、バックアップを個別にリストアすると、S1 と S2 が互いに不整合になる可能性があります。

一方、使用した手順でバックアップまたはリストアを調整して、すべてのシステムが論理的な同じ時点 (ここでは、更新 B の後) にリストアされることを確実にすると、順序が保持されて、その順序に依存する論理整合性が確保されます。これは、調整されたバックアップおよびリストアの手順の目標です。

ここで説明したシャード・クラスタのリストアのいずれかの手順を使用しなければならなくなる可能性を大幅に小さくするために、"ミラーによる高可用性" で説明しているように、ミラーリングされたデータ・サーバを使用してシャード・クラスタを導入できます。クラスタがミラーリングされていない場合でも、ほとんどのデータ・エラー (例えば、データ破損やデータの誤った削除) は、エラーが発生したデータ・ノードを最新のバックアップからリストアし、そのジャーナル・ファイルを使用して現在の論理的な時点に回復することで修正できます。ここで説明した手順は、クラスタ全体のリストアが必要なきわめてまれな状況で使用するものです。

このセクションでは、以下のトピックについて説明します。

シャード・クラスタの調整されたバックアップとリストアのアプローチ

シャード・クラスタの調整されたバックアップとリストアには、常にクラスタ内のすべてのデータ・ノードが関係します。InterSystems IRIS バックアップ API には、クラスタのデータ・ノードの調整されたバックアップとリストアを行う 3 種類のアプローチをサポートする Backup.ShardedClusterOpens in a new tab クラスが含まれます。

すべてのアプローチの目標が、すべてのデータ・サーバを同じ論理的な時点にリストアすることであり、それを行う方法が異なるだけです。1 つのアプローチでは、論理的な時点を共有するのはバックアップ自体ですが、それ以外のアプローチでは、InterSystems IRIS データベース・ジャーナリングが共通の論理的な時点を提供します。これはジャーナル・チェックポイントと呼ばれ、ここにデータベースがリストアされます。以下のようなアプローチがあります。

  • 調整されたバックアップ

  • 調整されていないバックアップの後の、調整されたジャーナル・チェックポイント

  • 調整されていないバックアップに含まれる調整されたジャーナル・チェックポイント

これらのアプローチが機能するしくみを理解するには、InterSystems IRIS データ整合性とクラッシュ回復の基本を理解することが重要です。これについては、"データ整合性の概要" で説明されています。データベース・ジャーナリングは、データ整合性および回復の重要な機能であり、特にこのトピックでは大きな影響があります。ジャーナリングでは、インスタンスのデータベースに加えられたすべての更新がジャーナル・ファイルに記録されます。これによって、バックアップが作成された時点から障害が発生した時点 (または別の選択した時点) までの間に加えられた更新を回復できるようになります。これは、バックアップからのリストアの後にジャーナル・ファイルから更新をリストアすることで実行できます。ジャーナル・ファイルは、トランザクション整合性の確保にも使用され、障害によって開いたままになっているトランザクションをロールバックすることで実現されます。ジャーナリングの詳細は、"ジャーナリングの概要" を参照してください。

調整されたバックアップとリストアのアプローチを選択する際の考慮事項は、以下のとおりです。

  • アクティビティがバックアップ手順によって中断される度合い

  • 十分な復元可能性を保証するために必要な、バックアップ手順の実行頻度

  • 必要なリストア手順の複雑さ

これらの問題の詳細は、このセクションで後述します。

API 呼び出しの調整されたバックアップとリストア

Backup.ShardedClusterOpens in a new tab クラス内のメソッドは、任意のデータ・ノードで呼び出すことができます。メソッドのすべてが ShardMasterNamespace 引数を取ります。これは、クラスタ内のすべてのノードからアクセスできる、データ・ノード 1 上のマスタ・ネームスペースの名前 (既定では IRISDM) です。

使用できるメソッドは以下のとおりです。

  • Backup.ShardedCluster.Quiesce() Opens in a new tab

    シャード・クラスタのすべてのデータ・ノード上のすべてのアクティビティをブロックし、保留中の書き込みすべてがディスクにフラッシュされるまで待機します。Quiesce() の下に作成される、クラスタのデータ・ノードのバックアップは、論理的な時点を表します。

  • Backup.ShardedCluster.Resume()Opens in a new tab

    Quiesce() によって一時停止されているデータ・ノードで、アクティビティを再開します。

  • Backup.ShardedCluster.JournalCheckpoint()Opens in a new tab

    調整されたジャーナル・チェックポイントを作成し、各データ・ノードを新しいジャーナル・ファイルに切り替えた後、チェックポイント番号とプリチェックポイント・ジャーナル・ファイルの名前を返します。プリチェックポイント・ファイルは、リストアに含める必要のある各データ・ノード上の最後のジャーナル・ファイルです。この後のジャーナル・ファイルには、チェックポイントで表される論理的な時点の後に生じたデータが含まれます。

  • Backup.ShardedCluster.ExternalFreezeOpens in a new tab

    クラスタ全体の物理的なデータベース書き込みを凍結しますが、アプリケーションのアクティビティは凍結しません。その後、調整されたジャーナル・チェックポイントを作成し、各データ・ノードを新しいジャーナル・ファイルに切り替え、チェックポイント番号とプリチェックポイント・ジャーナル・ファイルの名前を返します。ExternalFreeze() の下に作成されたバックアップは、論理的な時点を表しませんが、プリチェックポイント・ジャーナル・ファイルが含まれているため、チェックポイントによって表される論理的な時点にリストアできます。

  • Backup.ShardedCluster.ExternalThawOpens in a new tab

    ExternalFreeze() によって一時停止されているディスク書き込みを再開します。

これらの呼び出しの技術情報に関するドキュメントについては、"インターシステムズ・クラス・リファレンス" を参照してください。

調整されたバックアップとリストアの手順

調整されたバックアップとリストアの 3 種類のアプローチに含まれる、シャーディング API を使用した手順については、以下のセクションで説明しています。

データ・ノードのバックアップには通常、データベース・ファイルだけでなく、InterSystems IRIS で使用されるすべてのファイル (ジャーナル・ディレクトリ、ライト・イメージ・ジャーナル、インストール・データ・ディレクトリなど) および必要な外部ファイルを含める必要があります。これらのファイルの場所は、一部にはクラスタの導入状況によって異なります ("シャード・クラスタの導入" を参照)。バックアップにこれらのファイルを含めるために必要な手法が、アプローチの選択に関わってくる可能性があります。

Important:

ここで説明しているリストア手順では、リストア対象のデータ・ノードに使用可能なミラー・フェイルオーバー・パートナーがなく、災害復旧の状況でのみ、ミラーリングされたデータ・ノードで使用することが前提となっています。"ミラーリングされたシャード・クラスタの災害復旧"、および "災害復旧の手順" を参照してください。データ・ノードがミラーリングされている場合は、ミラーからプライマリを削除し、説明しているリストア手順を完了してから、"ミラー・メンバの再構築" で説明されているようにミラー・メンバとして再構築します。

調整されたバックアップの作成

  1. Backup.ShardedCluster.QuiesceOpens in a new tab を呼び出して、クラスタ内のすべてのデータ・ノード上のアクティビティ (およびこれによってすべてのアプリケーション・アクティビティ) を一時停止して、保留中のすべての書き込みがディスクにフラッシュされるまで待機します。このプロセスが完了して呼び出しが値を返すと、クラスタ内のすべてのデータベースおよびジャーナル・ファイルが論理的な同じ時点になります。

  2. クラスタ内のすべてのデータ・ノードのバックアップを作成します。データベースのバックアップは調整されますが、開いているトランザクションが含まれる可能性があります。データ・ノードがバックアップからリストアされた後で再起動されると、InterSystems IRIS のリカバリではジャーナル・ファイルを使用して、これらのトランザクションをロールバックすることで、トランザクションの整合性をリストアします。

  3. バックアップが完了したら、Backup.ShardedCluster.ResumeOpens in a new tab を呼び出して、データ・ノードの通常の動作をリストアします。

    Important:

    Resume() は、Quiesce() を呼び出したものと同じジョブ内で呼び出す必要があります。失敗の返り値は、Quiesce() の下に作成したバックアップ・イメージの信頼性が低く、このイメージの破棄が必要な可能性があることを示します。

  4. 失敗の後に、各データ・ノードで以下の操作を行います。

    1. バックアップ・イメージをリストアします。

    2. 存在するジャーナル・ファイルは、バックアップの作成時点からリストアしたイメージに含まれるものだけであることを確認します。

      Caution:

      これはきわめて重要です。起動時に、リカバリによってジャーナル・ファイルがリストアされ、バックアップの作成時点で開いていたトランザクションがすべてロールバックされるからです。バックアップの作成時点より後のジャーナル・データが起動時に存在する場合、そのジャーナル・データがリストアされ、対象のデータ・ノードが他のデータ・サーバと不整合になる可能性があります。

    3. 対象のデータ・ノードを再起動します。

    このデータ・ノードは、データベースのアクティビティが停止された論理的な時点にリストアされます。

Note:

この最初の 3 つの手順の代替方法として、クラスタ内のすべてのデータ・ノードを適切にシャットダウンして、コールド・バックアップを作成し、すべてのデータ・ノードを再起動することができます。

調整されていないバックアップの作成後の、調整されたジャーナル・チェックポイント

  1. クラスタ内のすべてのデータ・ノードが動作中で、アプリケーション・アクティビティが続行している間に、これらのデータ・ノード上のデータベースのバックアップを作成します。これらのバックアップは、選択した任意の方法を使用して、選択した任意の間隔で、まったく異なる時点で作成できます。

  2. Backup.ShardedCluster.JournalCheckpoint()Opens in a new tab を定期的に (スケジュールされたタスクとすることを推奨) 呼び出します。このメソッドは、調整されたジャーナル・チェックポイントを作成し、そのチェックポイントに達するために各データ・ノード上のリストアに含める最新のジャーナル・ファイルの名前を返します。データ・ノードを回復できる論理的な時点を指示するのは、バックアップのタイミングではなく、最新のチェックポイントの時点とプリチェックポイント・ジャーナル・ファイルの可用性であることに留意してください。

    Note:

    ジャーナル・ファイルを切り替える前に、JournalCheckpoint() は、シャード・クラスタ内のすべてのデータ・ノードを短時間停止して、プリチェックポイント・ファイルすべてが論理的な同じ時点で終了するようにします。この結果、アプリケーション・アクティビティがこのメソッドの実行中にきわめて短い時間一時停止する可能性があります。

  3. データ・ノードごとにジャーナル・ファイルの完全セットを必ず格納します。このセットには、最後のバックアップ時点から最新の調整されたジャーナル・チェックポイントの作成時点までのジャーナル・ファイルを格納し、最後がプリチェックポイント・ジャーナル・ファイルになります。また、これらのファイルすべてがサーバ障害発生後も必ず使用可能な状態にします (ジャーナル・ファイルを定期的にバックアップすることで実現する可能性が高い)。データベースのバックアップが調整されることはなく、部分トランザクションが存在する可能性もありますが、データ・ノードはバックアップからのリストア後に再起動され、調整されたジャーナル・ファイルをリカバリで使用して、すべてのデータベースを論理的な同じ時点にして、トランザクションの整合性をリストアします。

  4. 障害発生後に、すべてのデータ・ノードに共通のリストア・ポイントとして利用可能な最新のチェックポイントを識別します。このためには、各データ・ノードに、最新のチェックポイントより前に作成されたデータベース・バックアップと、プリチェックポイント・ジャーナル・ファイルまでの途中のジャーナル・ファイルすべてが格納されている必要があります。

    Caution:

    これはきわめて重要です。起動時に、リカバリによってジャーナル・ファイルがリストアされ、バックアップの作成時点で開いていたトランザクションがすべてロールバックされるからです。プリチェックポイント・ジャーナル・ファイルより後のジャーナル・ファイルが起動時に存在する場合、それらのジャーナル・ファイルがリストアされ、対象のデータ・ノードが他のデータ・サーバと不整合になる可能性があります。

  5. 各データ・ノードで、チェックポイントより前のバックアップからデータベースをリストアし、ジャーナル・ファイルをチェックポイントまでリストアします。このチェックポイントの後のジャーナル・データが適用されることのないようにします。これを確実にする簡単な方法は、チェックポイントより後のジャーナル・ファイルがサーバに存在するかどうかを確認し、存在する場合はそれを移動または削除してから、ジャーナル・ログを削除することです。

    これで、調整されたジャーナル・チェックポイントが作成された論理的な時点にデータ・ノードがリストアされます。

調整されていないバックアップへの調整されたジャーナル・チェックポイントの追加

  1. Backup.ShardedCluster.ExternalFreeze()Opens in a new tab を呼び出します。このメソッドは、シャード・クラスタ内のすべてのデータ・ノードのライト・デーモンを一時停止することで、それらのデータ・サーバ上のすべてのアクティビティを凍結します。アプリケーション・アクティビティは続行しますが、更新はジャーナル・ファイルだけに書き込まれ、ディスクにはコミットされません。このメソッドは、値を返す前に、調整されたジャーナル・チェックポイントを作成し、各データ・ノードを新しいジャーナル・ファイルに切り替えた後、チェックポイント番号とプリチェックポイント・ジャーナル・ファイルの名前を返します。この時点で、プリチェックポイント・ジャーナル・ファイルは、単一の論理的な時点を表します。

    Note:

    Backup.ShardedCluster.ExternalFreeze()Opens in a new tab は内部的に Backup.ShardedCluster.JournalCheckpoint()Opens in a new tab を呼び出します。その結果、Backup.ShardedCluster.Quiesce()Opens in a new tab と Backup.ShardedCluster.Resume()Opens in a new tab が呼び出されてジャーナル・ファイルが切り替わる間、システムが短時間停止します。Resume() の実行が完了すると、Backup.ShardedCluster.Resume: System resumed メッセージがログに記録されます。これによってシステムが凍結しなくなるわけではなく、停止しなくなるにすぎません。ExternalFreeze() を呼び出すと、Backup.ShardedCluster.ExternalThaw()Opens in a new tab を呼び出すまでシステムは凍結した状態になります。

  2. クラスタ内のすべてのデータ・ノードのバックアップを作成します。データベースのバックアップが調整されることはなく、部分トランザクションが存在する可能性もありますが、データ・ノードをリストアする際に必ず実行することは、データ・サーバをジャーナル・チェックポイントに回復し、すべてのデータベースを論理的な同じ時点にして、トランザクションの整合性をリストアすることです。

    Note:

    Backup.ShardedCluster.ExternalFreeze()Opens in a new tab によってライト・デーモンが既定で 10 分間一時停止すると、アプリケーションのプロセスが以降の更新が行われないようブロックされます (ジャーナル・バッファがいっぱいになるリスクがあるため)。ただし、バックアップ・プロセスにもっと時間が必要な場合は、ExternalFreeze() のオプションの引数を使用してこの時間を延長できます。

  3. すべてのバックアップが完了したら、Backup.ShardedCluster.ExternalThaw()Opens in a new tab を呼び出して、ライト・デーモンを再開し、データ・ノードの通常の動作をリストアします。

    Important:

    失敗の返り値は、ExternalFreeze() の下に作成したバックアップ・イメージの信頼性が低く、このイメージの破棄が必要な可能性があることを示します。

  4. 失敗の後に、各データ・ノードで以下の操作を行います。

    1. バックアップ・イメージをリストアします。

    2. リストアされたイメージに、ExternalFreeze() から返されたプリチェックポイント・ジャーナル・ファイルより後のジャーナル・ファイルが存在する場合は、それらをすべて削除します。

    3. InterSystems IRIS インスタンスを手動で回復するには、"自動 WIJ およびジャーナル・リカバリを使用しない InterSystems IRIS の起動" の手順に従います。ジャーナル・ファイルをリストアする場合、ExternalFreeze() によって切り替えられたジャーナル・ファイルから開始し、ExternalFreeze() によって返されたプリチェックポイント・ジャーナル・ファイルを最後にします (これらが同一のファイルである可能性があります。この場合、これがリストア対象の唯一のジャーナル・ファイルです)。

      Note:

      コンテナ化された InterSystems IRIS インスタンスを使用して作業している場合、コンテナ内で手動リカバリを実行する手順については、"InterSystems IRIS コンテナのアップグレード" を参照してください。

    調整されたジャーナル・チェックポイントが ExternalFreeze() メソッドによって作成された論理的な時点に、データ・ノードがリストアされます。

Note:

このアプローチでは、各データ・ノード上のデータベースとジャーナル・ファイルを、単一のバックアップにこれら両方を含めることができるように配置する必要があります。

ミラーリングされたシャード・クラスタの災害復旧

災害復旧 (DR) 非同期は、ミラーリングされたデータベースの同期された同じコピーをバックアップ・フェイルオーバー・メンバとして維持します。違いは、非同期とそのプライマリ間の通信が非同期であること、および非同期は自動フェイルオーバーに参加しないことです。ただし、フェイルオーバー・メンバの 1 つが利用できなくなった場合、DR 非同期をフェイルオーバー・メンバに昇格させてバックアップにすることができます。例えば、バックアップでメンテナンスを実行する場合や、プライマリの停止によってミラーがバックアップにフェイルオーバーしたときに、以前のプライマリの問題を調査・修正する一方で自動フェイルオーバー機能を維持しなければならない場合などです。重大な障害によって両方のフェイルオーバー・メンバの停止が発生した場合、昇格させた DR 非同期に手動でフェイルオーバーして災害復旧を行うことができます。

DR 非同期ミラー・メンバを使用すると、ミラーリングされたシャード・クラスタに災害復旧オプションを提供することが可能になり、ミラー・フェイルオーバー・ペアの停止後に比較的短時間でクラスタの動作を復旧できます。ミラーリングされたクラスタの災害復旧を可能にする場合、具体的には以下を行います。

  • ミラーリングされたシャード・クラスタ内のすべてのデータ・ノード・ミラーで DR 非同期を少なくとも 1 つ構成します。

    重大な障害によってフェイルオーバー・ペアの停止が発生した場合に DR 非同期を確実に利用可能に維持するため、DR 非同期は通常、フェイルオーバー・ペアとは別のデータ・センターまたはアベイラビリティ・ゾーンに配置します。災害復旧手順で手動によってフェイルオーバーする先の DR 非同期が複数の場所に分散されている場合、DR 非同期間のネットワーク遅延がクラスタのパフォーマンスに大きな影響を及ぼす可能性があります。このため、ベスト・プラクティスとして、クラスタ内のすべてのデータ・ノード・ミラーに、共通の場所にある DR 非同期を少なくとも 1 つ含めます。

    Important:

    災害復旧実現の一環として (または他の理由で) 既存のミラーリングされたクラスタ内のデータ・ノードに DR 非同期を追加する場合や、バックアップ・メンバを DR 非同期に降格させる場合は、いずれかのミラー・プライマリのクラスタ・ネームスペースで $SYSTEM.Sharding.VerifyShards()Opens in a new tab を呼び出してクラスタのメタデータを更新し、追加を反映させる必要があります。

  • 前のセクションの説明に従って、調整されたバックアップを定期的に作成します。

    バックアップによってクラスタの動作がどの程度中断するか、バックアップの実行頻度、およびリストア手順の複雑さはすべて、選択した、調整されたバックアップとリストアのアプローチによって変わるため、アプローチを確認して、自身の状況と災害復旧の目標 (許容できるデータ損失の量、クラスタの動作をリストアする必要がある速度など) に最も適したアプローチを決定する必要があります。

  • 必要な災害復旧手順 (選択した調整されたバックアップ手順について説明されているリストア手順を含む) を計画、準備、およびテストし、"災害復旧の手順" で説明されている手順を十分に理解します。

必要な DR 非同期を構成済みで、調整されたバックアップを定期的に作成していることを前提とした場合、ミラーリングされたシャード・クラスタの一般的な災害復旧手順は以下のようになります。

  1. 各データ・ノード・ミラーで以下を実行します。

  2. "調整されたバックアップとリストアの手順" の該当セクションで説明されているように、選択した調整されたバックアップとリストアのアプローチについて説明されている手順を使用して、最新の調整されたバックアップをリストアします。

  3. フェイルオーバー機能をクラスタにリストアするために、各ミラーでフェイルオーバー・ペアを完成させます。データ・ノード・ミラーすべてに複数の DR 非同期が含まれていた場合、それぞれで別の DR 非同期をフェイルオーバー・メンバに昇格させます。ミラーに追加の DR 非同期がない場合は、"ミラー・データ・ノードによる高可用性" の説明に従って、各ミラーに 2 つ目のフェイルオーバー・メンバを構成します。

  4. シャード・クラスタへのアプリケーション・アクセスをリストアします。

Note:

回復したミラーリングされたシャード・クラスタに計算ノードが含まれていた場合、これらの計算ノードはほぼ確実にデータ・ノードのフェイルオーバー・ペアと同じ場所に配置されており、障害によって利用できなくなっています。この場合、クラスタの完全なリカバリを行うには、"作業負荷の分離とクエリ・スループットの向上のための計算ノードの導入" の説明に従って、回復したクラスタと同じ場所に配置された新しい計算ノードを導入して、ネットワーク遅延を最小化することが含まれます。クラスタの既存の計算ノードがまだ元の場所で動作している場合は、できる限り速やかにそれらの計算ノードをクラスタの新しい場所に再配置する必要があります。回復したクラスタは計算ノードなしでも動作可能ですが、計算ノードが提供する利点を利用することはできません。

シャード・クラスタの複製

現在のホストとは別の複数のホストに既存のクラスタを複製することが必要になる場合があります。その状況の例を以下に挙げます。

  • プロダクション・クラスタのスナップショットに基づくテスト・システムを準備する。

  • 既存ホストの一部またはすべてが使用できなくなる障害が発生した後、新しいホストにバックアップからクラスタを復元する。

  • 現在とは別のデータ・センターなどの新しい場所にクラスタを移動する。

ここでは、新しいホストに既存のクラスタを複製して、上記のタスクまたは類似のタスクを達成できるようにする手順を説明します。

シャード・クラスタは、複数のマッピングと通信チャンネルを通じて連携するように構成したノードとネームスペースから成ります。この構成に関する情報は、データ・ノード 1 のマスタ・ネームスペース (または、ネームスペースレベル・クラスタのシャード・マスタ) に保存されて維持されます。この情報として、具体的なホスト名、ポート番号、ネームスペースなどがあります。クラスタを複製するには、この構成を新しいクラスタ上に複製する必要があります。

Note:

複製元の既存クラスタと複製先の新規クラスタでデータ・ノードの数が同じ場合にのみ、この手順を使用できます。

この複製プロセスには SYSTEM.Sharding API 呼び出しが関わっているので、複製されたクラスタは必ずネームスペースレベル・クラスタになります。このクラスタの管理と変更は、%SYSTEM.Sharding API および管理ポータルのネームスペース・レベルのページでのみ可能です。

この手順は、ホストあたりのノードが 1 つであることを想定していますが、ホストあたり複数のノードがあるネームスペースレベル・クラスタで使用できるように変更することもできます。

シャード・クラスタを複製するには以下の手順に従います。

  1. 複製先クラスタのデータ・ノード・ホストをプロビジョニングまたは特定し、そのホストに InterSystems IRIS を導入します。管理ポータルまたは $SYSTEM.Sharding.EnableSharding API 呼び出しを使用してシャードを有効にします。

  2. 複製元クラスタのデータ・ノード 1 にあるマスタ・ネームスペースで $SYSTEM.Sharding.GetConfig()Opens in a new tab を呼び出して、ノード 1 にあるマスタ・ネームスペースの既定のグローバル・データベースの場所と、各データ・ノードにあるシャード・ネームスペースの既定のグローバル・データベースの場所を表示します。新しいクラスタでは、元のクラスタのノードに対応するノードにこれらのデータベースを複製する必要があるので、必ず情報を正確に記録します。マスタ・ネームスペースで既定のルーチン・データベースとグローバル・データベースが異なる場合は、その情報も記録します。

    GetConfig() の出力には、各データ・ノードのシャード番号が記述されています。複製先のデータ・ノードを構成するには、複製元でそれに対応するデータ・ノードのシャード番号が必要です。複製元クラスタのシャード番号を複製先クラスタの各ホストに割り当てることによって、複製先ノードと複製元ノードとの対応関係を指定します。

  3. 複製元クラスタへのアプリケーションのアクセスをブロックします。すべての書き込みをディスクにフラッシュした後、複製元クラスタにある InterSystems IRIS のすべてのインスタンスを 1 つずつシャット・ダウンします。

  4. 複製先クラスタ上に複製元クラスタのグローバル・データベースを複製します (必要に応じて、マスタのルーチン・データベースも複製します)。この作業には以下の 2 つの方法のいずれかを使用します。

    • 複製元クラスタでデータベースをバックアップし、それを複製先クラスタに復元する。

    • 複製元クラスタから複製先クラスタに IRIS.DAT ファイルをコピーする。

    この 2 つのクラスタでディレクトリ・パスを同じにする必要はありません。どちらの方法を使用する場合でも、必ず複製元のシャード番号に対応する複製先クラスタ・ノード上に各データベースを複製します。

    Note:

    複製元クラスタをミラーリングしている場合は、各ノードのいずれか 1 つのフェイルオーバー・メンバのみからデータベースをバックアップまたはコピーするだけですみます。

  5. 複製先クラスタの各ノードでシャード・ネームスペースを作成し、複製したシャード・データベースをそのネームスペースの既定のグローバル・データベースとします。ノード 1 で、マスタ・ネームスペースに対して上記と同じ手順を実行します。ルーチン・データベースとグローバル・データベースが異なる場合はルーチン・データベースを追加します。

  6. 複製先クラスタのノード 1 にあるマスタ・ネームスペースで以下の手順に従います。

    1. 複製先データ・ノートごとに $SYSTEM.Sharding.ReassignShard()Opens in a new tab を 1 回ずつ呼び出し、それぞれのホスト名または IP アドレス、スーパーサーバ・ポート、シャード・ネームスペース、シャード番号を指定します。複製元クラスタに対応する正しいシャード番号を指定します。以下に例を挙げます。

      set status = $SYSTEM.Sharding.ReassignShard(,"shard-host",shard-port,"shard-namespace","shard-number")

    2. $SYSTEM.Sharding.Reinitialize()Opens in a new tab を呼び出します。これによって、複製先クラスタのバージョンに互換性があることが確認され、複製先クラスタの有効化に必要なマッピング、ECP 接続、メタデータがすべて設定されます。$SYSTEM.Sharding.VerifyShards()Opens in a new tab が自動的に呼び出されて、クラスタが有効になり、構成が正しいことが確認されます。

      複製先クラスタに複製したグローバル・データベースとルーチン・データベース以外のデータベースに対して、ユーザ定義のグローバル、ルーチン、またはパッケージのマッピングがマスタ・ネームスペースにあると、Reinitialize() からエラーが返されます。新しいクラスタにはこのような追加のデータベースが存在しないからです。このエラーを回避するには、Reinitialize() を呼び出すときの 2 番目の引数 IgnoreMappings に、以下のように 1 を指定します。

      set status = $SYSTEM.Sharding.Reinitialize(,1)

      Reinitialize() 呼び出しの後、グローバル・データベースとルーチン・データベースを複製したときと同様に、関連する追加のデータベースを複製先ノード 1 に複製します。これらのデータベースをすべて用意した段階で $SYSTEM.Sharding.VerifyShards()Opens in a new tab を呼び出し、関連するマッピングをシャード・ネームスペースに適用します。

  7. 必要に応じて、複製したクラスタをミラーリングに変換し、計算ノードを追加します。

シャーディング API

このリリースで、InterSystems IRIS は、シャード・クラスタの構成および管理に使用できる 2 つの API を用意しています。

%SYSTEM.Cluster API

%SYSTEM.Cluster API メソッドおよびそれらを呼び出す手順の詳細は、"インターシステムズ・クラス・リファレンス" の "%SYSTEM.ClusterOpens in a new tab" クラス・ドキュメントを参照してください。

%SYSTEM.ClusterOpens in a new tab API メソッドを以下の要領で使用します。

%SYSTEM.Cluster メソッドには以下のようなものがあります。メソッドの名前をクリックすると、そのクラス・リファレンス・エントリが開きます。

%SYSTEM.Sharding API

%SYSTEM.Sharding API メソッドおよびそれらを呼び出す手順の詳細は、"インターシステムズ・クラス・リファレンス" の "%SYSTEM.ShardingOpens in a new tab" クラス・ドキュメントを参照してください。

%SYSTEM.ShardingOpens in a new tab API メソッドを以下の要領で使用します。

%SYSTEM.Sharding メソッドには以下のようなものがあります。メソッドの名前をクリックすると、そのクラス・リファレンス・エントリが開きます。

ネームスペース・レベル・アーキテクチャの導入

管理ポータルまたは %SYSTEM.ShardingOpens in a new tab API を使用して、シャード・マスタ、シャード・データ・サーバ、およびオプションのクエリ・サーバで構成される、古いネームスペース・レベル・アーキテクチャで InterSystems IRIS シャード・クラスタを導入するには、このセクションの手順を使用します。これらの手順は、各 InterSystems IRIS インスタンスを独自のシステムにインストールすることを前提としています。

アプリケーションは任意のシャード・データ・サーバのクラスタ・ネームスペースに接続して、全データセットをローカルのものであるかのように利用できるので、シャード・クエリ・サーバを含まないネームスペース・レベルのクラスタの一般的な推奨ベスト・プラクティスは、すべてのシャード・データ・サーバ間でアプリケーション接続を負荷分散することです。一般的に、これはシャード・クエリ・サーバを含むクラスタにも最適なアプローチですが、追加の考慮事項があります。詳細は、"計算ノードの計画" の末尾を参照してください。

ノード・レベルのクラスタのノード・レベルの導入と異なり、ネームスペース・レベルの導入では、クラスタ構成の一部としてミラーを作成することはできません。ただし、ミラーリングされたシャード・クラスタ (つまり、ミラーリングされたシャード・マスタ・データ・サーバとミラーリングされたシャード・データ・サーバで構成) を導入する場合は、以下のどれでも実行できます。

  • 既存のミラーのプライマリをシャード・マスタ・データ・サーバとして構成し、最初に対象のマスタ・ネームスペースのグローバル・データベースをミラーに追加する。

  • 既存のシャード・マスタ・データ・サーバをプライマリとして含むミラーを作成し、バックアップを追加する前に、マスタ・ネームスペースのグローバル・データベースをミラーに追加する。

  • 既存のミラーのフェイルオーバー・メンバをシャード・マスタ・データ・サーバとして割り当て、最初に対象のクラスタ・ネームスペースのグローバル・データベースをミラーに追加する。

  • 割り当てたシャード・データ・サーバをプライマリとして含むミラーを作成し、シャード・ネームスペースのグローバル・データベースをミラーに追加してから、バックアップに関する情報を指定して、ミラーリングされたシャード・データ・サーバとして再割り当てする。

ミラーリングされたシャード・クラスタに DR 非同期を含めることはできますが、レポート非同期を含めることはできません。推奨されるベスト・プラクティスは、ミラーリングされたノードとミラーリングされていないノードを混在させないようにすることです。つまり、シャード・マスタとすべてのシャード・データ・サーバをミラーリングするか、いずれもミラーリングしないようにしてください。これらの手順のステップを以下に示します。このステップは、ミラーリングされたクラスタを導入する場合にも、ミラーリングされていないクラスタを導入する場合にも使用できます。

インフラストラクチャのプロビジョニングまたは特定

必要なネットワーク・ホスト・システム (物理、仮想、またはクラウド) の数を特定します (シャード・マスタおよびシャード・データ・サーバについてそれぞれ 1 つのホスト)。

ミラー・クラスタを導入する場合は、シャード・マスタ・データ・サーバ用に 2 つのホストと、各シャード・データ・サーバ用に 2 つ以上のホスト (DR 非同期メンバが必要かどうかによる) をプロビジョニングします。

Important:

必ず、"インフラストラクチャのプロビジョニングまたは特定" で、シャード・クラスタのインフラストラクチャの要件とベスト・プラクティスを確認してください。

クラスタ・ノードへの InterSystems IRIS の導入

この手順では、各システムで単一の InterSystems IRIS インスタンスをホストするか、またはホストする予定であることが前提となっています。

  1. インターシステムズが提供するイメージからコンテナを作成する ("コンテナ内でのインターシステムズ製品の実行" を参照) か、キットから InterSystems IRIS をインストールする ("インストール・ガイド" を参照) ことにより、InterSystems IRIS のインスタンスを導入します。

    Important:

    必ず、"データ・ノード・ホストへの InterSystems IRIS の導入" で、シャード・クラスタの InterSystems IRIS インスタンスの要件とベスト・プラクティスを確認してください。

  2. "データベース・キャッシュとデータベースのサイズの見積もり" の説明に従って、各インスタンスのデータベースをホストするストレージ・デバイスがグローバル・データベースのターゲット・サイズに十分対応できる大きさであることを確認します。

    可能であれば、すべてのインスタンスについて、データベース・ディレクトリとジャーナル・ディレクトリを別個のストレージ・デバイスに配置してください。これは、大量のデータ取り込みがクエリの実行と同時に行われる場合に特に重要です。ジャーナル・ストレージなど、ファイル・システムおよびストレージの構成のガイドラインについては、"ストレージの計画"、"ファイル・システムの分離"、および "ジャーナリングの最善の使用方法" を参照してください。

  3. "データベース・キャッシュとデータベースのサイズの見積もり" で決定したサイズに従って、クラスタにおける最終的なロールに応じて、各インスタンスのデータベース・キャッシュ (グローバル・バッファ・プール) を割り当てます。データベース・キャッシュを割り当てる手順は、"メモリと開始設定" を参照してください。

    Note:

    クラスタ・メンバの共有メモリ・ヒープのサイズを大きくすることがお勧めの手段となることがあります。共有メモリ・ヒープへのメモリの割り当て方法の詳細は、"gmheap" を参照してください。

    InterSystems IRIS インスタンスのルーチン・キャッシュとデータベース・キャッシュおよび共有メモリ・ヒープにメモリを割り当てる際のガイドラインは、"システム・リソースの計画と管理" を参照してください。

管理ポータルを使用したネームスペース・レベルのクラスタの構成

インフラストラクチャをプロビジョニングまたは特定して、クラスタ・ノードに InterSystems IRIS をインストールした後、このセクションのステップに従って、管理ポータルを使用してネームスペース・レベルのクラスタを構成します。

ブラウザで管理ポータルを開く方法の詳細は、コンテナに導入されたインスタンスの手順、またはキットからインストールしたインスタンスの手順を参照してください。

シャード・データ・サーバの準備

目的の各インスタンスで以下を実行して、クラスタにシャード・データ・サーバとして追加するための準備を行います。

Note:

状況によっては、API (管理ポータルの基盤) で 1 つ以上のノードのホスト名をクラスタのノードの相互接続に使用できる IP アドレスに解決できない場合があります。このような場合、$SYSTEM.Sharding.SetNodeIPAddress()Opens in a new tab ("%SYSTEM.Sharding API" を参照) を呼び出して、各ノードで使用する IP アドレスを指定できます。$SYSTEM.Sharding.SetNodeIPAddress() を使用するには、対象の各クラスタ・ノードでこれを呼び出してから、これらのノードで他の %SYSTEM.Sharding API 呼び出しを行う必要があります。以下に例を示します。下線

set status = $SYSTEM.Sharding.SetNodeIPAddress("00.53.183.209")

この呼び出しを使用する場合、シャードをマスタ・ネームスペースに割り当てる際に、ホスト名ではなく、各シャード・データ・サーバ・ノードに対して指定した IP アドレスを使用する必要があります。"シャード・マスタ・データ・サーバの構成とシャード・データ・サーバの割り当て" を参照してください。

  1. インスタンスの管理ポータルを開き、[システム管理]→[構成]→[システム構成]→ [シャーディング]→[シャード有効] の順に選択し、表示されるダイアログで [OK] をクリックします (既定値はほぼすべてのクラスタに適しているため、[ECP 接続の最大数] 設定の値を変更する必要はありません)。

  2. インスタンスを再起動します (管理ポータルが表示されているブラウザのウィンドウやタブを閉じる必要はありません。インスタンスが完全に再起動した後に再読み込みするだけでかまいません)。

  3. シャード・ネームスペースを作成するには、[ネームスペースレベルの構成] ページ ([システム管理]→[構成]→[システム構成]→[シャーディング]→[ネームスペースレベルの構成]) に移動して、[ネームスペースを作成] ボタンをクリックします。続いて、"ネームスペースの作成/変更" の手順に従います (ネームスペースは相互運用対応である必要はありません)。別のシャード・データ・サーバのシャード・ネームスペースには異なる名前を付けることができますが、同じ名前を付けた方が便利です。

    このプロセスでは、"データベース・キャッシュとデータベースのサイズの見積もり" で説明しているように、既定のグローバル・データベースで新しいデータベースを作成し、必ず、シャード・ネームスペースのターゲット・サイズに対応できる十分な空き容量があるデバイスにそのデータベースを配置してください。データ取り込みのパフォーマンスが重要な考慮事項である場合は、データベースの初期サイズをそのターゲット・サイズに設定します。また、作成したグローバル・データベースを、ネームスペースの既定のルーチン・データベースとして選択します。

    Important:

    シャード・データ・サーバにするために既存のミラーを準備する場合は、各メンバのシャード・ネームスペースの既定のグローバル・データベースを作成する際に (最初にプライマリ、次にバックアップ、その次に DR 非同期)、[ミラー・データベース?] プロンプトで [はい] を選択して、シャード・ネームスペースのグローバル・データベースをミラーに含めます。

    Note:

    "データベース・キャッシュとデータベースのサイズの見積もり" で説明したように、シャード・マスタ・データ・サーバとシャード・データ・サーバはすべて、単一の既定のグローバル・データベースを共有し、このデータベースは、シャード・マスタに物理的に配置され、マスタ・グローバル・データベースと呼ばれます。シャード・ネームスペースが作成されたときに作成される既定のグローバル・データベースはシャードに残りますが、シャードに保存されているデータを含む local globals database になります。シャード・データ・サーバは、クラスタに割り当てられるまでマスタ・グローバル・データベースを使用しません。このため、わかりやすくするために、このドキュメントの計画ガイドラインと手順では、最終的なローカル・グローバル・データベースを、シャード・ネームスペースの既定のグローバル・データベースと呼んでいます。

    新しいネームスペースは、IRISTEMP が一時ストレージ・データベースとして構成された状態で自動的に作成されます。シャード・ネームスペースのこの設定を変更しないでください。

  4. 後の手順のために、ホスト・システムの DNS 名または IP アドレス、インスタンスのスーパーサーバ (TCP) ポート、および作成したシャード・ネームスペースの名前を記録します。

    Note:

    もう 1 つのノード (この手順で必要なノード) から見ると、コンテナ化された InterSystems IRIS インスタンスのスーパーサーバ・ポートは、そのコンテナが作成されたときにスーパーサーバ・ポートが公開されたホスト・ポートによって異なります。この詳細および例は、"永続的な %SYS を使用した InterSystems IRIS コンテナの実行" と "InterSystems IRIS コンテナの実行 ： Docker Compose の例"、および Docker ドキュメントの "Container networkingOpens in a new tab" を参照してください。

    そのホスト上にしかないコンテナ化されていない InterSystems IRIS インスタンスの既定のスーパーサーバ・ポート番号は 1972 です。インスタンスのスーパーサーバ・ポート番号を表示または設定するには、そのインスタンスの管理ポータルで [システム管理]→[構成]→[システム構成]→[メモリと開始設定] を選択します (インスタンスの管理ポータルを開いてスーパーサーバ・ポートを確認する方法の詳細は、コンテナに導入されたインスタンスの手順、またはキットからインストールしたインスタンスの手順を参照してください)。

シャード・マスタ・データ・サーバの構成とシャード・データ・サーバの割り当て

目的のインスタンスで以下を実行してシャード・マスタ・データ・サーバとして構成し、準備しておいたシャード・データ・サーバをクラスタに割り当てます。この手順を使用してクラスタにクエリ・シャードを割り当てることもできます。

  1. インスタンスの管理ポータルを開き、[システム管理]→[構成]→[システム構成]→ [シャーディング]→[シャード有効] の順に選択し、表示されるダイアログで [OK] をクリックします (既定値はほぼすべてのクラスタに適しているため、[ECP 接続の最大数] 設定の値を変更する必要はありません)。

  2. インスタンスを再起動します (管理ポータルが表示されているブラウザのウィンドウやタブを閉じる必要はありません。インスタンスが完全に再起動した後に再読み込みするだけでかまいません)。

  3. マスタ・ネームスペースを作成するには、[ネームスペースレベルの構成] ページ ([システム管理]→[構成]→[システム構成]→[シャーディング]→[ネームスペースレベルの構成]) に移動して、[ネームスペースを作成] ボタンをクリックします。続いて、"ネームスペースの作成/変更" の手順に従います (ネームスペースは相互運用対応である必要はありません)。

    このプロセスでは、"データベース・キャッシュとデータベースのサイズの見積もり" で説明しているように、既定のグローバル・データベースで新しいデータベースを作成し、必ず、マスタ・ネームスペースのターゲット・サイズに対応できる十分な空き容量があるデバイスにそのデータベースを配置してください。また、作成したグローバル・データベースを、ネームスペースの既定のルーチン・データベースとして選択します。

    Important:

    既存のミラーをシャード・マスタ・データ・サーバとして構成する場合は、各メンバのマスタ・ネームスペースの既定のグローバル・データベースを作成する際に (最初にプライマリ、次にバックアップ、その次に DR 非同期)、[ミラー・データベース?] プロンプトで [はい] を選択して、マスタ・ネームスペースのグローバル・データベースをミラーに含めます。

  4. シャード・データ・サーバを割り当てるには、[ネームスペース] ドロップダウンが先ほど作成したマスタ・ネームスペースに設定されていることを確認します。各シャードに対して、[ネームスペースレベルの構成] ページの [シャード割り当て] ボタンをクリックして [シャード割り当て] ダイアログを表示し、シャード・データ・サーバ・インスタンスの以下の情報を入力します。

    • ホストの名前 (または、このセクションの冒頭で説明したように、この手順を開始する前に各ノードで $SYSTEM.Sharding.SetNodeIPAddress()Opens in a new tab 呼び出しを使用した場合は IP アドレス)。

    • スーパーサーバ・ポート。

    • 準備の際に作成したシャード・ネームスペースの名前。

    • シャードのロールとして [データ] を選択。

      Important:

      シャード・クエリ・サーバを割り当てるには、シャードのロールとして、[データ] ではなく [クエリ] を選択します。

    既存のミラーをシャード・データ・サーバとして割り当てる場合は、プライマリから作業を始め、上記の情報を入力した後に、[ミラー] を選択して以下の情報を指定します。これにより、バックアップが自動的にプライマリに割り当てられます (シャード・クエリ・サーバはミラーリングされません)。

    • ミラーの名前。

    • バックアップのホストの名前 (または IP アドレス)。

    • バックアップのスーパーサーバ・ポート。

    • ミラーの仮想 IP アドレス (VIP) (設定されている場合)。

    最後に [完了] を選択します。

  5. シャードを割り当てると、そのシャードは [ネームスペースレベルの構成] ページのリストに表示されます。シャードがミラーである場合は、両方のフェイルオーバー・メンバが含まれます。

  6. すべてのシャード・データ・サーバ (およびオプションでシャード・クエリ・サーバ) を割り当てたら、[シャードを検証] をクリックして、ポートが正しく、ノードの必要な情報がすべて設定されていて、シャード・マスタがシャード・データ・サーバと通信できることを確認します。

シャード・サーバの割り当て解除

一覧表示されているシャード・データ・サーバまたはシャード・クエリ・サーバの右側にある [割り当て解除] リンクを使用して、シャード・サーバをクラスタから削除できます。ミラーリングされたシャード・データ・サーバを割り当て解除する場合は、プライマリの管理ポータルで割り当て解除を行う必要があります。

Important:

クラスタにシャード・テーブルまたはクラスがある場合は (テーブルにデータが含まれるかどうかは関係ありません)、シャード・データ・サーバを割り当て解除することはできません。

API を使用したクラスタ・ノードの構成

インフラストラクチャをプロビジョニングまたは特定して、クラスタ・ノードに InterSystems IRIS をインストールした後、このセクションのステップに従って、API を使用してネームスペース・レベルのクラスタを構成します。ここで説明されている呼び出し、および API の他の呼び出しの詳細は、"InterSystems クラス・リファレンス" の %SYSTEM.Sharding のクラス・ドキュメントOpens in a new tabを参照してください。

Note:

状況によっては、API で 1 つ以上のノードのホスト名をクラスタのノードの相互接続に使用できる IP アドレスに解決できない場合があります。このような場合、$SYSTEM.Sharding.SetNodeIPAddress()Opens in a new tab ("%SYSTEM.Sharding API" を参照) を呼び出して、各ノードで使用する IP アドレスを指定できます。$SYSTEM.Sharding.SetNodeIPAddress() を使用するには、対象の各クラスタ・ノードでこれを呼び出してから、これらのノードで他の %SYSTEM.Sharding API 呼び出しを行う必要があります。以下に例を示します。

set status = $SYSTEM.Sharding.SetNodeIPAddress("00.53.183.209")

この呼び出しを使用する場合、シャード・マスタで $SYSTEM.Sharding.AssignShard()Opens in a new tab を呼び出してクラスタにノードを割り当てる際、以下の手順に示すように、shard-host 引数として、ホスト名ではなく、各ノードに対して指定した IP アドレスを使用する必要があります。

シャード・データ・サーバの準備

目的の各インスタンスで以下を実行して、クラスタにシャード・データ・サーバとして追加するための準備を行います。

Note:

ネームスペース・レベルの導入でミラーを作成することはできません。ただし、既存のミラーのフェイルオーバー・メンバをシャード・データ・サーバとして追加できます。このためには、ミラーを作成し、この手順を使用してメンバを準備してから、次の手順の説明に従ってメンバをシャード・データ・サーバとして割り当てます。

  1. 管理ポータルでシャード・ネームスペースを作成します。詳細は、"ネームスペースの作成/変更" を参照してください (ネームスペースは相互運用対応である必要はありません)。別のシャード・データ・サーバのシャード・ネームスペースには異なる名前を付けることができますが、同じ名前を付けた方が便利です。

    "データベース・キャッシュとデータベースのサイズの見積もり" で説明しているように、新しいデータベースを既定のグローバル・データベースとして作成し、必ず、そのターゲット・サイズに対応できる十分な空き容量があるデバイスにそのデータベースを配置してください。データ取り込みのパフォーマンスが重要な考慮事項である場合は、データベースの初期サイズをそのターゲット・サイズに設定します。

    Important:

    シャード・データ・サーバにするために既存のミラーを準備する場合は、各メンバのシャード・ネームスペースの既定のグローバル・データベースを作成する際に (最初にプライマリ、次にバックアップ、その次に DR 非同期)、[ミラー・データベース?] プロンプトで [はい] を選択して、シャード・ネームスペースのグローバル・データベースをミラーに含めます。

    作成したグローバル・データベースを、ネームスペースの既定のルーチン・データベースとして選択します。

    Note:

    "データベース・キャッシュとデータベースのサイズの見積もり" で説明したように、シャード・マスタ・データ・サーバとシャード・データ・サーバはすべて、単一の既定のグローバル・データベースを共有し、このデータベースは、シャード・マスタに物理的に配置され、マスタ・グローバル・データベースと呼ばれます。シャード・ネームスペースが作成されたときに作成される既定のグローバル・データベースはシャードに残りますが、シャードに保存されているデータを含む local globals database になります。シャード・データ・サーバは、クラスタに割り当てられるまでマスタ・グローバル・データベースを使用しません。このため、わかりやすくするために、このドキュメントの計画ガイドラインと手順では、最終的なローカル・グローバル・データベースを、シャード・ネームスペースの既定のグローバル・データベースと呼んでいます。

    新しいネームスペースは、IRISTEMP が一時ストレージ・データベースとして構成された状態で自動的に作成されます。シャード・ネームスペースのこの設定を変更しないでください。

  2. 後の手順のために、ホスト・システムの DNS 名または IP アドレス、インスタンスのスーパーサーバ (TCP) ポート、および作成したシャード・ネームスペースの名前を記録します。

    Note:

    もう 1 つのノード (この手順で必要なノード) から見ると、コンテナ化された InterSystems IRIS インスタンスのスーパーサーバ・ポートは、そのコンテナが作成されたときにスーパーサーバ・ポートが公開されたホスト・ポートによって異なります。この詳細および例は、"永続的な %SYS を使用した InterSystems IRIS コンテナの実行" と "InterSystems IRIS コンテナの実行 ： Docker Compose の例"、および Docker ドキュメントの "Container networkingOpens in a new tab" を参照してください。

    そのホスト上にしかないコンテナ化されていない InterSystems IRIS インスタンスの既定のスーパーサーバ・ポート番号は 1972 です。インスタンスのスーパーサーバ・ポート番号を表示または設定するには、そのインスタンスの管理ポータルで [システム管理]→[構成]→[システム構成]→[メモリと開始設定] を選択します (インスタンスの管理ポータルを開いてスーパーサーバ・ポートを確認する方法の詳細は、コンテナに導入されたインスタンスの手順、またはキットからインストールしたインスタンスの手順を参照してください)。

  3. InterSystems ターミナル・ウィンドウで、任意のネームスペースで $SYSTEM.Sharding.EnableShardingOpens in a new tab を呼び出して ("%SYSTEM.Sharding API" を参照)、インスタンスがシャード・クラスタに参加できるようにします。次に例を示します。

    set status = $SYSTEM.Sharding.EnableSharding()

    引数は必要ありません。

    Note:

    これらの手順で詳述されている各 API 呼び出しの戻り値 (成功の場合は 1 など) を確認するには、以下を入力します。

    zw status

    状況によっては通知なしで呼び出しが失敗することがあるため、各呼び出しの後に [ステータス] を確認することをお勧めします。呼び出しが成功しなかった ([ステータス] が [1] 以外) 場合、以下を入力することにより、わかりやすいエラー・メッセージが表示されます。

    do $SYSTEM.Status.DisplayError(status)

    この呼び出しを実行した後で、インスタンスを再起動します。

シャード・マスタ・データ・サーバの構成とシャード・データ・サーバの割り当て

シャード・マスタ・データ・サーバのインスタンスで、以下を実行してシャード・マスタを構成し、シャード・データ・サーバを割り当てます。

  1. 管理ポータルでマスタ・ネームスペースを作成します。詳細は、"ネームスペースの作成/変更" を参照してください (ネームスペースは相互運用対応である必要はありません)。

    "データベース・キャッシュとデータベースのサイズの見積もり" で説明しているように、必ず、作成する既定のグローバル・データベースをそのターゲット・サイズに対応できる十分な空き容量があるデバイスに配置してください。データ取り込みのパフォーマンスが重要な考慮事項である場合は、データベースの初期サイズをそのターゲット・サイズに設定します。

    Important:

    既存のミラーをシャード・マスタ・データ・サーバとして構成する場合は、各メンバのマスタ・ネームスペースの既定のグローバル・データベースを作成する際に (最初にプライマリ、次にバックアップ、その次に DR 非同期)、[ミラー・データベース?] プロンプトで [はい] を選択して、マスタ・ネームスペースのグローバル・データベースをミラーに含めます。

    作成したグローバル・データベースを、ネームスペースの既定のルーチン・データベースとして選択します。

    Note:

    新しいネームスペースは、IRISTEMP が一時ストレージ・データベースとして構成された状態で自動的に作成されます。マスタ・ネームスペースのこの設定を変更しないでください。シャード・クエリの中間結果が IRISTEMP に格納されるため、このデータベースは、拡張に対応できる十分な空き容量がある、使用可能な最速のストレージに配置する必要があります。大規模な結果セットを返す多くの同時シャード・クエリが予想される場合は特に、その必要があります。

  2. InterSystems ターミナル・ウィンドウで、任意のネームスペースで以下の手順を実行します。

    1. $SYSTEM.Sharding.EnableSharding()Opens in a new tab を呼び出して ("%SYSTEM.Sharding API" を参照)、インスタンスがシャード・クラスタに参加できるようにします (引数は必要ありません)。次に例を示します。

      set status = $SYSTEM.Sharding.EnableSharding()

      この呼び出しを実行した後で、インスタンスを再起動します。

    2. シャード・データ・サーバごとに 1 回ずつ $SYSTEM.Sharding.AssignShard()Opens in a new tab を呼び出して ("%SYSTEM.Sharding API" を参照)、作成したマスタ・ネームスペースにシャードを割り当てます。次に例を示します。

      set status = $SYSTEM.Sharding.AssignShard("master-namespace","shard-host",shard-superserver-port,
    "shard_namespace")

      引数は、作成したマスタ・ネームスペースの名前と、前の手順でそのシャード・データ・サーバについて記録した情報を表します。次に例を示します。

      set status = $SYSTEM.Sharding.AssignShard("master","shardserver3",1972,"shard3")

      このセクションの冒頭で説明したように、この手順を始める前に各ノードで $SYSTEM.Sharding.SetNodeIPAddress()Opens in a new tab 呼び出しを使用した場合、shard-host には、ホスト名ではなくシャード・ホストの IP アドレスを使用してください。

    3. シャードを正しく割り当てているかどうかを検証するには、以下のコマンドを発行し、ホスト、ポート、およびネームスペースの名前を確認します。

      do $SYSTEM.Sharding.ListShards()
Shard   Host                       Port    Namespc  Mirror  Role    VIP
1       shard1.internal.acme.com   56775   SHARD1
2       shard2.internal.acme.com   56777   SHARD2
...
      Note:

      InterSystems IRIS インスタンスのスーパーサーバ・ポートの特定についての重要な情報は、"シャード・データ・サーバの準備" の手順 2 を参照してください。

    4. シャード・マスタがシャード・データ・サーバと通信できるように、ポートが正しく、ノードの必要な構成がすべて適切であることを確認するには、次のように $SYSTEM.Sharding.VerifyShards()Opens in a new tab ("%SYSTEM.Sharding API" を参照) を呼び出します。

      do $SYSTEM.Sharding.VerifyShards()

      $SYSTEM.Sharding.VerifyShards()Opens in a new tab 呼び出しは、多数のエラーを識別します。例えば、$SYSTEM.Sharding.AssignShard()Opens in a new tab 呼び出しで指定されたポートが、シャード・データ・サーバ・ホスト上で開いているポートであり、InterSystems IRIS インスタンスのスーパーサーバ・ポートではない場合、シャードは正しく割り当てられません。$SYSTEM.Sharding.VerifyShards()Opens in a new tab 呼び出しはこれを示します。

    5. ミラーのフェイルオーバー・ペアをシャード・データ・サーバとして準備および追加した場合は、以下に示すように、シャード・マスタ・データ・サーバで $SYSTEM.Sharding.AddDatabasesToMirrors()Opens in a new tab 呼び出し ("%SYSTEM.Sharding API" を参照) を使用して、各プライマリにマスタ・データベースとシャード・データベースをミラーリングされたデータベースとして追加し、各フェイルオーバー・ペアをミラーリングされたシャード・データ・サーバとして完全に構成できます。

      set status = $SYSTEM.Sharding.AddDatabasesToMirrors("master-namespace")

      推奨されるベスト・プラクティスは、ミラーリングされたノードとミラーリングされていないノードを混在させるのではなく、完全にミラーリングするか、まったくミラーリングしないでクラスタを導入することです。

構成したデータ・ノード・ミラー内のフェイルオーバー・ペアに DR 非同期を追加するには、最初のフェイルオーバー・メンバ上のミラーリングされたデータベースに対応する新しいノード上にデータベースを作成します。続いて、そのミラーに新しいノードを DR 非同期として追加し、最初のフェイルオーバー・メンバ上に作成したバックアップからデータベースをリストアして、そのデータベースを自動的にミラーに追加します。

既存のデータ・ノードそれぞれにミラーを作成してから、ノード 1 で $SYSTEM.Sharding.AddDatabasesToMirrors()Opens in a new tab を呼び出して、クラスタをミラーリングされた構成に自動的に変換します。

予約名

以下の名前は InterSystems IRIS で使用されているため、ユーザ定義要素の名前には使用しないでください。

  • パッケージ名 IRIS.Shard は、システム生成シャード・ローカル・クラス名用に予約されているため、ユーザ定義クラスには使用しないでください。

  • スキーマ名 IRIS_Shard は、システム生成シャード・ローカル・テーブル名用に予約されているため、ユーザ定義テーブルには使用しないでください。

  • プレフィックス IRIS.Shard.、IS.、および BfVY. は、シャード・ローカル・テーブルのグローバル用に予約されており、シャード・ネームスペースでシャードのローカル・データベースにマッピングされます。ユーザ定義グローバル名およびシャード化されていないテーブルのグローバル名は、これらのプレフィックスで始めないでください。シャード・ローカル・テーブル以外のグローバルにこれらのプレフィックスを使用すると、予測できない動作が起こる可能性があります。

関連項目


Previous sectionシャーディングによるデータ量に応じた水平方向の拡張
FeedbackOpens in a new tab