この記事は、LayerX Tech Advent Calendar 2024 の7日目の記事です。 tech.layerx.co.jp こんにちは。バクラクビジネスカード開発チーム エンジニアの iwamatsu です。 何か書くことないかな〜と頭を悩ませていたところ、見たことのない不思議なデッドロックに出くわしたので、今回はそれについて書こうと思います。 実行環境 バージョン: MySQL 8.0.39 ストレージエンジン: InnoDB トランザクション分離レベル: REPEATABLE READ 発生した事象 以下のようなユーザーテーブルがあるとします。 CREATE TABLE `users` ( `id` INT NOT NULL, `name` VARCHAR(255) NOT NULL, `lucky_color` VARCHAR(255) NOT NULL, PRIMARY
MySQL 8.0 は遅くなってきてる？何故？（２）
前のエントリの続きです。 念を押しておきますが、このブログの「内容は個人の考えであって、所属組織とは方針が異なる」と考えてください。 さて、MySQL 8.0.xの単スレッド性能がどんどん遅くなってきた要因は幾つかありそうなので切り分けていきたいと思います。 まずは、数年前のエントリ「やはりC++はCよりも遅い？」の影響をできるだけ正確に見積もりたいところです。実行バイナリの最適化レベルを合わせて比較して初めて、ロジックの劣化が判るわけです。コンパイラのオプションの範疇でできるだけ最大の最適化を行って計測したいところです。いくつか試した結果、clangのPGO+LTO が手軽な中では最も効果があったのでそれで同じ計測をしてみましょう。(GCCのPGO+LTO と clangのPGOのみ はこれよりも少し劣ったのでとりあえず。) (補足) PGO は、一旦ターゲットとなる処理をプロファイリン
MySQL 8.0 は遅くなってきてる？何故？（１）
いろいろありますが、今後のことを考える前にまずは、バージョン8.0.xの現状を一旦整理・理解してから決めようと思います。 念を押しておきますが、このブログの「内容は個人の考えであって、所属組織とは方針が異なる」と考えてください。 MySQL内部の人は、クラウドとか最新のサーバーとかしか利用していないのかも知れず、MySQL 8.0 が日に日に遅くなっていることに気づいていない人しかいないのでしょう。しかし、数年前のローカルPCで動かすと年々動作が鈍くなっているのを感じます。マイナーバージョンアップで単スレッド性能が下がり続けるなんて商用システムではリスキーです。 証明が難しく、ずっと放置せざるを得なかったのですが、非常に重要な事柄ですので今一度、オープンになっているソースを基に分析をしてみます。 まず、測るモノサシを決めましょう。以前のエントリ「MySQLバージョンアップによるInnoDB
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
データベースアップグレード後の性能劣化、イヤですよね。 去る2023年某日、弊社ではAmazon Aurora MySQL 互換エディション 2 (MySQL 5.7 互換) から Aurora MySQL 互換エディション 3 (MySQL 8.0 互換) にアップグレードしました。当時の背景やアップグレードに関する知見は以下の記事をぜひ読んでみてください。 blog.smartbank.co.jp ソフトウェアバージョンアップをするとき、旧バージョンが抱えていた問題の解決などの恩恵を我々は期待します。しかし時には予期せぬデグレーションに遭遇することもあります。我々のMySQL 8.0へのアップグレード前後においてもいくつかの問題に遭遇しました。 本記事ではそんな問題の一つ、MySQL 8.0のオプティマイザが選択したセミジョイン最適化が性能劣化を引き起こした事例と解決方法について紹介し
データアナリティクス事業本部のueharaです。 今回は、MySQL 8.0.32でテーブルをUNION ALLした際に生じるバグを共有したいと思います。 バグの事象 こちらで報告されている通り、MySQL 8.0.32では、UNION ALLをするとWHERE句で検索条件として日本語を指定すると、以下のようなエラーが発生して処理が落ちてしまいます。 Cannot convert string '\xE5\x8C\x97\xE6\xB5\xB7...' from utf8mb4 to binary したがって、次のような処理をすることが不可能になります。 WITH tmp_table AS ( SELECT name, data1 FROM table_a UNION ALL SELECT name, data1 FROM table_b ) SELECT * FROM tmp_table
Aurora MySQL でレコードが存在するのに SELECT すると Empty set が返ってくる事象を調査した話 こんにちは。 KINTO テクノロジーズの DBRE チーム所属の@p2skです。 DBRE（Database Reliability Engineering）チームでは、横断組織としてデータベースに関する課題解決や、組織のアジリティとガバナンスのバランスを取るためのプラットフォーム開発などを行なっております。DBRE は比較的新しい概念で、DBRE という組織がある会社も少なく、あったとしても取り組んでいる内容や考え方が異なるような、発展途上の非常に面白い領域です。 弊社における DBRE の取り組み例としては、あわっち（@_awache）による DBRE ガードレール構想の実現に向けた取り組みについてというテックブログや、今年の AWS Summit の登壇内容を
【2022/2/26 追記】 主にはてブコメントで様々なご指摘を頂いたので、タイトルの修正＆内容を一部追記しました。分かりにくいタイトルを付けてしまい申し訳ございません。ご指摘ありがとうございます。 もともと本記事は自分用のメモを兼ねて駆け出しエンジニアの人が数人参考にしてくれたらいいかな、程度の気持ちで書いたものでした。 現在はてなブックマークのテクノロジーカテゴリーで 1 位になっており、予想の 1000 倍以上の人に見ていただける記事になってしまいました。 今後も精進します、ありがとうございます！ 特に理由もなくローカルに MySQL を入れて遊びたくなる気持ちって定期的に湧きますよね。 私は湧きます、半年に 1 回ぐらい。 業務ではフロントを触ることが多く、DB はそれほど触りません。 そのため久々に MySQL をローカルで立ち上げようとするといつも手順を忘れてしまっていて、なん
こんにちは、freee Developers Advent Calendar 2021、19日目のid:shallow1729です。昨日はtdtdsさんで【マジで】サイバー演習シナリオの作り方【怖い】でした！障害訓練後に攻撃方法を解説された時はリアリティの高さに驚きました。 僕はMySQLを使っていて発生した不思議な挙動の調査の話をしようと思います。 今回問題となったクエリ 今回話題にするクエリは以下のようなシンプルなものです。 SELECT * FROM hoge WHERE id IN (...) MySQLのパラメーター次第ですが、デフォルトの設定だとこのIN句の中の値の数が数万になると適切なインデックスが用意されていてもフルスキャンが発生する事がありました。このクエリがテーブルのほとんどのレコードを網羅するような場合や高速でレコードを大量にinsertして統計情報が追いつかないケー
最近、MySQLのパラメータの調整をする機会があったのですが、特定のパラメータを変更した際に、メモリの消費量にどう影響するのか、というのを調査する際に、インターネッツを彷徨ったところ、サイトによって書いてあることにバラつきがあったので、自分でもまとめてみることにした。 結論から書くと、参考にしたのは以下のオライリーの書籍「MySQLトラブルシューティング」で、記述が一番わかりやすく書かれていた。 このエントリは、この書籍の 「3.9.3 オプションの安全値を計算する」 にて記載がある内容をまとめたものになる。 MySQLトラブルシューティング 作者:Sveta SmirnovaオライリージャパンAmazon 著者について Sveta Smirnova(スヴェータ・スミルノヴァ): Oracle社MySQLサポートグループ・バグ検証グループの主席テクニカルサポートエンジニアとして毎日MySQ
この記事は本番環境でやらかしちゃった人のアドベントカレンダー9日目の記事です。 https://qiita.com/advent-calendar/2020/yarakashi-production 去年に引き続き、今年も参加させてもらいました。 ※去年の記事はこちら→ データ移行をしただけなのに…（起こってしまったメール誤配信） 今年のネタも15年くらい前の事で、且つ自分が直接関わった事案ではないのですが、「そういやあの事件、今MySQLだったらどうするかな」と思い書くことにしました。 何があったか もうタイトルで出落ちしていますが本番でUPDATE文を実行する際にWHERE句を付け忘れたという事故です。 当時の状況を整理するとこんな感じだったと思います。 対象サービス： 年商10億円くらいの自社サービス 作業内容： 仮登録されている顧客の情報を指定された情報で更新する 作業環境： DB
こんにちは。クラウド運用チームで SRE をしている飯塚です。 今回は、MySQL のレプリケーション機能を約10年もの間ずっと使ってこなかった私たちが、レプリケーションを使った高可用性構成に移行するための取り組みの中で学んだことについて紹介します。 背景 巨大なテーブルへの primary key の付与 トランザクションサイズが大きい場合には tmpdir に注意 mysqldump で絵文字が消えていないか要チェック mysqldump が Error 1412: Table definition has changed... で失敗する mysqldump したデータのリストアが Duplicate entry 'xxx-yyy-PRIMARY-n_diff_pfx01' for key 'PRIMARY' で失敗することがある mysqldump したデータのリストア時のディスク
MySQLで3億レコード物理削除した話 はじめに こんにちは。webエンジニア社会人をしている ningenMe です。 タイトル通り。MySQLで3億レコード物理削除した話。 ちょっとハマったので備忘録。 はじまりはアラート はじまりはアラートだった。 僕が運用・保守しているバッチサーバでは、mysqlからちょうど直近1ヶ月分のデータを毎日1回selectする定期処理をしている。 いつもなら1時間程度で終わる処理のはずが、その日は7,8時間経っても終わらずアラートが鳴り止まない.....。 原因追求 とりあえずリトライしたり、ログ見たりしたもののあんまり悪いところがなかった。 クエリもちゃんとindex効いてる。なんでだろうと思ったらDBの容量が結構大きくなっていたことに気づいた。 3億5千レコード。インデックスちゃんと効いてたので多分普通に遅いだけっぽい。 必要なデータ取得は1ヶ月分で
MySQL5.7のExtended Supportは２０２３年１０月までです。これから始める場合はMySQL8.0を使いましょう。 既存のシステムのMySQLを5.6から5.7に変えて動かしたら、group by を使ったSQLでエラーが発生した。 Error Number: 1055 Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'dtabase_name.table_name.column_name' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by このエラーは s
2019年8月2日、インフラストラクチャエンジニアやネットワークエンジニア向けの勉強会「インフラ・ネットワークエンジニア勉強会」がアイスタイル株式会社で開催されました。同会では、AWSに関するインフラ・ネットワーク視点の話や、オンプレ環境の話など、過去の事例を共有。6人のエンジニアが成功・失敗談をシェアしました。「スイッチ交換でデータベースがすごく苦労した話」に登壇したのは、株式会社アイスタイルのsuzukito氏。講演資料はこちら スイッチ交換でデータベースがすごく苦労した話 suzukito氏：レイヤ3スイッチの交換でデータベースがすごく苦労した話をしたいと思います。 自己紹介です。鈴木と申します。アイスタイルのデータベースエンジニアをやっています。 お話しすることは、スイッチ交換でMySQLのレプリケーションが壊れました。その顛末を共有したいと思います。 まず、ある日、インフラのほ
端的にいうと SELECTのWHEREの条件の「右辺」に、RAND()やSYSDATE()のような非決定性関数を使うと、想定外のことが起こる。 戻ってくる行数が想定と異なる。 Indexが効かなくなる。（テーブルフルスキャン走る） どっちもなかなかのインパクトです。 追記：2019/05/30 PostgreSQLもMySQLと同じ挙動でした。（9.6と10系で確認） Oracleは、MySQLやPostgreSQLとは異なり、想定通りの件数が返ってきますし、Indexも効いてました。（11g R2で確認） 追記：2019/05/31 「PostgreSQLもMySQLと同じ」なのは、「ランダム関数利用時の挙動」です。日付系は調査しきれてません。 公式ドキュメントを読む限り、clock_timestamp()やtimeofday()を意図的に使わない限り、１つのSQLの中で違う日時を取り直
2007/ 01 02 03 04 05 06 07 08 09 10 2006/ 01 02 03 04 05 06 07 08 09 10 11 12 2005/ 01 02 03 04 05 06 07 08 09 10 11 12 2004/ 01 02 03 04 05 06 07 08 09 10 11 12 2003/ 01 02 03 04 05 06 07 08 09 10 11 12 2002/ 01 02 03 04 05 06 07 08 09 10 11 12 2001/ 01 02 03 04 05 06 07 08 09 10 11 12 2000/ 01 02 03 04 05 06 07 08 09 10 11 12 1999/ 01 02 03 04 05 06 07 08 09 10 11 12 1998/ 01 02 03 04 05 06 07 0
MySQL 8.0は何が優れていて、どこに注意すべきか。データベース専門家が新機能を徹底解説 MySQLの最新版「MySQL 8.0」正式版が2018年4月にリリースされました。数多くの機能や設定が追加・変更されているMySQL 8.0の「知っておきたい便利な機能」や「危険なハマりどころ」などを、My SQLの専門家に教えてもらいました。 2018年4月、世界中のエンジニアが待ちに待ったMySQL 8.0の正式版がリリースされました。本リリースに伴い、数多くの機能や設定が追加・変更されており、MySQLがより便利なものへと進化しています。 MySQL 8.0で積極的に利用すべき目玉機能や、知っておかなければ危険なハマりどころなど重要な変更点を、MySQLの保守サポートやコンサルティングなどを専門とする株式会社スマートスタイルの中野真也さんと成田優隆さんに解説してもらいました。 中野真也（な
MySQL 8.0正式版がリリース。性能が最大で2倍、JSONデータや地理情報などサポート。ロールによるユーザー権限の管理も可能に 前バージョンのバージョン番号は5.7で、本バージョンが8.0になったのは、過去のバージョン番号で6が使われたことがあったというMySQL のバージョンの都合や、MySQL Clusterがバージョン7であることなどを考慮したためとされています。 MySQL 8.0では、大幅な性能向上、JSONデータに対応したNoSQL機能の搭載、地理情報の対応、ロールによるユーザー権限など、さまざまな改善が行われています。 性能が最大で2倍に MySQL 8.0では、MySQL 5.7と比較してユーザー数が増えた場合に最大で約2倍ほどの大きな性能向上を実現しています。下記は読み込み性能の比較です。 読み込みだけでなく書き込み性能も向上しており、これはInnoDBでREDOログ
11/28 に Haskell で MySQL の Xプロトコルを実装したという話が聴ける Club MySQL というイベントがあったので参加してきました。 clubmysql.connpass.com MySQLのプロトコルの話ということで、平日の夜とは言え東京で参加者9人(発表者含む)というマニアックな集まりでした。 自分も1年前に Ruby で MySQL Xプロトコルを実装していたのですが、このツイートを最後に中断していたのでした。 MySQL X Protocol で Collection の追加はできるようになったが、検索がめんどくさい。条件文字列のパースはクライアントで行う必要があるんだな。— とみたまさひろ💎🐬 (@tmtms) 2017年2月20日 今回話を聞いて、無理に謎条件式文字列をパースするんじゃなくて、処理系で書きやすいように書けばいいんだという方式に目から
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
