redisバックアップの2つの方法とメリットとデメリット
7441 ワード
Redis永続化のRDBとAOF Redisには、RDB(Redis DataBase)とAOF(Append Only File)の2つの永続化スキームがある.RDBとAOFを迅速に理解し、使用したい場合は、文章の下部に直接ジャンプしてまとめを見ることができます.この章では、プロファイル、スナップショットをトリガーする方法、データを復元する操作、コマンド操作のプレゼンテーション、メリットとデメリットを通じて、Redisの重点知識の永続化を学びます.
RDB詳細RDBはRedisのデフォルトの永続化スキームである.指定した間隔で、指定した回数の書き込みを行うと、メモリのデータがディスクに書き込まれます.すなわち、指定ディレクトリの下にdumpを生成する.rdbファイル.Redis再起動はdumpをロードする.rdbファイルはデータを復元します.
プロファイルからRDBがredisを開くことを知る.confファイル、SNAPSHOTTING対応コンテンツ1 RDBコアルール構成を見つけます(ポイント)
save
save “”
save 900 1 save 300 10 save 60 10000解説:save、条件を満たすとメモリのデータをハードディスクに同期します.デフォルトでは900秒以内に1つの変更があり、300秒以内に10つの変更があり、60秒以内に10000の変更がある場合は、メモリ内のデータスナップショットをディスクに書き込みます.RDBスキームを使用したくない場合は、save""のコメントを開いて、次の3つのコメントを開くことができます.
2ローカルデータベースのファイル名を指定します.一般的にデフォルトのdumpを使用します.rdb
dbfilename dump.rdb 3ローカルデータベース格納ディレクトリを指定し、一般的にデフォルト構成も使用します.
dir ./4デフォルトオープンデータ圧縮
rdbcompression yesの説明:ローカル・データベースに格納するときにデータを圧縮するかどうかを構成します.デフォルトはyesです.RedisはLZF圧縮方式を採用しているが,CPUの時間が少しかかっている.このオプションをオフにすると、データベース・ファイルが大きくなります.開くことを推奨します.
RDBスナップショット1をトリガ指定された時間間隔で、指定された回数の書き込み操作2を実行してsave(スナップショットの保存のみ、その他の待機)を実行するか、bgsave(非同期)コマンド3がflushallコマンドを実行し、データベースのすべてのデータをクリアすることは、意味がありません.4 shutdownコマンドを実行して、サーバーが正常に停止し、データが失われないことを保証します.意味もありません.
RDBファイルからデータを復元するdump.rdbファイルをredisのインストールディレクトリのbinディレクトリにコピーし、redisサービスを再起動すればよい.実際の開発では、物理機のハードディスクの破損を考慮して、バックアップdumpを選択するのが一般的である.rdb .以下の操作のプレゼンテーションから理解できます.
RDBの長所と短所:1大規模なデータ復旧に適している.2ビジネスがデータ整合性と一貫性に対する要求が高くない場合、RDBは良い選択です.
欠点:1データの整合性と一貫性は高くありません.RDBは最後のバックアップでダウンタイムになる可能性があります.2バックアップ時にメモリを使用します.Redisはバックアップ時に独立してサブプロセスを作成し、一時ファイルにデータを書き込み(メモリのデータは元の2倍ですよ)、最後に前のバックアップファイルを一時ファイルに置き換えます.だからRedisの持続化とデータの回復は夜が更けて人が静かな時に実行するのが合理的だ.
操作のデモ
第一歩:vimは持続化構成時間を修正し、120秒以内に5回修正すると1回持続化する.ステップ2:サービスを再起動して構成を有効にします.第3歩:それぞれ5つのkeyをセットし、2分後、binの現在のディレクトリの下でdumpを自動的に生産する.rdbファイル.(set key 6はshutdownがRDBスナップショットをトリガする役割を果たすことを検証するため)第4ステップ:現在のdump.rdbバックアップ1部(シミュレーションラインで動作).ステップ5:FLUSHALLコマンドを実行してデータベースデータを空にします(アナログデータが失われました).ステップ6:Redisサービスを再起動し、データを復元...あれ???( ′◔ ‸◔`).データが空です???これはFLUSHALLにもRDBスナップショットをトリガする機能があるからです.ステップ7:バックアップするdump_bk.rdb置換dump.rdbは次に再Redisする.
注意点:SHUTDOWNとFLUSHALLコマンドはRDBスナップショットをトリガーします.これはピットです.注意してください.
その他のコマンド:
keys*整合データベース内のすべてのkey saveブロックはRDBスナップショットをトリガし、そのバックアップデータFLUSHALLがRedisサーバ全体のデータ(ほとんど使わない)SHUTDOWNシャットダウンをクリアする(少ない)AOF詳細AOF:Redisはデフォルトでオンになっていない.RDBの不足(データの不一致)を補うために、ログ形式で各書き込み操作を記録し、ファイルに追加します.Redisが再起動すると、ログ・ファイルの内容に応じて、データのリカバリを完了するために、書き込みコマンドが前後に1回実行されます.
構成ファイルからAOFがredisを開くことを知る.confファイル、APPEND ONLY MODEの対応する内容を探し当てます1 redisはデフォルトで閉じて、開いて手動でnoをyesに変える必要があります
2ローカルデータベースファイル名を指定します.デフォルトはappendonlyです.aof
3更新ログ条件の指定
4書き換えトリガメカニズムの構成
解説:AOFファイルサイズが前回rewrite後のサイズの倍であり、ファイルが64 Mより大きい場合にトリガーされます.普通はすべて3 Gに設定して、64 Mは小さすぎます.トリガAOFスナップショットは、プロファイルに従ってトリガされ、実行ごとにトリガされ、毎秒トリガされ、同期されなくてもよい.AOFファイルに従ってデータが正常に回復する場合、appendonly.aofファイルをredisのインストールディレクトリのbinディレクトリにコピーし、redisサービスを再起動すればよい.しかし、実際の開発では、いくつかの理由でappendonlyが発生する可能性があります.aofファイルのフォーマットが異常で、データの復元に失敗し、redis-check-aof--fix appendonlyをコマンドすることができる.aofは修復を行う.以下の操作プレゼンテーションから体験します.AOFの書き換えメカニズムについても前述したように,AOFの動作原理は書き込み操作をファイルに追加することであり,ファイルの冗長性が増すことである.だから賢いRedisは書き換えメカニズムを追加しました.AOFファイルのサイズが設定した閾値を超えると、RedisはAOFファイルの内容を圧縮する.
書き換えの原理:Redisはforkから新しいプロセスを出し、メモリのデータを読み取り、一時ファイルに書き直します.古いファイルを読み込んでいません(あなたはそんなに大きくなったのに、私はまたあなたを読みに行きます???o(ﾟ)Дヽ(ﾟ)傻啊!).最後に古いaofファイルを置き換えます.
トリガメカニズム:AOFファイルサイズが前回rewrite後のサイズの倍であり、ファイルが64 Mより大きい場合にトリガされます.ここで「倍」と「64 M」はプロファイルで変更できます.AOFのメリットとデメリット:データの整合性と一貫性がより高いデメリット:AOF記録の内容が多いため、ファイルがますます大きくなり、データ復旧もますます遅くなります.操作のデモ
ステップ1:コンフィギュレーションファイルを修正し、AOF永続化コンフィギュレーションをオンにします.ステップ2:Redisサービスを再起動し、Redisが所有するクライアントにアクセスします.ステップ3:値を保存し、データ損失をシミュレートしてRedisサービスを閉じます.ステップ4:サービスを再起動し、データが回復したことを発見します.(ちなみに、FLUSHALLコマンドがAOFファイルに書き込まれ、データ復旧に失敗するチュートリアルがあります.私がインストールしたのはredis-4.0.2でこの問題に遭遇していません).ステップ5:appendonlyを変更します.aof、ファイル異常をシミュレートします.ステップ6:Redisサービスの再起動に失敗しました.これはまた、RDBとAOFが同時に存在し、AOFファイルを優先的にロードできることを示している.ステップ7:appendonlyを検証します.aofファイル.Redisサービスを再起動したら正常です.
补充点:aofの検査はredis-check-aofファイルを通じて、rdbの検査はredis-check-rdbファイルを通じて(通って)ことができますか??
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------2:RDB永続化は大規模なデータ復旧に適しているが、データの整合性と整合性が悪い.3:RedisはAOF永続化方式を手動でオンにする必要があり、デフォルトでは1秒あたりAOFファイルに書き込み操作ログを追加します.4:AOFのデータ整合性はRDBより高いが、記録内容が多くなると、データ復旧の効率に影響する.5:RedisはAOFファイルの大きな問題に対して、書き換えのダイエットメカニズムを提供します.6:Redisのみでキャッシュする場合は、永続化をオフにできます.7:Redisの永続化を使用する場合.RDBもAOFもオンにすることをお勧めします.実はRDBはデータのバックアップに適していて、後手を残しています.AOFに問題が発生しました.RDBもあります.ここまでRedisの永続化は紹介済みで、何か悪い点が指摘できる
RDB詳細RDBはRedisのデフォルトの永続化スキームである.指定した間隔で、指定した回数の書き込みを行うと、メモリのデータがディスクに書き込まれます.すなわち、指定ディレクトリの下にdumpを生成する.rdbファイル.Redis再起動はdumpをロードする.rdbファイルはデータを復元します.
プロファイルからRDBがredisを開くことを知る.confファイル、SNAPSHOTTING対応コンテンツ1 RDBコアルール構成を見つけます(ポイント)
save
save “”
save 900 1 save 300 10 save 60 10000解説:save、条件を満たすとメモリのデータをハードディスクに同期します.デフォルトでは900秒以内に1つの変更があり、300秒以内に10つの変更があり、60秒以内に10000の変更がある場合は、メモリ内のデータスナップショットをディスクに書き込みます.RDBスキームを使用したくない場合は、save""のコメントを開いて、次の3つのコメントを開くことができます.
2ローカルデータベースのファイル名を指定します.一般的にデフォルトのdumpを使用します.rdb
dbfilename dump.rdb 3ローカルデータベース格納ディレクトリを指定し、一般的にデフォルト構成も使用します.
dir ./4デフォルトオープンデータ圧縮
rdbcompression yesの説明:ローカル・データベースに格納するときにデータを圧縮するかどうかを構成します.デフォルトはyesです.RedisはLZF圧縮方式を採用しているが,CPUの時間が少しかかっている.このオプションをオフにすると、データベース・ファイルが大きくなります.開くことを推奨します.
RDBスナップショット1をトリガ指定された時間間隔で、指定された回数の書き込み操作2を実行してsave(スナップショットの保存のみ、その他の待機)を実行するか、bgsave(非同期)コマンド3がflushallコマンドを実行し、データベースのすべてのデータをクリアすることは、意味がありません.4 shutdownコマンドを実行して、サーバーが正常に停止し、データが失われないことを保証します.意味もありません.
RDBファイルからデータを復元するdump.rdbファイルをredisのインストールディレクトリのbinディレクトリにコピーし、redisサービスを再起動すればよい.実際の開発では、物理機のハードディスクの破損を考慮して、バックアップdumpを選択するのが一般的である.rdb .以下の操作のプレゼンテーションから理解できます.
RDBの長所と短所:1大規模なデータ復旧に適している.2ビジネスがデータ整合性と一貫性に対する要求が高くない場合、RDBは良い選択です.
欠点:1データの整合性と一貫性は高くありません.RDBは最後のバックアップでダウンタイムになる可能性があります.2バックアップ時にメモリを使用します.Redisはバックアップ時に独立してサブプロセスを作成し、一時ファイルにデータを書き込み(メモリのデータは元の2倍ですよ)、最後に前のバックアップファイルを一時ファイルに置き換えます.だからRedisの持続化とデータの回復は夜が更けて人が静かな時に実行するのが合理的だ.
操作のデモ
[root@itdragon bin]# vim redis.conf
save 900 1
save 120 5
save 60 10000
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> set key1 value1
OK
127.0.0.1:6379> set key2 value2
OK
127.0.0.1:6379> set key3 value3
OK
127.0.0.1:6379> set key4 value4
OK
127.0.0.1:6379> set key5 value5
OK
127.0.0.1:6379> set key6 value6
OK
127.0.0.1:6379> SHUTDOWN
not connected> QUIT
[root@itdragon bin]# cp dump.rdb dump_bk.rdb
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> FLUSHALL
OK
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> SHUTDOWN
not connected> QUIT
[root@itdragon bin]# cp dump_bk.rdb dump.rdb
cp: overwrite `dump.rdb'? y
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> keys *
1) "key5"
2) "key1"
3) "key3"
4) "key4"
5) "key6"
6) "key2"
第一歩:vimは持続化構成時間を修正し、120秒以内に5回修正すると1回持続化する.ステップ2:サービスを再起動して構成を有効にします.第3歩:それぞれ5つのkeyをセットし、2分後、binの現在のディレクトリの下でdumpを自動的に生産する.rdbファイル.(set key 6はshutdownがRDBスナップショットをトリガする役割を果たすことを検証するため)第4ステップ:現在のdump.rdbバックアップ1部(シミュレーションラインで動作).ステップ5:FLUSHALLコマンドを実行してデータベースデータを空にします(アナログデータが失われました).ステップ6:Redisサービスを再起動し、データを復元...あれ???( ′◔ ‸◔`).データが空です???これはFLUSHALLにもRDBスナップショットをトリガする機能があるからです.ステップ7:バックアップするdump_bk.rdb置換dump.rdbは次に再Redisする.
注意点:SHUTDOWNとFLUSHALLコマンドはRDBスナップショットをトリガーします.これはピットです.注意してください.
その他のコマンド:
keys*整合データベース内のすべてのkey saveブロックはRDBスナップショットをトリガし、そのバックアップデータFLUSHALLがRedisサーバ全体のデータ(ほとんど使わない)SHUTDOWNシャットダウンをクリアする(少ない)AOF詳細AOF:Redisはデフォルトでオンになっていない.RDBの不足(データの不一致)を補うために、ログ形式で各書き込み操作を記録し、ファイルに追加します.Redisが再起動すると、ログ・ファイルの内容に応じて、データのリカバリを完了するために、書き込みコマンドが前後に1回実行されます.
構成ファイルからAOFがredisを開くことを知る.confファイル、APPEND ONLY MODEの対応する内容を探し当てます1 redisはデフォルトで閉じて、開いて手動でnoをyesに変える必要があります
appendonly yes
2ローカルデータベースファイル名を指定します.デフォルトはappendonlyです.aof
appendfilename "appendonly.aof"
3更新ログ条件の指定
# appendfsync always
appendfsync everysec
# appendfsync no
4書き換えトリガメカニズムの構成
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
解説:AOFファイルサイズが前回rewrite後のサイズの倍であり、ファイルが64 Mより大きい場合にトリガーされます.普通はすべて3 Gに設定して、64 Mは小さすぎます.トリガAOFスナップショットは、プロファイルに従ってトリガされ、実行ごとにトリガされ、毎秒トリガされ、同期されなくてもよい.AOFファイルに従ってデータが正常に回復する場合、appendonly.aofファイルをredisのインストールディレクトリのbinディレクトリにコピーし、redisサービスを再起動すればよい.しかし、実際の開発では、いくつかの理由でappendonlyが発生する可能性があります.aofファイルのフォーマットが異常で、データの復元に失敗し、redis-check-aof--fix appendonlyをコマンドすることができる.aofは修復を行う.以下の操作プレゼンテーションから体験します.AOFの書き換えメカニズムについても前述したように,AOFの動作原理は書き込み操作をファイルに追加することであり,ファイルの冗長性が増すことである.だから賢いRedisは書き換えメカニズムを追加しました.AOFファイルのサイズが設定した閾値を超えると、RedisはAOFファイルの内容を圧縮する.
書き換えの原理:Redisはforkから新しいプロセスを出し、メモリのデータを読み取り、一時ファイルに書き直します.古いファイルを読み込んでいません(あなたはそんなに大きくなったのに、私はまたあなたを読みに行きます???o(ﾟ)Дヽ(ﾟ)傻啊!).最後に古いaofファイルを置き換えます.
トリガメカニズム:AOFファイルサイズが前回rewrite後のサイズの倍であり、ファイルが64 Mより大きい場合にトリガされます.ここで「倍」と「64 M」はプロファイルで変更できます.AOFのメリットとデメリット:データの整合性と一貫性がより高いデメリット:AOF記録の内容が多いため、ファイルがますます大きくなり、データ復旧もますます遅くなります.操作のデモ
[root@itdragon bin]# vim appendonly.aof
appendonly yes
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> set keyAOf valueAof
OK
127.0.0.1:6379> FLUSHALL
OK
127.0.0.1:6379> SHUTDOWN
not connected> QUIT
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> keys *
1) "keyAOf"
127.0.0.1:6379> SHUTDOWN
not connected> QUIT
[root@itdragon bin]# vim appendonly.aof
fjewofjwojfoewifjowejfwf
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
Could not connect to Redis at 127.0.0.1:6379: Connection refused
not connected> QUIT
[root@itdragon bin]# redis-check-aof --fix appendonly.aof
'x 3e: Expected prefix '*', got: '
AOF analyzed: size=92, ok_up_to=62, diff=30
This will shrink the AOF from 92 bytes, with 30 bytes, to 62 bytes
Continue? [y/N]: y
Successfully truncated AOF
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> keys *
1) "keyAOf"
ステップ1:コンフィギュレーションファイルを修正し、AOF永続化コンフィギュレーションをオンにします.ステップ2:Redisサービスを再起動し、Redisが所有するクライアントにアクセスします.ステップ3:値を保存し、データ損失をシミュレートしてRedisサービスを閉じます.ステップ4:サービスを再起動し、データが回復したことを発見します.(ちなみに、FLUSHALLコマンドがAOFファイルに書き込まれ、データ復旧に失敗するチュートリアルがあります.私がインストールしたのはredis-4.0.2でこの問題に遭遇していません).ステップ5:appendonlyを変更します.aof、ファイル異常をシミュレートします.ステップ6:Redisサービスの再起動に失敗しました.これはまた、RDBとAOFが同時に存在し、AOFファイルを優先的にロードできることを示している.ステップ7:appendonlyを検証します.aofファイル.Redisサービスを再起動したら正常です.
补充点:aofの検査はredis-check-aofファイルを通じて、rdbの検査はredis-check-rdbファイルを通じて(通って)ことができますか??
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------2:RDB永続化は大規模なデータ復旧に適しているが、データの整合性と整合性が悪い.3:RedisはAOF永続化方式を手動でオンにする必要があり、デフォルトでは1秒あたりAOFファイルに書き込み操作ログを追加します.4:AOFのデータ整合性はRDBより高いが、記録内容が多くなると、データ復旧の効率に影響する.5:RedisはAOFファイルの大きな問題に対して、書き換えのダイエットメカニズムを提供します.6:Redisのみでキャッシュする場合は、永続化をオフにできます.7:Redisの永続化を使用する場合.RDBもAOFもオンにすることをお勧めします.実はRDBはデータのバックアップに適していて、後手を残しています.AOFに問題が発生しました.RDBもあります.ここまでRedisの永続化は紹介済みで、何か悪い点が指摘できる