Redisの永続性の構成方法

編集済み 3 数週間前 によって ExtremeHow 編集チーム

レディス設定設定永続性データストレージバックアップ復旧データベース管理サーバー

Redisは、メモリ内のキーバリューデータストアで、キャッシュ、セッション管理、リアルタイム分析によく使用されます。Redisの運用上の重要な側面の1つが永続性です。Redisのコンテキストでの永続性は、予期しない障害に対してデータの耐久性を確保することです。Redisは主にメモリ内のデータベースですが、その永続性レイヤーはメモリの不安定性を超えてデータの可用性を確保するのに役立ちます。Redisには2つの主要な永続性オプションがあります：RDB（Redisデータベースバックアップ）とAOF（Append Only File）。ここでは、Redisの永続性を効果的に構成するための詳細なガイドを紹介し、各オプションを調査し、それらがどのように機能するかについての包括的な理解を提供します。

Redisの永続性オプションの理解

構成に入る前に、Redisが提供する2つの主要な永続性オプションを理解することが重要です：

RDB永続性

RDBはRedisデータベースバックアップの略です。この形式の永続性は、指定されたインターバルでメモリ内のデータセットのスナップショットを作成します。スナップショットはディスク上にバイナリファイルとして保存されます。RDBの主な利点は、その使いやすさとこれらのスナップショットからのデータセットの迅速な復元です。しかし、欠点は、Redisがクラッシュした場合に、最新のスナップショットに保存されていないデータが失われることです。

RDBでは、Redisを指定された間隔で自動的にスナップショットを作成するように構成することができます。また、データセットの変更頻度に基づいてもスナップショットを作成できます。スナップショットファイルは、バックアップのために異なるサーバーに移動することもでき、データ保護の追加レイヤーを提供します。

AOF永続性

AOFはAppend Only Fileの略です。RDBとは異なり、AOFはサーバーが受け取ったすべての書き込み操作をログに記録します。これは必要に応じてデータセットを再構築するために使用されるファイルに追加されます。AOFはより頻繁にディスクに変更を書き込むため、RDBよりも優れた耐久性を提供します。

AOFでは、さまざまな構成オプションを通じてディスク書き込みの頻度を制御できます。Append-onlyファイルはRDBスナップショットよりも大きいですが、より詳細なデータ復旧の利点を提供します。

RDB永続性の構成

RedisをRDB永続性を使用するように設定するには、希望するスナップショットポリシーを設定する必要があります。これは通常、Redisのメインの構成ファイルであるredis.confファイルで行います。

ステップ1: 構成ファイルを見つける

Redisの構成ファイルは、通常、Linuxシステムでは/etc/redis/redis.confにあります。好きなテキストエディタでこのファイルを開きます。

ステップ2: スナップショット間隔の構成

構成ファイルには以下の行が見つかります：
save 900 1
save 300 10
save 60 10000
これらの各行は、Redisがデータセットのスナップショットを作成する条件を指定しています。

• save 900 1 : 少なくとも1つのキーが変更された場合、データセットを900秒（15分）ごとに保存します。
• save 300 10 : 少なくとも10の変更がある場合、データセットを300秒（5分）ごとに保存します。
• save 60 10000 : 少なくとも10,000の変更がある場合、データセットを60秒ごとに保存します。

これらの設定を調整して自分のニーズに合わせることができます。例えば、10分ごとに5つのキーの変更を保存したい場合、次のような行を追加します：save 600 5。

ステップ3: 構成を保存

変更を加えた後、構成ファイルを保存し、Redisサーバーを再起動して変更を適用します。これは、コマンドsudo systemctl restart redisを使用するか、システムでサービスを管理する方法に従います。

AOF永続性の構成

AOF永続性は、すべての書き込み操作を記録することで、RDBスナップショットよりも高いレベルのデータ保護を提供します。AOF永続性を有効にするには、redis.confファイルにいくつかの調整を行います。

ステップ1: AOFを有効にする

