これはなに？
伸縮自在なサイズ変更を使ってみて、
RedSfhitのノード数変更する際に3回転んだ話です。
伸縮自在なサイズ変更について
伸縮自在なサイズ変更 - クラスターにノードを追加または削除できます。DS2 ノードから RA3 ノードなど、ノードタイプを変更することもできます。伸縮自在なサイズ変更はすばやい操作で、通常は数分で完了します。このため、最初のオプションとしてお勧めします。伸縮自在なサイズ変更を実行すると、データスライスを再分配します。データスライスは、各ノードにメモリとディスク領域に割り当てられるパーティションです。伸縮自在なサイズ変更は、次のような場合に適しています。
簡単にまとめると
- ノードタイプを変更
- すばやい操作で、通常は数分で完了
- ほとんどのクエリが保持
最高か？？
やりたいこと
ra3.xlplus 2ノードで経っているRedSfhitを処理が増える数日だけra3.xlplus 8ノードにしたい！
- 常に動いているRedSfhit且つ、定期的なリサイズなため「従来のサイズ変更」での変更は避けたい
実際にやってみた
むむ
困ったその① 変更先ノード数の制限
ra3.xlplusのノード数を変更する際、変更先のノード数は2倍もしくは1/2が選択肢となります。
つまり2ノードで動いているRedSfhitは4ノードのみが選択肢になります。
仕様上の問題と分かり次の手段へ。
困ったその② 元のクラスターを基準にノード数が決まる
変更先が２倍にしかできないのであれば、
一度4ノードに上げてから8ノードにするという２段階でノードを増やす手段を考えました。
2ノード → 4ノード → 8ノード
が、
実際やってみたがまたもや失敗。
ソース vs ターゲットクラスターサイズ - 伸縮自在なサイズ変更によってサイズ変更可能なノード数と種類の設定は、元のクラスターのノード数と、サイズ変更したクラスターのターゲットノードタイプによって決まります。
https://docs.aws.amazon.com/ja_jp/redshift/latest/mgmt/managing-cluster-operations.html#rs-resize-tutorial
私は完全にドキュメントのこの言葉の意味を履き違えていました。
「変更前」＝「元のクラスター」ぐらいだと思い、2段階に分ければ問題ないと思っていました。
ここでいう「元のクラスター」は建てたタイミングで選んだノード数を基準とするため、ra3.xlplus、２ノードを４ノードにしたところで変更できる範囲は変わりませんでした。
困ったその③ 元のクラスターを思ったより引きずる
ここまできたら最終手段、
スナップショットから復元して新しくRedSfhitを建ててしまおう！！！！
建てたタイミングで選んだノード数を基準とするのであれば、
スナップショットから復元する際にra3.xlplus 4ノードを選択して、建ててみた。
しかし、スナップショットからのリストアする時点ですでに4ノードまでしか選べない。（本来であれば2～16で選択可能）
不安に思いながらリストアしたが、結果は最大ノード数は 4 のままとなり、
失敗。
AWSサポートにも聞いてみたが、
やはり、スナップショットから復元しても元々のクラスターノード数をそのままスライドしまうのは仕様らしい。
「伸縮自在なサイズ変更」では、求めていることはどうしても厳しそうなので「従来のサイズ変更」を使うことを進められました。
一度「従来のサイズ変更」を使えば、「元のクラスターノード数」も更新される。
知ってたら得するかも？
もし今後、ra3.xlplus 2ノードを建てることがあれば、
ra3.xlplus 4ノードで建てて、ノード数をダウンさせてからra3.xlplus 2ノードにしよう。
そうすればra3.xlplus 4ノードが基準となるため、2ノードや8ノードへ柔軟に変更が可能となる。