【アップデート】Amazon RDS for SQL Serverでタイムゾーンが変更可能になりました
ウィスキー、シガー、パイプをこよなく愛する大栗です。
ほとんどのRDSではタイムゾーンをUTC以外へ設定可能でしたが、SQL Serverのみ設定が行なえませんでした。しかし、9/19（PDT）のアップデートでSQL ServerもタイムゾーンをUTC以外へ変更が可能になりましたので紹介します。
タイムゾーン設定
RDS for SQL Serverのタイムゾーンを設定可能になり、RDSの全てのDBエンジンでローカルタイムゾーンを設定できるようになりました。注意点としては、DBインスタンスの作成時しかタイムゾーンを設定できないことです。
| DBエンジン | 変更方法 | 備考 |
|---|---|---|
| Aurora | DBクラスタパラメータグループ | あとで変更可能 |
| MySQL | DBパラメータグループ | あとで変更可能 |
| MariaDB | DBパラメータグループ | あとで変更可能 |
| PostgreSQL | DBパラメータグループ | あとで変更可能 |
| Oracle | オプショングループ, rdsadmin_util.alter_db_time_zone コマンド | あとで変更可能 |
| SQL Server | 起動時に指定する | New! あとで変更不能 |
設定できるタイムゾーンは、以下の37個(2016/9/20現在)となっています。Windowsのtzutilコマンドでは100個以上のタイムゾーンに対応していますが、RDSではその中の一部となります。全タイムゾーンの一部ですが、実用上はあまり問題にならないでしょう。
| タイムゾーン | 標準時とのオフセット | 備考 |
|---|---|---|
| Alaskan Standard Time | (UTC–09:00) Alaska | |
| Atlantic Standard Time | (UTC–04:00) Atlantic Time (Canada) | |
| AUS Central Standard Time | (UTC+09:30) Darwin | |
| AUS Eastern Standard Time | (UTC+10:00) Canberra, Melbourne, Sydney | |
| Canada Central Standard Time | (UTC–06:00) Saskatchewan | |
| Cen. Australia Standard Time | (UTC+09:30) Adelaide | |
| Central America Standard Time | (UTC–06:00) Central America | |
| Central Asia Standard Time | (UTC+06:00) Astana | |
| Central Brazilian Standard Time | (UTC–04:00) Manaus | |
| Central Europe Standard Time | (UTC+01:00) Belgrade, Bratislava, Budapest, Ljubljana, Prague | |
| Central European Standard Time | (UTC+01:00) Sarajevo, Skopje, Warsaw, Zagreb | |
| Central Pacific Standard Time | (UTC+11:00) Solomon Islands, New Caledonia | |
| Central Standard Time | (UTC–06:00) Central Time (US and Canada) | |
| Central Standard Time (Mexico) | (UTC–06:00) Guadalajara, Mexico City, Monterrey | |
| China Standard Time | (UTC+08:00) Beijing, Chongqing, Hong Kong SAR, Urumqi | |
| E. Australia Standard Time | (UTC+10:00) Brisbane | |
| E. Europe Standard Time | (UTC+02:00) Minsk | |
| Eastern Standard Time | (UTC–05:00) Eastern Time (US and Canada) | |
| Georgian Standard Time | (UTC+04:00) Tblisi | |
| GMT Standard Time | (UTC) Dublin, Edinburgh, Lisbon, London | このタイムゾーンはGreenwich Mean Timeとは異なります。 このタイムゾーンは夏時間に対応しています。 |
| Greenland Standard Time | (UTC–03:00) Greenland | |
| Greenwich Standard Time | (UTC) Monrovia, Reykjavik | このタイムゾーンは夏時間に対応していません。 |
| Korea Standard Time | (UTC+09:00) Seoul | |
| Mountain Standard Time | (UTC–07:00) Mountain Time (US and Canada) | |
| Mountain Standard Time (Mexico) | (UTC–07:00) Chihuahua, La Paz, Mazatlan | |
| New Zealand Standard Time | (UTC+12:00) Auckland, Wellington | |
| Pacific Standard Time | (UTC–08:00) Pacific Time (US and Canada) | |
| Pacific Standard Time (Mexico) | (UTC–08:00) Baja California | |
| Singapore Standard Time | (UTC+08:00) Kuala Lumpur, Singapore | |
| Tokyo Standard Time | (UTC+09:00) Osaka, Sapporo, Tokyo | |
| Turkey Standard Time | (UTC+02:00) Istanbul | |
| Hawaiian Standard Time | (UTC–10:00) Hawaii | |
| US Eastern Standard Time | (UTC–05:00) Indiana (East) | |
| UTC | UTC | このタイムゾーンは夏時間に対応していません。 |
| W. Australia Standard Time | (UTC+08:00) Perth | |
| W. Central Africa Standard Time | (UTC+01:00) West Central Africa | |
| W. Europe Standard Time | (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna |
RDS for SQL Serverのローカルタイムゾーン設定の制限
- 既存のDBインスタンスのタイムゾーンは変更できません。
- スナップショットを異なるタイムゾーンでリストアすることはできません。
- バックアップファイルを異なるタイムゾーンへリストアしないことを強く勧めます。バックアップファイルを異なるタイムゾーンへリストアする場合は、タイムゾーン変更の影響についてクエリとアプリケーションを検証しなければなりません。
また、注意点としてPoint in Time Recovery(PITR)をする場合はUTCで指定をする必要があります。
ローカルタイムゾーンを試す
ローカルタイムゾーンの設定を試してみます。RDS for SQL Serverを起動します。ここではMicrosoft SQL Server Web Editionを起動します。
[DB 詳細の指定]の中に『タイムゾーン』という項目が増えています。Tokyo Standard Timeを指定します。他の項目は今まで通りに指定してください。
起動したDBインスタンスの詳細を確認するとタイムゾーンという項目が増えています。
実際にSQL Serverの中のタイムゾーンが変わっているか確認してみます。
SELECT GETDATE();を実行すると日本時間と同じ時刻が表示されます。
DBインスタンスのスナップショットを取得して、リストアしてみます。 リストア時にはタイムゾーンを指定できません。
リストアしたDBインスタンスでもSELECT GETDATE();を実行してみます。先ほどと同様に日本時間と同じ時刻が表示されます。
さいごに
RDS for SQL Serverがローカルタイムゾーンに対応して、全てのRDSでタイムゾーン設定が可能になりました。ただしSQL Serverでは既存のDBインスタンスの変更はできません。タイムゾーンをJSTなどにしたい場合は、新規構築時にタイムゾーンの設定を検討するか、バックアップファイルを使った移行で入念に検証しましょう。
