ウィスキー、シガー、パイプをこよなく愛する大栗です。 Auroraへ移行するお話を頂くことが増えてきました。そこでAuroraへの移行時における冗長化のポイントを考えてみました。 RDSのSLA定義はMulti-AZが前提である旨を追記しました。 そもそもMulti-AZって？ ここではMySQLの場合のMulti-AZについて述べます。 Single-AZでは、以下の問題があります。 耐久性： ストレージボリュームで障害が発生した時には、「最新の復元可能な時刻」以降のデータ更新が失われる。 可用性： ハードウェア障害が発生した時に、インスタンスを再作成するため再接続までの時間が必要になる Auroraを除くRDSではストレージボリュームにEBSと同等のものが使用されているようなので通常のディスクに比べて高い可用性と信頼性を備えています。 補足すると、EBSについての具体的な数字としては「
前回のうるう秒が2015年7月1日でした。 今回は2016年12月31日の最後にうるう秒が追加されます。日本時間だと2017年1月1日の午前9時(正確には8時の最後に挿入)となります。 「うるう秒」挿入のお知らせ | NICT-情報通信研究機構2015年に実施されたときからまわりの環境は良くなっているので、うるう秒への対策簡単にとれるようになりました。このことについて、簡単にまとめておこうと思います。 ※ うるう秒について、詳しい解説が欲しい方は以前の記事を参照してください。 ー 閏秒を迎えるにあたってLinuxでは何を対策すべきか？ うるう秒対策済のNTPに設定を向ける結論から言うと、うるう秒対策が施されているNTPサーバにntpdの設定を向ける。というのが最近登場した簡単な方法です。 11/30にGoogleがうるう秒対策済のPublic NTPを公開しました。 Public NTP
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
