Amazon Aurora MySQLでテーブル再構築を伴う操作をするとテーブルが見えなくなるっぽい - GMOインターネットグループ グループ研究開発本部（次世代システム研究室）
2023.01.11 Amazon Aurora MySQLでテーブル再構築を伴う操作をするとテーブルが見えなくなるっぽい Amazon Aurora MySQLでテーブルの再構築を伴う操作を行うと，Readerインスタンスで瞬間的に対象のテーブルが見えなくなる場合があるので，オペレーションの実行タイミングに気をけましょう，というお話です。再構築を伴う操作には，一部のALTER TABLEやOPTIMIZE TABLEが含まれます。 こんにちは，S.T.です。Amazon Aurora MySQLで少し気になる現象を見かけたので紹介します。この現象を知っていれば回避できるので，クリティカルな影響があるということではないですが，将来直ってくれると嬉しいですね。 1.Amazon Aurora MySQLとは Amazon Aurora MySQLはAWSで利用できるマネージドのRDBです。コ
MySQL でショート／ロングトランザクション実行中のインデックス作成の影響 - ablog
MySQL (5.7 InnoDB) で本番稼働中にインデックス作成すると、対象テーブルにショートトランザクション実行中の場合は並行でできるけど、ロングトランザクションが実行中*1の場合は Waiting for table metadata lock (synch/cond/sql/MDL_context::COND_wait_status) で metadata lock を延々待ち続ける。DML はオブジェクト定義のメタデータに共有ロックを取り、DDL は排他ロックをかけるため、ロングトランザクションが実行中にインデックスを作成すると、そのトランザクションが終了するまで排他ロックを取れず待ち続ける。 環境 Aurora Mysql エンジンバージョン: 5.7.mysql_aurora.2.07.2 検証結果 sysbench を Amazon Linux 2 にインストールする A
クエリログを使ったAurora MySQLの負荷テスト - クックパッド開発者ブログ
最近はZX-25Rが気になっている菅原です。4気筒250ccといえば、以前バリオス2に乗っていたんですが、あれもよく回るよいバイクでした。足つきの良さが懐かしいです。 この記事では、クエリログを使ったAurora MySQLの負荷テストの話を書きます。 MySQLの負荷テスト サービスに使われているデータベースは、Webサーバと比べて自動的なスケールアップ・スケールアウトが簡単ではないためキャパシティプランニングは非常に重要です。サービスへのアクセス増による負荷増大の結果、急激に性能が低下するためなるべく事前にキャパシティを把握しておきたいところです。 クックパッドではサービスのデータベースとして主にAurora MySQLを利用しているのですが、キャパシティを把握するための負荷テストには以前から苦労してきました。 1. シナリオを書くのが大変 サービスで使われているデータベースの負荷テス
Amazon Aurora レプリカ では metadata lock 待ちが発生しない - mita2 database life
Amazon Aurora のレプリカは Vanilla MySQL のレプリケーションとは違った仕組みで実現されている。 マスターとレプリカは同じディスクボリュームを参照しており、マスターでの更新はほぼ即時レプリカに反映される。 DB クラスターボリュームは DB クラスターのデータの複数のコピーで構成されます。ただし、クラスターボリュームのデータは、DB クラスターのプライマリインスタンスおよび Aurora レプリカの 1 つの論理ボリュームとして表されます。この結果、すべての Aurora レプリカは、最短のレプリカラグでクエリの結果として同じデータを返します。 レプリカラグは、通常はプライマリインスタンスが更新を書き込んだ後、100 ミリ秒未満です。https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide
サーバーレスでAuroraの実行中クエリをCloudWatch Logsへ出力する | DevelopersIO
大栗です。 RDSで障害が発生する一因として、想定外に長時間実行しているクエリが邪魔になっていることがあります。RDS for MySQLやAuroraの場合はSlow Queryで長時間実行されたクエリは分かりますが、実行が完了したものしか出力されないため現在動いているものはshow processlist;を実行して実行中のクエリを確認する必要があります。監視システムで定期的にRDSにログインして実行すれば良いのですが、面倒なのでEC2を使わずに実装してみました。 全体概要 Auroraの場合は、ストアドプロシージャ経由でLambdaを実行できます。この機能とMySQLが持っているスケジュール機能を利用します。 AuroraのEvent Schedulerでinformation_schema.processlistの内容を取得してlambda_asyncを呼ぶ LambdaでPROC
AuroraのALTER TABLE性能検証とRDS比較 | 外道父の匠
よく、Auroraを採用しました、安定しています、移行してよかったです！とか見かけますけど、 なんで快適なのかをちゃんとわかって使ってんのかこの野郎ッp(｀･ω･´ﾒ)q 俺も全然わかってねぇッ( ･`ω･´) ということで、今回もいい感じに飽きてきたAuroraです。Aurora。少々気になっていた、ALTER TABLE周りについて興味深い数値が取れたので、その共有で御座います候。 MySQL5.6互換 AuroraはMySQL5.6互換というけれど・・・ Q:「MySQL と互換性がある」とはどういう意味ですか? これは、現在お客様が MySQL データベースで使用しているほとんどのコード、アプリケーション、ドライバー、ツールをほとんど、またはまったく変更を加えなくても Aurora で使用できることを意味します。Amazon Aurora データベースエンジンは InnoDB スト
カヤックでのAurora移行は「今のところいいことしかない」
11月2日に開催されたJAWS-UG横浜Rebootにおいて、RDS for MySQLからAuroraへの移行についてLTを披露したのが、面白法人カヤックの藤原俊一郎さん。Auroraの移行により、RDS for MySQLのたまにデータが詰まる問題やリードレプリカの難点が解消されたという。 マルチAZのMySQLがたまにつまる、リードレプリカの暖気がつらい ゲームや広告、Webサービスなど、ともかくバズるモノを作るのが得意な面白法人カヤック。古都鎌倉に本社を構えていることでも知られているが、最近は支社として“ヨコハマ展望台”オフィスができたこともあり、今回のJAWS-UG横浜の登壇につながったようだ。そんなカヤックの藤原俊一郎さんがLTで披露したのは、ソーシャルゲーム「ぼくらの甲子園」でのAurora移行話だ。 2014年9月にリリースされたぼくらの甲子園はプラットフォームとしてAWS
最強のDBを求めて、AWSのAuroraとMySQL5.7とGCPのGQLのv1,v2を比較し直してみた - Qiita
もう一度最強のDBを求めて 前回まで MySQL5.7 > Aurora 遅いと噂のGQL > RDS と、上のような結果が出てみたもののどうにも自分で調べておいて検証結果が信用できない。 データ容量と同時接続数を増やしてみてもう一度チャレンジしてみた。 検証方法 sysbench --test=oltp --db-driver=mysql --oltp-table-size=100000000 prepare sysbench --test=oltp --db-driver=mysql --oltp-table-size=100000000 --num-threads=XXX --oltp-read-only=off run 取りあえず手軽に試してみたかったので、sysbenchで実行してみる。 登録データ件数は1億件。容量にして約20GB。 同時接続数を4→8→16→32→64と増やし
密着 24時！ MySQL 5.1 から Aurora への移行100日間 〜 Backlog 編 | 株式会社ヌーラボ(Nulab inc.)
Photo via Visual hunt Backlog の一部のスペースにて Amazon Aurora へと移行しました。ここでは、その経緯と実際に実施した作業を簡単にご紹介させていただきます。 移行の経緯 昨年末データベース障害が発生しユーザー様には多大なご迷惑をお掛けしてしまいました。 Backlog には Terraform をどう使っているかを紹介したブログ にあるように複数の運用環境があります。 その各々の環境の構築時期によって EC2 上で自前運用していた MySQL もあれば、RDS for MySQL もある、といった統一されていない状況でした。また EC2 上ではまだ MySQL 5.1 も稼働していました。 移行を検討するにあたり、優先したのは障害時の復旧が素早く出来ることと、少しでも運用の管理コストを下げることでした。Backlog のサーバは 100 台以上で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
innodb_read_onlyとread_onlyの違い - 備忘録
[Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証![[Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://cdn-ak-scissors.b.st-hatena.com/image/square/76ec8c9f8632133d1a009287a66f6102c6643cac/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fauroradeep-150322203758-conversion-gate01-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)