元同僚が書いた「CloudSQL 2nd Generation性能評価」でいくつか疑問形になっていたので、面白がって調べてみたので捕捉したいと思います。

場所

データベースを作成時に、作成場所を選択します。

「すべて」という選択肢があります。

説明文に、「データの地域とゾーンを選択します。選択しない場合、ゾーンは「すべて」となり、Cloud SQL によって自動的に選択されます。」と解説があります。

「すべて」を選択すると、地域内にあるゾーンから1つをGoogle側のロジックで選択して、データベースインスタンスを作成してくれるようです。

メンテナンスの時間枠

メンテナンスの時間枠は、「メンテナンス時間内にインスタンスが自動的にシャットダウンし、再起動され、アップデートが適用されます。運用環境の更新は、数か月に一度ほどの割合で行われます。」と記載があります。

曜日を選択すると、時間を選択できるようになります。これはUIがちょっと微妙かもしれませんね。

ちなみにこのUIに気付いたのは、公式ドキュメントの説明に、「The day and hour when updates to this Cloud SQL instance can be made. 」と記載があったからです。hour選べないじゃん！と思ったけど、まさかね……と思いつつ選んだら、時間選択ウィンドウが表示された(;´･ω･)

メンテナンスは、指定した日時内で基本的には数分で完了します。
ただし、「The restart is not guaranteed to complete before the end of the maintenance window」と記載があるので再起動はメンテナンスウィンドウ内で実行するけど、再起動がこの時間内に完了することを保証してないようです。

料金

「Google Cloud料金計算ツール」と頭を突き合わせて調べてみました。

Compute

これは、「インスタンス料金」に記載されているとおりです。利用時間に応じてディスカウントが入るので、実際にいくらディスカウントされるかは計算ツールで確認しましょう。

ちなみに1ヶ月フルに使って、db-f1-microだと次のディスカウントです。

（例）0.015ドル/時間×730時間ー0.55－1.09－1.10＝7.67ドル/月

リードレプリカ（フェールオーバーレプリカ / High Availability）

これは、作成時にはまったく同じComputeインスタンスが設定されるようなので、お料金は単純に倍。

参考：How configuring an instance for high availability affects your charges

（例）7.67ドル/月×２＝15.34ドル/月

ストレージ料金

「ストレージ料金」に記載がある通り。

SSDだと、月1GBで0.17ドル。

バックアップ料金

月0.08ドル

フェイルオーバーレプリカ

MySQLの準同期レプリケーションで、オリジナル（Master）とは異なるゾーンにレプリケーションをします。

Masterが置いてあるゾーンが機能停止した場合、Cloud SQLは自動的にフェイルオーバーレプリカにフェイルオーバーし、クライアントへのデータ提供を継続します。First世代では組み込み機能でしたが、Second世代では開発環境のコストを減らせるように、high availabilityオプションとして提供します。

フィルオーバーすると、インスタンスに接続している既存コネクションは切断されます。同じ文字列またはIPアドレスを使用して再接続できるので、フィルオーバーが発生してもアプリケーションを変更せずにすみます。

フェイルオーバーすると、Masterに昇格し、自動的にほかのゾーンに新しいフェイルオーバーレプリカを作成します。

フェイルオーバーレプリカは、マスターからリード操作を減らすために、リードレプリカとして使用できます。フェイルオーバーレプリカは、データベース毎に１つだけ作成できます。さらに追加でリードレプリカを追加できます。ただし、リードレプリカはフェイルオーバーできるようにはなっていません。

レプリカのインスタンスサイズ

インスタンス作成後のレプリカタブで作成できます。

リードレプリカは、次のように自由にインスタンスサイズを設定できます。

しかい、フェイルオーバーレプリカは、Masterと同じインスタンスサイズが自動的に設定され変更はできない用です。

メンテナンス

https://cloud.google.com/sql/faq#maintenancerestart

We recommend that you design your applications to deal with situations when your instance is not accessible for short periods of time, such as in a maintenance shutdown.

てことで、ちょっとの時間アクセスできないぐらいで停止しないようにアプリケーション設計することを推奨だ！てことですね。メール連絡などについては特に言及なし。