84
61

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

Redisデータ永続化の種類とサービス稼動時の切り替え注意点

Last updated at Posted at 2016-07-02

前提

以下は Redis 2.8 以降を前提としています

Redisのデータ永続化の種類

Redisではデータの管理手法として3種類あります。

・メモリでデータを管理する方式(揮発性ベース)
・特定のタイミングでデータをディスクに保存する方式(RDBベース)
・随時データをディスクに保存する方式(AOFベース)

'RDB'や'AOF'とすることでRedisを再起動してもはファイルからメモリにデータを読み込みなおすためデータの永続化がはかれる。というものです。

パフォーマンス劣化などの弊害もあるため、提供するサービスの内容とメリデメを見て選択することになります。

揮発性ベース

データをすべてメモリ内で保有して処理します。
Redisの再起動でデータがすべてロストしてしまうので、これが許容できるケースで利用します。

説明
メリット ・最高パフォーマンス
デメリット ・再起動でデータは全ロスト

設定例  :

    save ""

RDBベース

指定したタイミングでデータをファイルに保存します。(非同期スナップショット)
Redisの再起動において軽微なデータロストが発生するので、それが許容できるケースで利用します。
Redisの'save'ディレクティブで保存タイミングを設定します。

説明
メリット ・高パフォーマンス
デメリット ・再起動で保存前の更新データがロストする

設定例  : save [□□秒以内に保存] [〇〇回更新後]

    dir /var/run/redis              # RDB/AOFの格納ディレクトリを指定する
    dbfilename 6379.rdb             # RDBのファイル名を指定する
    rdbcompression yes              # RDBの圧縮要否を指定する
    save 900 1                      #      1回の更新後 900 秒以内に同期する
	save 300 10                     #     10回の更新後 300 秒以内に同期する
    save 60 10000                   # 10,000回の更新後  60 秒以内に同期する

AOFベース

常にデータをファイルに保存します。(デフォルトは秒単位の保存なので"ほぼ"同期保存となります)
データロストが許容できないケースで利用します。
RDBベースと並行稼動できますが、正直メリットは感じられません。

説明
メリット ・データ毀損が(ほぼ)無い
デメリット ・低パフォーマンス(50〜100倍程度のレスポンス遅延)
・リソース大量消費(データ保存時に格納サイズの倍以上のメモリが必要)

設定例  :

    dir /var/run/redis              # RDB/AOFの格納ディレクトリを指定する
    appendonly yes                  # AOFの利用要否を指定する
	appendfilename 6379.aof         # デフォルトは appendonly.aof となる
    appendfsync everysec            # デフォルトで秒単位に同期する(中速で動作する)
    # appendfsync always            # 常に同期する(低速だが安全に動作する
    # appendfsync no                # OSに任せる(高速に動作する)
    auto-aof-rewrite-min-size 32mb  # AOFのファイルサイズが32MByte以下はリビルド(最適化)の対象外とする
    auto-aof-rewrite-percentage 100 # AOFのファイルサイズが倍増(100%)した場合にリビルド(最適化)する

サービス稼動中の永続化方式変更時の注意点

稼働中のモード変更では、'CONFIG'コマンドによるサービス中のモード変更と設定ファイル(redis.conf)の変更をあわせてしておかないと運用時と再起動時の永続化モードの差異によって運用時のデータがロストしてしまう可能性があります。

データロスト事例

###(1)AOFからRDBに切り替えるケース
'AOF'稼動中のRedisをパフォーマンスを高めるため'CONFIG SET'コマンドで'RDB'に切り替えた。
あわせて設定ファイルも'RDB'に変更する予定だったが忘れた。
数日後のサーバ再起動で、設定ファイルが'AOF'ままだったので、'RDB'切り替え前の
古い'AOF'ファイルで起動されてしまい'RDB'で運用していた期間のデータが消えた。

###(2)RDBからAOFに切り替えるケース
'RDB'稼動中のRedisを、可用性を高めるため設定ファイルを'AOF'に切り替えた。
あわせて'CONFIG SET'コマンドで'AOF'に切り替える予定だったが忘れてしまった。
数日後のサーバ再起動で、期待どおりに'AOF'起動されたが'AOF'ファイルが存在せず、データなしで起動されてしまい'RDB'で運用されていた再起動前のデータがすべてロストしてしまった。
※ Redisは'RDB'と'AOF'の並行動作時、'AOF' > 'RDB' の優先順でデータを読み込みなおす

###(3)RDBからAOFに切り替えるケース
'RDB'稼動中のRedisの可用性を高めるため'CONFIG SET'コマンドで'AOF'に切り替えた。
あわせて設定ファイルも'AOF'に更新する予定だったが忘れた。(='AOF'で運用が継続された)
数日後のサーバ(Redis)再起動で誤った'RDB'設定で起動してしまい、古い'RDB'ファイルで起動された。
('AOF'に切り替え後のデータがすべてロストした)

最後に

Redisは利用する機能の特質上、どんどん更新情報が登録されていくものなので、サービス再開後の切り戻しは厳しい(できない!)ってことを念頭において、より上流工程で永続化方式を決定しておくべきですね。
仕方なく途中で変更する場合は、手順でしくらないよう注意したいと思います。

84
61
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
84
61

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?