NFSの機能を使って疑似静止点を作る方法の考察

xfs_freezeコマンドはファイルシステム自体への書き込みをブロックしてしまう（readは可）ので、業務サーバからの書き込みをブロックしてrsyncによるバックアップ（ソースボリュームに対してはreadだけ）は可能。ただし、ｒｓｙｎｃが終わるまでの間はデータボリュームに書き込みができないのでダウンタイムになる。一方、xfs_freezeコマンドはLVMスナップショットの取得もブロックされてしまう（っぽい）ので、短時間のダウンタイムで済むスナップショット取得をxfs_freezeコマンドの組合わせで静止点を取得してスナップショットからバックアップ取得するシナリオもうまくいかない。

なので、NFS機能を使って、プロセスやユーザに対して選択的に書き込みをブロックできないだろうか。

業務プロセスがNFS領域に書き込み中にNFSエクスポートを停止することはできるのか？

gracefulに書き込み中プロセスだけ書き込み完了を待って以降の書き込みをブロックできないか？

lsofやfuserでファイルシステム上のファイルをopenしてないタイミングを監視してだれもopenしてないタイミングでＮＦＳエクスポートを停止してパシャッとスナップショットを取れないか？

（→20200918追記nfsサーバがexportしてる領域内のファイルでnfsクライアント側で書き込み中のファイルをnfsサーバ上で発行したlsofやfuserでは確認できない。nfsクライアント上で発行したlsofやfuserでは確認できる）

nfsサーバ側の設定でファイルをロックできないか？

あるいは、ＮＦＳレイヤーでなくファイルシステムレイヤーで、書き込みが無いタイミングを見つけてファイルシステムをread onlyでリマウントしてスナップショットをパシャッと取るとか、

あるいは、ファイルが壊れるのを承知でスナップショットを取得してバックアップを取得して、スナップショットからバックアップへのコピー完了後に、xfs_freeze＋rsyncを組み合わせてもう一回おかわりバックアップで仕上げるとか。

→スナップショットがソースのrsyncバックアップにソースボリュームがソースのおかわりバックアップ

→snapperとLVMシンスナップショットを使ったクールなデータバックアップ

連続書き込み中のファイルに対するrsyncの挙動確認

【お題１】 rsyncによる増分バックアップ その１のつづき

１．ddコマンドで連続書き込みされているファイルに対する挙動

２．cpコマンドで連続書き込みされているファイルに対する挙動

１．ddコマンドで連続書き込みされているファイルに対する挙動

# mount | grep test
/dev/mapper/src-testlv on /testlv type xfs (rw,relatime,seclabel,attr2,inode64,noquota)
/dev/mapper/dst-testlv_bk on /testlv_bk type xfs (rw,relatime,seclabel,attr2,inode64,noquota)

# ll /testlv
合計 4
drwxr-xr-x. 25 root root 4096  9月  7 04:59 1

# ll /testlv_bk
合計 4
drwxr-xr-x. 25 root root 4096  9月 14 20:41 1

・試し打ち

# time dd if=/dev/zero of=/testlv/hoge count=10000 bs=1024k
10000+0 レコード入力
10000+0 レコード出力
10485760000 バイト (10 GB) コピーされました、 40.2597 秒、 260 MB/秒
real    0m40.262s　　　←約40秒くらいかかる
user    0m0.006s
sys     0m5.857s

※ちなみに/dev/src/testlv（リニア論理ボリューム）にスナップショットがあると5分40秒だった

・上記で作成した10GBのhogeを一旦削除

# rm -f /testlv/hoge

・rsyncする

# time rsync -auvh /testlv/ /testlv_bk/ > /dev/null

sent 5.30M bytes  received 106.45K bytes  166.22K bytes/sec
total size is 44.74G  speedup is 8,281.26
real    0m32.020s
user    0m1.509s
sys     0m5.475s
※/testlv_bkは/testlvのバックアップなので差分はない

もういっかい

# time rsync -auvh /testlv/ /testlv_bk/ > /dev/null
real    0m1.080s
user    0m0.574s
sys     0m0.616s

・src上にddで10GBコピーを開始して3秒後にrsyncを実行する

# dd if=/dev/zero of=/testlv/hoge count=10000 bs=1024k &  { sleep 3;time rsync -auvh /testlv/ /testlv_bk/ > /dev/null; }

[1] 4485
10000+0 レコード入力
10000+0 レコード出力
10485760000 バイト (10 GB) コピーされました、 42.1591 秒、 249 MB/秒
[1]+  終了                  dd if=/dev/zero of=/testlv/hoge count=10000 bs=1024k
real    0m54.714s
user    0m15.342s
sys     0m8.298s

# ll /testlv
合計 10240004
drwxr-xr-x. 25 root root        4096  9月  7 04:59 1
-rw-r--r--.  1 root root 10485760000  9月 16 07:59 hoge
# ll /testlv_bk
合計 2800644
drwxr-xr-x. 25 root root       4096  9月  7 04:59 1
-rw-r--r--.  1 root root 2867855360  9月 16 07:59 hoge

→rsyncは静止点とってくれない

・おかわりでrsyncする

# time rsync -auvh /testlv/ /testlv_bk/ > /dev/null

real    1m5.256s
user    0m42.979s
sys     0m12.760s
# ll /testlv
合計 10240004
drwxr-xr-x. 25 root root        4096  9月  7 04:59 1
-rw-r--r--.  1 root root 10485760000  9月 16 07:59 hoge

