Redisの永続化をオンラインで設定する - Qiita$ redis-cli CONFIG SET appendonly yes OK $ redis-cli CONFIG SET save "900 1 300 10 60 10000" OK AOFがonの場合、起動時にAOFファイルを読み込んでデータを再構成するので先にオンラインで実行する必要がある。 RDBのみ設定する場合はBGSAVEでもRDBファイルはできるのでどちらでもいいが、再起動する手間も省けるしCONFIG SETで良い。 変更を確認
RedisにおけるRDBファイルのバックアップ | TECHSCORE BLOG | TECHSCORE BLOG
こんにちは、鈴木です。 Redis におけるバックアップとリストアについて調べました。 データを永続化する方法については「Redisにおけるデータの永続化」で調べました。 RDB ファイルのバックアップ RDB ファイルでのバックアップ手順は以下のようになると思います。 BGSAVE コマンドを実行する（非同期での RDB ファイルの生成が開始される）。 RDB ファイルの生成が完了するまで待機する（完了したかどうかは、LASTSAVE コマンドの結果が変化したことや、RDB ファイルの i-node 番号が変化したことで判別可能です）。 （redis-check-dump で生成された RDB ファイルに問題が無いことを確認する。） RDB ファイルをコピーする（別サーバなど Redis が動作するサーバがクラッシュしても安全な場所に保管する）。 上記を一日一回など、定期的に実行します。
主キーはインデックスではない - 設計者の発言
仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス（キー）というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
分割と整合性と戦う
