Tair (Redis® OSS-Compatible):Redis グローバル分散キャッシュの制限事項

使用制限

• 各サブインスタンスは、DRAM ベースのインスタンスである必要があります。

  すべてのサブインスタンスが同一の仕様であることを確認してください。整合性を維持するため、いずれかのサブインスタンスの構成を変更した場合は、他のすべてのサブインスタンスにも同様の変更を適用してください。仕様が不一致の場合、パフォーマンスや容量に関する問題が発生する可能性があります。

• 分散インスタンスには最大で 3 つのサブインスタンスを含めることができ、かつサブインスタンスは同一の可用性ゾーンに配置してはなりません。最初のサブインスタンスは既存のインスタンスから変換可能ですが、2 番目および 3 番目のサブインスタンスは新規購入する必要があります。

• 分散インスタンス内のサブインスタンスは、すべて中国本土リージョン内、またはすべてその他のリージョン内に配置する必要があります。中国本土リージョンとその他のリージョン間でデータを同期する必要がある場合は、DTS データ同期機能をご利用ください。詳細については、「越境データ同期の権限申請」をご参照ください。

• サブインスタンスを分散インスタンスに追加した後、以下の制限が適用されます：

  • インスタンスの可用性ゾーンを変更できません。

  • インスタンスのアーキテクチャ（例：クラスタアーキテクチャから標準アーキテクチャへの変更など）を変更できません。

  • クラスターインスタンスの仕様を変更する場合、シャード数またはシャードの仕様のいずれか一方のみを一度に変更できます。詳細については、「分散クラスターインスタンスの構成変更ソリューション」をご参照ください。

• クラシックインスタンスの場合、直接接続エンドポイントが有効になっていないことを確認してください（直接接続アドレスの解放）。この制限はクラウドネイティブインスタンスには適用されません。

コマンド制限

• FLUSHDB コマンドおよび FLUSHALL コマンドは同期されません。

  • データをクリアする場合：すべてのサブインスタンスで FLUSHALL コマンドを実行する必要があります。これを実行しないと、データの不整合が発生します。

  • 再同期するには：たとえば、インスタンス A をソースとして使用してインスタンス B にデータを再同期する場合、remove を実行してインスタンス B を分散インスタンスから削除し、インスタンス B で FLUSHALL コマンドを実行してから、再度インスタンス B を分散インスタンスに追加する必要があります。追加されると、同期が自動的に開始されます。

• SWAPDB コマンドは同期されません。

• SCRIPT LOAD、SCRIPT FLUSH、FUNCTION LOAD、FUNCTION DELETE、FUNCTION RESTORE、FUNCTION FLUSH などのスクリプト関連コマンドは同期されません。

• PUB コマンドおよび SUB コマンドは同期されません。クロスリージョン通知におけるメッセージレプリケーションを実装するには、Stream データ構造の利用を推奨します。

• データエビクションおよび有効期限切れによって生成される DEL コマンドは同期されません。

粒度制限

データ整合性の制限

• 単一書き込みシナリオ（例：ディザスタリカバリ）では、データ整合性レベルは結果整合性となります。以下の状況でデータの不整合が発生する可能性があります：

  • 同期遅延の影響により、生存時間（TTL）付きキーに対する操作でデータの不整合が発生する場合があります。たとえば、EXPIRE コマンドをサブインスタンス A で正常に実行して有効期限を延長したとしても、当該コマンドがサブインスタンス B へ同期される前に既にデータが有効期限切れとなることがあります。データ整合性に対する要件が高い場合は、グローバルマルチアクティブインスタンスにおいて有効期限を設定しないことを推奨します。

  • 各サブインスタンスにおけるデータエビクション対象のキーは独立しており、ランダムに選択されます。データエビクションが発生しないよう、メモリ使用量がインスタンスの仕様を超えないようにしてください。

