Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up
![RDSでtrx_mysql_thread_idが0のトランザクションが残ってしまったときの対応方法 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/f777231a202c91be775887ddffd8aa76496b06fd/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9UkRTJUUzJTgxJUE3dHJ4X215c3FsX3RocmVhZF9pZCVFMyU4MSU4QzAlRTMlODElQUUlRTMlODMlODglRTMlODMlQTklRTMlODMlQjMlRTMlODIlQjYlRTMlODIlQUYlRTMlODIlQjclRTMlODMlQTclRTMlODMlQjMlRTMlODElOEMlRTYlQUUlOEIlRTMlODElQTMlRTMlODElQTYlRTMlODElOTclRTMlODElQkUlRTMlODElQTMlRTMlODElOUYlRTMlODElQTglRTMlODElOEQlRTMlODElQUUlRTUlQUYlQkUlRTUlQkYlOUMlRTYlOTYlQjklRTYlQjMlOTUmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPTEzODZiMzI4MjI2MTdkYmQ2Mjk1OWMzNzk4MWFlZGQ3%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBDa1JlYWwmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTVkODRhNWI1YmM0MzMwMmExMzI0NjZiMjhhYjliZTg3%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4gQ2xhc3Np5qCq5byP5Lya56S-%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%2523212121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3Dfbf28411651805f6a3c08274b295ebc2)
Wantedlyは今までRDSを初期設定のまま使っていました。ごめんなさい。 今回ちゃんとチューニングしてみたのでやってみた過程と結果を書きます。 ちなみにWantedlyはDBを幾つか持っていて、その中のDBの一つの最適化結果です。 NewRelic での測定の結果、平均31ms ぐらいかかっていたのが、 平均23ms ぐらいになっているので25%ぐらいの改善になりました。 インスタンスタイプ 使っているDBのインスタンスタイプです モデル: r3.4xlarge vCPU: 16 メモリ: 122GB SSDストレージ: 1 x 320G デフォルト値 RDSはパラメータグループを調節します。 それぞれのデフォルト値は書かれてないですが、以下のSQL出だすことができます。 => SELECT name,setting,unit FROM pg_settings; name | sett
今回は、まだ全然底が見えていないAuroraのガチンコ検証となります。公式資料に、発表当初の簡単な検証数値もありますが、自分でやらないと理解できない部分が多くあるためです。 既にAuroraにするだけで従来より速くなる説は有力ですが、なぜ速くなるのか、どのような点に注意を払って運用すべきなのか、といったことを理解するために、より局所的な検証をいくつか行って考察していきたいと思います。 目次 楽しい検証になって長くなりましたので、目次を置いておきます。 はじめに クエリのレスポンスタイム クエリキャッシュ CPU利用率とIOPSの性質 データ容量とストレージ性能の関係 インスタンスタイプとストレージ性能の関係 運用面の色々 何がボトルネックになるか はじめに いくつか前提的なものを。 ベンチマークは全て、sysbench を使ってテストデータ作成・ランダム参照/更新クエリを実行しています デ
CloudSQLの価格は実戦的という意味で、per Dayの価格を24hourで割った価格にしています。 メモリは2GBあれば検証としては十分なので格差は関係ありません。 IOPSはEBSならGeneral Purposeの1000GB*3で最大確保しています。 その他、ネットワーク周りなどポイントがあれば都度、補足していきます。 ベンチマークのデータ 今回、採取した全データはこちらになります。一部、目的に対して不要と判断したら省略しています。まぁ、こんなオレオレメモデータを見ても楽しくないでしょうから、1つ1つ考察していきましょう。 手法について 私がよくやる計測方法なのですが、innodb_buffer_pool_size がデータ容量より大きい健全な状態と、最小の16MBで過負荷ストレージを演出し、それぞれで参照/更新を別々にランダムアクセスをすることで、最初のボトルネックを炙り出し
この投稿は AWS Advent Calendar 2014 の 22日目の記事です。 RDS で MySQL を運用中に、想定外の CPU スパイクに悩まされたことがありましたので纏めておきます。 まずは、CloudWatch のグラフを見てみましょう。 所々で CPU スパイクが発生しているのがわかるかと思います。一見すると法則性がないようにも見えます。一般的には CPU リソースを消費する要因としては、アクセス過多やバッチ処理などで負荷をかけたケースが殆どです。しかし、今回のケースはユーザー側では何も負荷をかけておらず、RDS へのアクセスがゼロのサーバーでも同様の CPU スパイクが発生することがわかりました。 CPU スパイクの原因は? では、CPU スパイクの原因は何だったのでしょう?その後の調査で「RDS の定期メンテナンスジョブ」が原因であることがわかりました。 以下、メン
構成図 実装(という程ではないけど) Read Replica の分散 HAProxy の設定は以下のように。 global log 127.0.0.1 local0 log 127.0.0.1 local1 notice maxconn 4096 daemon defaults log global option dontlognull retries 3 maxconn 2000 timeout connect 5000ms timeout client 50000ms timeout server 50000ms listen mysql bind 0.0.0.0:3306 mode tcp option mysql-check user monitor balance leastconn server read01 hogehoge-replica.xxxxxxxxxxxxx.ap
ウィスキー、シガー、パイプをこよなく愛する大栗です。 re:Invent 2014の注目新機能の一つであるRDSの新エンジン"Aurora"のPreviewが通ったので試してみました。 本内容はRDS for AuroraのPreview中の内容となります。正式リリース後の内容とは異なる可能性がありますので、ご注意下さい。 Aurora re:Invent 2014のKeynoteで発表されたAuroraの特徴を確認しておきましょう。AuroraはMySQL 5.6と互換性があり、高速、かつ可用性と耐久性があり、高いスケーラビリティもある、AWSが3年をかけて開発したRDBMSです。 AWSがsysbenchを使用した結果では通常のMySQLに比べて5倍のパフォーマンスが出たという、恐ろしく速いDBなので皆さんが注目しています。 Auroraを起動する Auroraのドキュメントを元にAu
開発コストは掛かったでしょうから、さすがにMySQLと同価格、とは行かなかったようですが、概ね1.2倍強の価格で提供されています。詳しくは料金表を御覧ください。 ちなみに、インスタンスクラスの選択肢は、現状上記5種類のようです。開発環境用にt2シリーズも欲しいですねぇ…。 MySQL 5.6からのマイグレーション マイグレーションには2つの選択肢があります。1つ目は「mysqldump & mysqlimport」、単純にダンプして、それをAuroraに食わせればいいんですね。見た目にも分かりやすいです。 もう一つはMySQLのDBスナップショットからAuroraのインスタンスを立てることもできるようです。これは簡単。 制限事項としては2つ。MyISAMエンジンを使っている場合は、予めInnoDBに変換しておく必要があります。そもそもRDS for MySQLでは推奨されていなかったエンジ
Amazon SageMaker Geospatial Capabilities Now Generally Available with Security Updates and More Use Case Samples At AWS re:Invent 2022, we previewed Amazon SageMaker geospatial capabilities, allowing data scientists and machine learning (ML) engineers to build, train, and deploy ML models using geospatial data. Geospatial ML with Amazon SageMaker supports access to readily available geospatial dat
はじめに ウィスキー、シガー、パイプをこよなく愛する大栗です。 先日RDSでGeneral Purpose (SSD) Storageが選択可能になりました。 高速なSSDが使用可能になったためベンチマークしてみました。以前と同様にRDSのベンチバークをしてみました。 General Purpose (SSD) Storageとは? General Purpose (SSD) Storageとは通称gp2と呼ばれ、最大で3,000 IOPSの性能を発揮でいるSSDストレージです。「最大」という所がポイントです。本来の性能はディスクサイズ(GB)の3倍のIOPSの性能になるのですが、I/O クレジットを貯める事でI/Oを3,000IOPSまでバーストできます。 ディスクの種類にはMagnetic (Standard)、General Purpose (SSD)、Provisioned IOP
はじめに こんにちは植木和樹です。本日10月17日付けでMySQL 5.5/5.6に対する脆弱性が発表されています。これはAWSのRDSも対象となっています。 AWS Developer Forums: 【参考日本語訳】MySQL 5.5 and 5.6 Security Advisory MySQL 5.5 and 5.6 Security Advisory 上記ページのリンク先にあるOracleの発表を読むと、「ユーザーパスワード認証なしに悪意のあるコードを実行できる」とあります。 訂正:2014/10/18 9:10 最初に公開した内容の一部に2点誤りがありました。 日本時間 10/18(土)に強制アップグレードされるインスタンスはPublicly Accessibleの設定に関係なく、セキュリティーグループが無条件解放になっているインスタンスが対象となります 日本時間 10/18(
2014 年 10 月 29 日午後 4 時 30 分 (大洋平標準時) - 更新 MySQL 5.1 のセキュリティ更新 MySQL 5.5 および 5.6 に関して Oracle が発表したセキュリティ上の問題のいくつかをこちら (http://www.oracle.com/technetwork/topics/security/cpuoct2014-1972960.html#AppendixMSQL) で確認しました。https://www.mysql.com/support/eol-notice.html で説明されているように、Oracle は 2013 年 12 月に MySQL 5.1 を Sustaining Support に移行し、パッチの提供を中止しました。MySQL のセキュリティと信頼性のパッチを引き続き受け取るには、MySQL 5.1 を実行しているお客様は、ア
(最終更新日: 2017/9/25) はじめに production 環境で MySQL 5.6 動かすためのパラメータ設計についてまとめました。この記事がカバーする内容は次のとおりです。 パラメータを設定するスクリプト。 各パラメータにおける変更するかどうかの判断基準。 想定されるメモリの消費サイズを算出してパラメータが妥当かどうか確認する方法。 サービスの状況に応じててきぎ読みかえてください。 【結論】パラメータグループ作成・パラメータ設定のスクリプト 結論として、パラメータグループを作成し、パラメータを設定する aws-cli のスクリプトを置きます。Amazon AWS の Web Console から設定することもできます。 #!/bin/sh # == パラメータグループ作成 aws rds create-db-parameter-group --db-parameter-gr
本番環境で RDS を運用して数ヶ月。いろいろ試して RDS のパフォーマンスを上げるコツがわかってきたのでまとめたいと思います。 ここで取り上げるコツは以下を前提にしています。 データベースは PostgreSQL (Multi-AZ 配置) Read よりも Write が多い 夜間のバッチ処理がピーク 1 レコードは小さいが、一度に書き込むレコード数は多い アプリケーションの特性によっては当てはまらないこともあるでしょうし、他の RDBMS では結果が違ってくると思います。そこを踏まえたうえで参考にしてください。 Availability Zone はどちらかに寄せる RDS の Multi-AZ は耐障害性を上げるために欠かせない機能で、本番環境では Multi-AZ 配置が推奨されています。 Multi-AZ 配置にすると物理的に独立した AZ (Availability Zon
Direct connect経由なFusion-IOとRDSはどっちが速いのかを繋いで、ベンチマークしてみた。 背景 目的 検証環境について TCP-Cについて ベンチマーク結果 コネクション時の通信帯域 MySQLサーバーのパラメーターの差異に関して 資料:セッティングパラメーター sysbench-lua 0.5について ベンチマーク結果 背景 RDBMSにおけるOLTP処理において、Fusion-io社のioDrive2はゲームなどを中心に非常に高い性能を示しており、各RDBMSのストレージとして採用されています。この事から、ioDrive2に匹敵する性能をクラウド求にられていくことが予想されます。 目的 本検証はハイブリッドクラウド環境において、ioDrive2搭載サーバの実運用性を検証することを目的としています。 EquinixにioDrive2を搭載した物理サーバを設置し、A
$ date 2014年 5月30日 金曜日 20時56分02秒 JST $ echo 'select now()' | mysql -h mysql.foobar.ap-northeast-1.rds.amazonaws.com -u admin -p Enter password: now() 2014-05-30 11:56:20 アンチパターン init_connect に "SET SESSION time_zone = 'Asia/Tokyo';"と書く →フェイルオーバー時にハマる (rdsadminユーザなどではTimezoneがUTCでないとダメ) ストアドプロシージャを入れて init_connect から呼ぶ 例)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く