Redis の永続化メカニズムについて話しましょう。RDB と AOF のどちらを使用すべきでしょうか?

この記事では、Redis の永続化メカニズム (RDB と AOF) を理解し、RDB と AOF のどちらを使用するかについて説明します。お役に立てれば幸いです!

#RDB

#1. RDB とは

#RDB: 時々、データはディスク上の一時ファイルにスナップショットとして書き込まれ、スナップショット ファイルはリカバリ中にメモリに読み込まれます。クラッシュして再起動するとメモリ内のデータは確実に消えますが、再度redisを起動すると復元されます。 [関連する推奨事項:

Redis ビデオ チュートリアル ]

2. バックアップとリカバリ

メモリ バックアップ--> ディスク一時ファイル

一時ファイル --> メモリに復元

3. RDB の長所と短所

長所
• • 毎回バックアップするしばらくの間、完全バックアップ

  • 災害復旧は簡単で、リモートで送信可能

  • 子プロセスがバックアップされると、メインプロセスはバックアップ データの整合性を確保するための IO 操作はありません (書き込み、変更、削除) はありません。

  • AOF と比較して、より大きなファイルがある場合、迅速な再起動と復元が可能です。

デメリット
• • 障害が発生すると、最後のバックアップ データが失われる可能性があります

  • 子プロセスが占有するメモリの割合 親プロセスと全く同じになります CPU負荷がかかる場合

  • スケジュールされた完全バックアップは負荷の高い操作であるため、リアルタイムバックアップはできません処理される。

4. RDB 設定

• 保存場所は redis.conf で設定可能定義:

  /user/local/redis/working/dump.rdb
  

• 保存メカニズム:

save 900 1
save 300 10
save 60 10000
save 10 3

* 如果1个缓存更新，则15分钟后备份
* 如果10个缓存更新，则5分钟后备份
* 如果10000个缓存更新，则1分钟后备份

• stop-writes-on-bgsave-error
  yes: 保存プロセス中にエラーが発生した場合は、書き込み操作を停止します
  • no: データの不整合が発生する可能性があります
• rdbcompression
  yes: rdb 圧縮モードをオンにします
  • no: オフにします。これにより、CPU 消費量が節約されますが、ファイルはnginx と同じ理由で、より大きくする必要があります
• rdbchecksum
  yes: CRC64 アルゴリズム検証を使用して、rdb でデータ検証を実行します (10%)。パフォーマンスの損失
  • no: 検証なし 検証

概要

RDB は大量のデータの回復に適していますデータの完全性と一貫性が不十分である可能性があります。

AOF

AOF の機能

• ユーザーから要求された書き込み操作をログの形式で記録します。書き込み操作のみが保存されるため、読み取り操作はログに記録されません。

• ファイルは変更されるのではなく、追加されます。

• Redis の aof リカバリは、実際には、追加されたファイルを最初から最後まで読み書きすることです。

利点

• AOF は耐久性が高く、数秒でバックアップできます。問題が発生した場合は、データの最後の 1 秒を失うだけで、信頼性とデータの整合性が大幅に向上します。したがって、AOF は fsync 操作を使用して 1 秒に 1 回バックアップできます。

• ログ ログの形式で追加します。ディスクがいっぱいの場合は、redis-check-aof ツールが実行されます。データが大きすぎる場合、Redis はバックグラウンドで aof を自動的に書き換えることができます。 Redis が古いファイルにログを追加し続ける場合、再書き込みも非常に安全であり、クライアントの読み取りおよび書き込み操作には影響しません。

• AOF ログに含まれるすべての書き込み操作により、redis の解析と回復が容易になります。

• #欠点

同じデータ、同じデータ、AOF が RDB より大きい

さまざまな同期メカニズムでは、AOF は RDB より遅くなります。AOF はバックアップと書き込み操作を 1 秒ごとに実行するため、RDB よりもわずかに遅くなります。 fsync を毎秒バックアップすることに問題はありませんが、クライアントが書き込みのたびにバックアップ fsync を実行すると、redis のパフォーマンスが低下します。
AOF でバグが発生しました。つまり、データ リカバリ中にデータが不完全です。これにより、AOF は RDB ほど単純ではないため、より脆弱になり、バグが発生しやすくなります。バグの発生を防ぐため、AOF は古い命令に基づいて再構築されるのではなく、その時点でキャッシュに存在するデータ命令に基づいて再構築されるため、より堅牢で信頼性が高くなります。
• AOF 構成

  `# AOF 默认关闭，yes可以开启
  appendonly no
  
  # AOF 的文件名
  appendfilename "appendonly.aof"
  
  # no：不同步
  # everysec：每秒备份，推荐使用
  # always：每次操作都会备份，安全并且数据完整，但是慢性能差
  appendfsync everysec
  
  # 重写的时候是否要同步，no可以保证数据安全
  no-appendfsync-on-rewrite no
  
  # 重写机制：避免文件越来越大，自动优化压缩指令，会fork一个新的进程去完成重写动作，新进程里的内存数据会被重写，此时旧的aof文件不会被读取使用，类似rdb
  # 当前AOF文件的大小是上次AOF大小的100% 并且文件体积达到64m，满足两者则触发重写
  auto-aof-rewrite-percentage 100
  auto-aof-rewrite-min-size 64mb`

RDB と AOF を使用する必要がありますか?

一定期間キャッシュの損失を許容できる場合は、RDB を使用できます。

実際のデータに注意する場合は、RDB を使用できます。 -time data の場合は、AOF
• を使用します

• RDB と AOF を併用して永続化を実現します。RDB はコールド バックアップとして使用され、異なる時点で異なるバージョンを復元できます。AOF はホット バックアップとして使用され、データの損失が 1 秒だけであることを保証します。 。 AOF が破損して利用できない場合は、RDB を使用して復元し、2 つを組み合わせます。つまり、Redis の回復では最初に AOF がロードされ、AOF に問題がある場合は RDB が再度ロードされます。ホットおよびコールドバックアップの目的を達成します。

プログラミング関連の知識について詳しくは、プログラミング入門をご覧ください。 ！

以上がRedis の永続化メカニズムについて話しましょう。RDB と AOF のどちらを使用すべきでしょうか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。