• マルチ書き込みシナリオ（例：マルチアクティブ）では、複数のサブインスタンスで同一キーを同時に、またはほぼ同時に更新しないでください。そうしないと、データの不整合（キーの結果整合性が保証されない）、またはデータの蓄積（ストリーミングシナリオにおける厳密な増分による競合）が発生する可能性があります。

  説明

  グローバル分散キャッシュ 機能は、Conflict-Free Replicated Data Type（CRDT）制約をサポートしていません。データ整合性はアプリケーション層で保証する必要があります。

  シナリオ	説明図	説明
  キーの有効期限延長が失敗		t1 時点で、サブインスタンス A および B の両方に有効期限付きのキーが存在し、そのキーは t3 時点で有効期限切れになります。 t2 時点で、サブインスタンス A が PEXPIREAT コマンドを実行し、キーの有効期限を t5 まで延長します。 t3 時点で、ネットワーク遅延の影響により、サブインスタンス B はサブインスタンス A からの PEXPIREAT 同期コマンドを受信していません。そのため、サブインスタンス B のキーは有効期限切れにより削除されます。 t4 時点で、サブインスタンス B がキーの有効期限延長コマンドを受信しますが、すでにキーは削除済みのためコマンドは失敗します。この時点で、サブインスタンス A にはキーが残っていますが、サブインスタンス B ではキーが失われています。
  有効期限によるコマンド実行結果の不整合		SMOVE コマンドを例に説明します。 t1 時点で、サブインスタンス A および B の両方に、有効期限が t3 のキー1 と有効期限のないキー2 が存在します。 t2 時点で、サブインスタンス A が SMOVE キー1 キー2 "foo" コマンドを実行し、"foo" メンバーをキー2 へ移動します。 t3 時点で、ネットワーク遅延の影響により、サブインスタンス B はサブインスタンス A からの同期コマンドを受信していません。その間に、サブインスタンス A および B の両方でキー1 が有効期限切れにより削除されます。 t4 時点で、サブインスタンス B が SMOVE コマンドを受信しますが、キー1 はすでに削除されているためコマンドは失敗します。この時点で、インスタンス A のキー2 には "foo" メンバーが含まれますが、インスタンス B のキー2 には含まれません。
  ランダムなデータエビクション		t1 時点で、サブインスタンス A および B の両方にキー1 およびキー2 が存在します。 t2 時点で、サブインスタンス A のメモリが満杯になり、データエビクションが発生し、キー2 がランダムに削除されます。 t3 時点で、サブインスタンス B のメモリが満杯になり、データエビクションが発生し、キー1 がランダムに削除されます。 デフォルトの立ち退きポリシーは volatile-lru であり、データエビクションによる削除操作は同期されないため、サブインスタンス A および B のデータが不整合になります。
  マルチ書き込み — 値の入れ替え		複数のサブインスタンスから同一キーに対する同時書き込み操作は、データの不整合を引き起こす可能性があります。 時間 t1 に、サブインスタンス A が Key:ValA を書き込みます。 t2 時点で、サブインスタンス B が キー:ValB を書き込みます。 t3 時点で、サブインスタンス A がデータ（キー:valA）をサブインスタンス B へ同期し、同時にサブインスタンス B がデータ（キー:valB）をサブインスタンス A へ同期します。 その結果、2 つのサブインスタンスにおけるキーに対応する値が入れ替わります。
  マルチ書き込み — データの型の競合		t1 時点で、サブインスタンス A が Hash データ型の キー を書き込みます。 t2 時点で、サブインスタンス B が String データ型の キー を書き込みます。 t3 時点で、データの型の競合により同期コマンドが失敗します。
  マルチ書き込み — 書き込み条件を満たさない		t1 時点で、サブインスタンス A が SETNX キー ValA を実行します。 t2 時点で、サブインスタンス B が SETNX キー ValB を実行します。 t3 時点で、書き込み条件を満たさないため同期コマンドが失敗します。 説明 HSETNX や SET[NX | XX] などのコマンドでも同様の問題が発生する可能性があります。
  マルチ書き込み — データの順序乱れまたは喪失		t1 時点で、サブインスタンス A が RPUSH キー valA を実行します。 t2 時点で、サブインスタンス B が RPUSH キー valB を実行します。 t3 時点で、同期コマンドによりデータの順序が乱れたり、データが喪失したりする可能性があります。 説明 LPUSH、APPEND、DEL、HDEL、INCR、XADD などのコマンドでも同様の問題が発生する可能性があります。