Amazon Aurora MySQL のパフォーマンスとスケーリングの管理 - Amazon Aurora
Aurora MySQL DB インスタンスのスケーリング Aurora MySQL DB インスタンスは、インスタンススケーリングと読み取りスケーリングの 2 つの方法でスケールできます。読み取りスケーリングの詳細については、「読み取りのスケーリング」を参照してください。 DB クラスター内の各 DB インスタンスの DB インスタンスクラスを変更することで、Aurora MySQL DB クラスターをスケーリングできます。Aurora MySQL は、Aurora 用に最適化された複数の DB インスタンスクラスをサポートしています サイズが 40 TB より大きい Aurora クラスターには、db.t2 または db.t3 インスタンスクラスを使用しないでください。Aurora MySQL でサポートされている DB インスタンスクラスの詳細な仕様については、「Aurora DB
Aurora Serverless MySQL の一般利用が開始 | Amazon Web Services
Amazon Web Services ブログ Aurora Serverless MySQL の一般利用が開始 クラウド向けに考案、構築され、MySQL や PostgreSQL と互換性のあるカスタムビルドのデータベース、Amazon Aurora については、すでにご存知の方も多かと思われます。また、インスタンスのことを考慮することなくアプリケーションおよびサービスを構築、実行できるサーバーレスをご存知の方も多いかと思われます。この 2 つのサービスは、成長を続ける AWS テクノロジーの一端を担うサービスであり、私たちはこのサービスに積極的に取り組んでいます。昨年の AWS re:Invent では、Aurora Serverless と呼ばれる Aurora の新機能のプレビューが発表されました。本日、Aurora MySQL 向け Aurora Serverless の一般利用
Amazon Auroraを真に理解するための性能検証 | 外道父の匠
今回は、まだ全然底が見えていないAuroraのガチンコ検証となります。公式資料に、発表当初の簡単な検証数値もありますが、自分でやらないと理解できない部分が多くあるためです。 既にAuroraにするだけで従来より速くなる説は有力ですが、なぜ速くなるのか、どのような点に注意を払って運用すべきなのか、といったことを理解するために、より局所的な検証をいくつか行って考察していきたいと思います。 目次 楽しい検証になって長くなりましたので、目次を置いておきます。 はじめに クエリのレスポンスタイム クエリキャッシュ CPU利用率とIOPSの性質 データ容量とストレージ性能の関係 インスタンスタイプとストレージ性能の関係 運用面の色々 何がボトルネックになるか はじめに いくつか前提的なものを。 ベンチマークは全て、sysbench を使ってテストデータ作成・ランダム参照／更新クエリを実行しています デ
いよいよAuroraを選択しない理由がなくなってきた | レコチョクのエンジニアブログ
Zero-Downtime Patching の機能が使えるようになりました No maintenance No Life なRDSに、遂にAuroraバージョン1.10からですがダウンタイムゼロでメンテナンスが実施できるようになりました。 https://aws.amazon.com/jp/blogs/aws/amazon-aurora-update-spatial-indexing-and-zero-downtime-patching/ PostgreSQL互換といい、Lambda連携といい(Lambda連携は動作保証が今のところ0回以上なので今後の改善に期待ですが1)、 そろそろAuroraを選択しない理由がなくなってきた感があります。 それでもAuroraを選択しない理由 t2.medium未満のインスタンスタイプで稼働可能なシステム コストをできるだけ節約したい場合 どうしてもb
ちょっと待って！Auroraを使う時にMulti-AZが本当に必要ですか？
ウィスキー、シガー、パイプをこよなく愛する大栗です。 Auroraへ移行するお話を頂くことが増えてきました。そこでAuroraへの移行時における冗長化のポイントを考えてみました。 RDSのSLA定義はMulti-AZが前提である旨を追記しました。 そもそもMulti-AZって？ ここではMySQLの場合のMulti-AZについて述べます。 Single-AZでは、以下の問題があります。 耐久性： ストレージボリュームで障害が発生した時には、「最新の復元可能な時刻」以降のデータ更新が失われる。 可用性： ハードウェア障害が発生した時に、インスタンスを再作成するため再接続までの時間が必要になる Auroraを除くRDSではストレージボリュームにEBSと同等のものが使用されているようなので通常のディスクに比べて高い可用性と信頼性を備えています。 補足すると、EBSについての具体的な数字としては「
Amazon Auroraの先進性を誰も解説してくれないから解説する - Qiita
TL;DR; Amazon AuroraはIn-Memory DBでもなくDisk-Oriented DBでもなく、In-KVS DBとでも呼ぶべき新地平に立っている。 その斬新さたるやマスターのメインメモリはキャッシュでありながらWrite-BackでもなくWrite-Throughでもないという驚天動地。 ついでに従来のチェックポイント処理も不要になったのでスループットも向上した。 詳細が気になる人はこの記事をチェキ！ Amazon AuroraはAWSの中で利用可能なマネージド(＝運用をAWSが面倒見てくれる)なデータベースサービス。 ユーザーからはただのMySQL、もしくはPostgreSQLとして扱う事ができるのでそれらに依存する既存のアプリケーション資産をそのまま利用する事ができて、落ちたら再起動したりセキュリティパッチをダウンタイムなしで(!?)適用したりなどなどセールストー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWS Black Belt Online Seminar 2017 Amazon Aurora
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス![[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス](https://cdn-ak-scissors.b.st-hatena.com/image/square/621590b3c7ee9e3370b81c3dfc99d0d34c4e6c55/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Famazonauroratips-170307140000-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)