初期状況
Amazonに8 TB EBSドライブ(ext4、パーティションなしで直接マウント))があります
私は何年もの間sw-raidを使用していなかったので、その方法でディスクを縮小できるという私の仮定は間違っているかもしれません。
ゴール
このEBSドライブを本番システムでライブで5TB(-3TB)に縮小したい
ドライブは常に100〜200mb /秒で書き込まれます(本番データベースとツール)
問題 AmazonはEBSの縮小を提供していません。私が見つけた(そして過去に使用した)唯一の解決策は、2番目のEBSを作成し、通常は「rsync」を使用してすべてをコピーすることでした。
それはオプションではありません。EBSは遅く、サイズが2TBを超えるファイル(データベースファイル)を永続的に変更するシステムがあることを考えると、rsyncは変更に追いつくことができませんでした。
アイデア EXT4 8TBディスクをRAID-1に「変換」することを考えました(最初は2番目のディスクがありません)。ディスクの最後にメタデータを追加するメタデータバージョンを使用します(そのためにファイルシステムを縮小することができます)。
最初の質問 8TBディスクのmd0を作成するときに、EXT4として再度マウントし、それがレイドディスクであることを無視するのを妨げるものはありますか?
私が理解したように、唯一の変更は、実際には「メタデータ」が追加(追加)されることです。したがって、「合法的に」通常のext4ディスクである必要がありますか?
本当 ?そして、それをMD0としてマウントし、それに書き込むとき、それはまだ本当ですか?
それがリスクのないことを考えると、2番目のディスクがない状態でmd0を作成し、それをマウントします(したがって、関連するサーバーの数分のダウンタイム)
ここで、ファイルシステムのサイズを3TB小さくしてから、mdadm --grow(shrink)md0を合計サイズ5TBに縮小します。
次に、2番目のEBSドライブ(5TB)を2番目のディスクとしてレイドに追加して同期させたいと思います。
2番目の質問それはできますか?そのように5TBのディスクを追加しますか?
番目の質問
今すぐ元の8TBディスクを取り外して、シングルディスクmd0を使い続けるか、md0のext4を直接マウントして、raidをまったく使用しないようにします。
Mdadmが適切でない場合、LVMは対応していますか? (ext4との互換性が維持されているようで、完了後に直接マウントに戻ることができるため、mdadmにアクセスしました。LVMでは不可能です)
長いテキストでごめんなさい。私は何かを逃したと思います。その問題を解決するためにmdadmを使用して言及された他の記事や回答がないほど簡単なことはありません。
冒険のための確かな計画のように聞こえます。あなたが説明した技術的な方法はしっかりしているように聞こえ、うまくいくはずです。それでもなお、これは別のマシンで事前にテストする必要があり、移行部分を検証するために、特に稼働している必要があるため、より多くの時間が必要になります。
上記の質問を読んだことによるいくつかのメモを要約します。
missing
ディスクを使用してRAIDを作成することは可能ですが、どのディスクがmissing
であるかを指定する必要があります。raid-1
の場合、これは通常のディスクとして扱うことができるという仮定は正しいと思います。 /dev/sd<x>
が使用されている限り、ブロックの複製とメタデータの更新、事実上レイドメカニズムはアクティブになりません。したがって、後で接続されたボリュームを同期するには、マウントを/dev/md<x>
に移行する必要があります。raid-1
ディスクを置き換えます。この段階では、上記の手順は関係ありません。/dev/<mdx>
の上にのみ作成することが重要です。実用的なヒント:このようなサイズのディスクで最近のext4ツールを使用してください。