2022.08.02
STAFF BLOG
スタッフブログ
TECHNICAL
テクログ
今回は RDS Aurora クラスターの疎通確認を MySQL コンテナ経由で行う方法を紹介します。
大部分は以下参考元のままです。
参考元と違うのは、Docker コンテナを利用している点です。
これにより、Windows などでもすぐにチェックが可能です。
Docker で MySQL コンテナをバックグラウンド起動
MySQL コンテナを起動します。
docker run --rm -itd --env MYSQL_ROOT_PASSWORD="password" mysql
MySQL コンテナに入る
MySQL コンテナに sh で入ります。
docker exec -it (コンテナID) sh
MySQL コンテナ内でシェルスクリプトを実行
以下のようなシェルスクリプトをコンテナ内部で実行します。
シェルスクリプトの内容はほとんど参考元のままです。
最初の変数3つには、疎通確認したい DB の接続情報を値として指定します。
# !/bin/sh
# https://blog.serverworks.co.jp/rds-measure-downtime
# DB ホスト名
dbHost=""
# DB ユーザー名
dbUser=""
# DB パスワード
password=""
# 何秒間隔で疎通確認するか
sleepTime=5
mysqladmin ping -h ${dbHost} -u ${dbUser} -p${password} 2>&1 | grep alive > /dev/null 2>&1
if [ $? -eq 0 ]; then
echo "DB status is alive"
date
echo "---------"
dbStatus="alive"
sleep ${sleepTime}
elif [ $? -eq 0 ]; then
echo "DB status is dead"
date
echo "---------"
dbStatus="dead"
sleep ${sleepTime}
fi
## mysql に ping を飛ばす処理(2回目以降)
while true; do
mysqladmin ping -h ${dbHost} -u ${dbUser} -p${password} 2>&1 | grep alive > /dev/null 2>&1
if [ $? -eq 0 ]; then
if [ ${dbStatus} = "alive" ]; then
sleep ${sleepTime}
elif [ ${dbStatus} = "dead" ]; then
echo "DB status has been alive"
date
echo "---------"
dbStatus="alive"
sleep ${sleepTime}
fi
elif [ $? -eq 0 ]; then
if [ ${dbStatus} = "alive" ]; then
echo "DB status has been dead"
date
echo "---------"
dbStatus="dead"
sleep ${sleepTime}
elif [ ${dbStatus} = "dead" ]; then
sleep ${sleepTime}
fi
fi
done
実行すると、標準出力に以下のように文字が出力されます。
DB status is alive
Wed Jul 20 08:26:33 UTC 2022
---------
- それまでは接続できていたが、できなくなった
- それまでは接続できていなかったが、接続できるようになった
の2通りのタイミングで、新しく文字列が追加で表示される仕組みです。
どのような場面で使うのか
これまでの流れから予想できる通り、使いどころは DB にダウンタイムが発生するような状況です。
- RDS DB インスタンス/RDS Aurora クラスターのエンジンのアップグレードなどのダウンタイムが生じる作業時、どの程度のダウンタイムが生じたかを確認する
- テスト環境で確認しておけば、本番環境でどの程度サービス断が発生するかを推測できる
ただし、テスト環境と本番環境では DB のインスタンスのタイプが違う場合がほとんどです。そうなると、ダウンタイムもそれなりに変動するので、大まかな予測程度にしかなりません。
逆に言えば、同じインスタンスタイプの場合、ダウンタイムの予測には十分利用可能です。
まとめ
- MySQL コンテナを利用して、 RDS DB インスタンス/RDS Aurora クラスターの疎通確認ができる
- エンジンのアップグレードなどのダウンタイムが生じる作業時に、どの程度のダウンタイムが生じたかを確認する
- テスト環境で確認しておけば、本番環境でどの程度サービス断が発生するかを推測できる
- インスタンスタイプや台数が違うとダウンタイムもそれなりに変動するので、大まかな予測程度にしかならない
- 同じインスタンスタイプの場合、ダウンタイムの予測に十分利用可能
- テスト環境で確認しておけば、本番環境でどの程度サービス断が発生するかを推測できる