Azure Cache for Redis でのデータ損失のトラブルシューティング

この記事では、Azure Cache for Redis で発生する 部分的 または 完全な データ損失を診断する方法について説明します。

部分的なキーの損失

Azure Cache for Redis では、メモリに格納された後にキーがランダムに削除されることはありませんが、有効期限ポリシー、削除ポリシー、および明示的なキー削除コマンドに応答してキーが削除されます。 これらのコマンドは 、コンソール または Redis CLI を使用して実行できます。

Premium または Standard Azure Redis インスタンスのプライマリ ノードに書き込まれたキーは、レプリカですぐに使用できない場合があります。 データは、非同期および非ブロッキングの方法でプライマリからレプリカにレプリケートされます。

一部のキーがキャッシュから消える場合は、次の原因を確認してください。

キーの有効期限

キーにタイムアウトが割り当てられ、その期間が経過すると、Azure Cache for Redis によってキーが自動的に削除されます。 Redis キーの有効期限の詳細については、Redis EXPIRE コマンドのドキュメントを参照してください。 タイムアウト値は、 SET、 SETEX、 GETSET、およびその他の *STORE コマンドを使用して設定することもできます。

有効期限が切れたキーの数に関する統計情報を取得するには、 INFO コマンドを使用します。 Stats セクションに、有効期限が切れたキーの総数が示されます。 Keyspaceセクションでは、タイムアウトがあるキーの数と平均タイムアウト値について詳しく説明します。

# Stats

expired_keys:46583

# Keyspace

db0:keys=3450,expires=2,avg_ttl=91861015336

キーの強制削除

Azure Cache for Redis では、データを格納するためのメモリ領域が必要であり、必要に応じて使用可能なメモリを解放するためにキーが消去されます。 used_memory値またはused_memory_rss値が構成されたmaxmemory設定に近づくと、Azure Redis はキャッシュ ポリシーに基づいてメモリからキーの削除を開始します。

削除されたキーの数は 、INFO コマンドを使用して監視できます。

# Stats

evicted_keys:13224

キーの削除

Redis クライアントは、Redis DEL または HDEL コマンドを発行して、Azure Redis からキーを明示的に削除できます。 INFO コマンドを使用して、削除操作の回数を追跡できます。 DELまたはHDELコマンドが呼び出された場合は、Commandstats セクションに一覧表示されます。

# Commandstats

cmdstat_del:calls=2,usec=90,usec_per_call=45.00

cmdstat_hdel:calls=1,usec=47,usec_per_call=47.00

非同期レプリケーション

Standard レベルまたは Premium レベルの Azure Cache for Redis インスタンスは、プライマリ ノードと少なくとも 1 つのレプリカで構成されます。 バックグラウンド プロセスを使用して、データがプライマリからレプリカに非同期的にコピーされます。

Redis Web サイトでの Redis レプリケーションでは、Redis データ レプリケーションの一般的な動作について説明します。 クライアントが Redis に頻繁に書き込むシナリオでは、レプリケーションが瞬時に行われるよう設計されていないため、部分的なデータ損失が発生する可能性があります。

たとえば、クライアントがキーを書き込んだ後で、バックグラウンド プロセスがそのキーをレプリカに送信する前にプライマリがダウンした場合、レプリカが新しいプライマリとして引き継ぐと、キーは失われます。

キーの完全な損失

ほとんどのキーまたはすべてのキーがキャッシュから消える場合は、次の原因を確認してください。

キーのフラッシュ

Azure Redis クライアントは、Redis FLUSHDB コマンドを呼び出して 1 つのデータベース内のすべてのキーを削除するか 、FLUSHALL を呼び出して、Redis キャッシュ内のすべてのデータベースからすべてのキーを削除できます。 キーがフラッシュされたかどうかを確認するには、 INFO コマンドを使用します。 Commandstatsセクションには、FLUSHコマンドが呼び出されたかどうかを示します。

# Commandstats

cmdstat_flushall:calls=2,usec=112,usec_per_call=56.00

cmdstat_flushdb:calls=1,usec=110,usec_per_call=52.00

データベースの選択が正しくない

各データベースは論理的に独立したユニットであり、異なるデータセットを保持しています。 Azure Cache for Redis では、既定では db0 データベースが使用されます。 db1などの別のデータベースに切り替えて、そこからキーを読み取ろうとすると、Azure Redis で見つかりません。 Redis SELECT コマンドを使用して、他の使用可能なデータベースのキーを検索します。

Redis インスタンスのエラー

Redis は、Redis キャッシュをホストする物理マシンまたは仮想マシン (VM) 上のメモリにデータを保持します。 Basic レベルの Azure Cache for Redis インスタンスは、1 つの仮想マシン (VM) でのみ実行されます。 その VM がダウンすると、キャッシュに格納したすべてのデータが失われます。

Standard レベルと Premium レベルのキャッシュでは、レプリケートされた構成で 2 つの VM を使用することで、データ損失に対する回復性が向上します。 そのようなキャッシュのプライマリ ノードで障害が発生すると、レプリカ ノードが自動的に引き継いでデータを提供します。

これらの VM は、障害と更新のために別々のドメインに配置され、両方の VM が一度に使用できなくなる可能性を最小限に抑えます。 ただし、大規模なデータセンターの停止が発生した場合、両方の VM がダウンする可能性があります。 このようなまれなケースでは、データが失われます。 データ永続化と geo レプリケーションを使用して、インフラストラクチャの障害に対するデータ保護を強化することを検討してください。

関連コンテンツ

• Azure Cache for Redis での Redis コマンドライン ツールの使用
• Azure Cache for Redis でのデータ永続化
• Azure Cache for Redis を監視する