２．cpコマンドで連続書き込みされているファイルに対する挙動

・いったん消す

# rm -f /testlv/hoge2 /testlv_bk/hoge2

・src上に10GBのファイルコピーを開始して3秒後にrsyncを実行する

# { time cp /testlv/hoge /testlv/hoge2; } & { sleep 3;time rsync -auvh /testlv/ /testlv_bk/ > /dev/null;echo $?; }
[1] 4538

real    0m48.119s　　←rsyncが先に終わった
user    0m12.611s
sys     0m4.538s
0　　　　　　　　　　　　　←正常終了

#
real    2m7.616s　　　←こっちはcpコマンド
user    0m0.061s
sys     0m9.873s

# ll /testlv
合計 28350912
drwxr-xr-x. 25 root root        4096  9月  7 04:59 1
-rw-r--r--.  1 root root 10485760000  9月 16 07:59 hoge
-rw-r--r--.  1 root root 10485760000  9月 16 08:20 hoge2
# ll /testlv_bk/
合計 12907780
drwxr-xr-x. 25 root root        4096  9月  7 04:59 1
-rw-r--r--.  1 root root 10485760000  9月 16 07:59 hoge
-rw-r--r--.  1 root root  2731802624  9月 16 08:18 hoge2

→rsyncは静止点とってくれない

・おかわりでrsyncする

# time rsync -auvh /testlv/ /testlv_bk/ > /dev/null
real    1m41.749s
user    0m43.572s
sys     0m15.621s

# echo 3 > /proc/sys/vm/drop_caches
# time md5sum /{testlv,testlv_bk}/hoge2

26f56024ac39cdc54b228820107f040d  /testlv/hoge2
26f56024ac39cdc54b228820107f040d  /testlv_bk/hoge2
real    2m17.827s
user    1m1.285s
sys     0m7.487s

→10GBのファイル2個のmd5sum所要時間は2分18秒だった。

※ちなみにマシンスペックは物理コア2論理コア2の4コア、 Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz

㊥【お題10】 MongoDBデータオンラインバックアップの諸検証

【お題3～8～】LVMスナップショットを使った増分バックアップの続きのブレークダウン

MongoDBデータオンラインバックアップにLVMスナップショットボリュームとrsyncを使った増分バックアップの諸検証を行う

１．Linuxファイルシステムの静止点の復習

1-1.xfs_freezeコマンドの動作

　→xfs_freezeコマンドはxfsファイルシステム自体への書き込みを禁止してしまう（readは可）

　　ので、書き込み中のwriteIOもブロックしてしまうし、バックアップユーザはソースデータに

　　関してはreadだけなのでrsync単体なら可能だが、xfs_freezeとLVMスナップショット取得

　　はLVMスナップショットが壊れてしまう（っぽい）のでxfs_freezeで書き込み静止点を作って　

　　LVMスナップショット取る方法は不可っぽい。

２．MongoDBオンラインバックアップに関する考察

2-0.MongoDBのバックアップ方式

①Back Up with Atlas

　※オンプレミスやプライベートクラウド上のMongoDBホストでは利用不可

②Back Up with MongoDB Cloud Manager

　※MongoDBクラウド上にあるManagerを使ってバックアップをする

③Ops Manager

　※有償版でのみ利用可能。Ops Managerを立てる。Ops ManagerとMongoDBとの間でデータ

　　送受信が発生する。

④MongoDBデータ（/var/lib/Mongoなど）を物理コピー

⑤mongodump

　※大規模データベースでは非推奨

2-1.collectionファイル内の1ドキュメントだけを変更した場合でもrsyncではファイル単位で増分コピーになるか？

2-2.MongoDBの静止点とは？「トランザクションとか」

2-3.MongoDBのチェックポイントとは？

　→チェックポイント時間外にDBデータの物理バックアップ（ファイルコピー）しちゃえばそれって自動的に静止点とれてんじゃね？

2-4.MongoDBのVer.4以前と以降の違い

2-5.MongoDBのシャーディングとバックアップの絡み

2-6.ストレージエンジン(wireTiger)とバックアップの絡み

2-7.MongoDBのデータ圧縮との絡み

　※データ圧縮することでメモリ使用量も節約できるのでディスク上のデータも圧縮して保存

　　するという考えがあるらしい。当然バックアップ対象のデータもそのまま圧縮した状態で

　　行う方がお得なはず

2-8.MongoDBのディスク暗号化機能とバックアップの絡み

2-9.MongoDBのPITR

2-10.RDB（PostgreSQL）の静止点とMongoDBの静止点の考え方の違いの考察

３．上記１．と２．を踏まえたMongoDBオンラインバックアップをLVMスナップショットなどで静止点を取得して行うことの有効性と問題点について考察

ていうかー。もうオンラインバックアップあきらめてMongoDBを一瞬落として、その間にLVMスナップショットを1秒でパシャッととって、すぐ上げればよくね？

ていうか、スクラッチでMongoDBの静止点を取得するスクリプトを作成しても、設定、バージョンアップ、モジュールの変更（ストレージエンジンなど）、ユーザがトランザクションを使うかどうか、replicasetやシャーディングの有無などの変更後も間違いなく静止点を取れるのだろうか？

MongoDBのバックアップマニュアルでファイルコピーでオンラインバックアップする方法をもう一度よく読んでみ

Back Up and Restore with Filesystem Snapshots