redis.confファイルで、次の行を見つけます：
# appendonly no
行のコメントを解除し、#を削除してnoをyesに変更します：
appendonly yes

ステップ2: AOFオプションの構成

AOF永続性は、いくつかの構成オプションを提供します：

• appendfsync : AOFデータをディスクに同期するポリシーを設定します。オプションは次のとおりです：
  • always : データは書き込まれるたびに即座にディスクにフラッシュされます。最大のデータ保護を提供しますが、遅くなります。
  • everysec : データは毎秒ディスクにフラッシュされます。パフォーマンスとデータ保護の良好な妥協案を提供します。
  • no : データのフラッシュタイミングをオペレーティングシステムに委ねます。キャッシングポリシーは通常OSレベルで実装されます。
• No-Appendfsync-on-rewrite : redis.confで定義されたこの設定をトグルできます：
  no-appendfsync-on-rewrite no
  これは、BGSAVE中の集中的なI/Oを防ぐためにいくつかのAOFフラッシュを遅延させます。
• AOFリライト : AOFファイルは大きくなる可能性がありますが、Redisはそれらをより小さなバージョンに書き直すことができます：
  • リライトを手動でトリガーするには、コマンドBGREWRITEAOFを使用します。
  • 自動リライトは、aof-rewrite-incremental-fsync yesなどのオプションを使用して増分ベースで構成できます。

ステップ3: 構成を保存

RDBと同様に、構成ファイルを変更した後、変更を保存し、Redisを再起動して適用します：
sudo systemctl restart redis

最大のデータ保護のためのRDBとAOFの組み合わせ

RDBとAOFの両方を組み合わせて使用するようにRedisを構成できます。このハイブリッドアプローチは、スナップショットの柔軟性と書き込みの粒度を提供します。高い信頼性が求められるシナリオでは、これが最良のプラクティスです。

これを実現するには、前述のようにRDBを構成し、AOFを有効にします：

appendonly yes appendfsync everysec

両方の永続性メソッドが使用されている場合、Redisは通常、デフォルトではAOFからデータを読み込むことを好みます。これは通常、データの最も最新の状態を持っているためです。

適切な永続性戦略の選択

適切な永続性方法の選択は、主に特定のアプリケーション要件に依存します：

• RDBを使用する場合:
  • パフォーマンスと引き換えに、一部のデータ損失を許容できる場合。
  • データの変更頻度が低い場合。
  • ディスクに対する書き込み負荷の少ない、よりスペース効率の良い方法を望む場合。
• AOFを使用する場合:
  • 各操作の整合性と耐久性が重要な場合。
  • 最小限のデータ損失で正確なデータを復旧する必要がある場合。
• 両方を使用する場合:
  • 合理的なパフォーマンスで高いデータ可用性とセキュリティを望む場合。
  • 主な優先事項が広範なフォールトトレランスである場合、データ保護とディスクI/Oのバランスを求める場合。

永続性構成のテスト

希望する永続性設定を構成した後、動作を適切にテストし、確認することが重要です：

• スナップショットの確認: 指定されたインターバルでのRDBファイルの作成を確認します。
• 障害のシミュレーション: Redisを強制終了し、再起動してデータが永続ストレージから正常にロードされることを確認します。
• ファイルサイズのモニタリング: AOFファイルのサイズを監視し、AOFリライト機能をテストします。

結論

Redisの永続性は、データ耐久性を効果的に管理するための重要な側面です。RDBとAOF、またはその両方を正しく理解し実装することにより、故障時でもデータが安全に保たれるようになります。パフォーマンス要件とデータセキュリティ要件の慎重なバランスをとることで、使用ケースに最も適したオプションを決定できます。

常に定期的なバックアップを取り、レプリケーションやクラスタリングなどの要素を含む全体的なシステムアーキテクチャを考慮して、包括的なデータ保護を考慮してください。

  この記事をシェアする

記事の内容に誤りがある場合, あなたは 更新をリクエストできます