AWSがMySQLのODBCドライバを開発、オープンソースで公開。純正ドライバ互換、Amazon Auroraでの高速なフェイルオーバー、AWSのシークレットやIAMのサポートなど AWS ODBC Driver for MySQLは、MySQLコミュニティが配布している純正のMySQL用ODBCドライバと置き換えて使える互換性を備えつつ、AWSでMySQLを利用する際により優れた機能と性能を実現できるように実装されています。 具体的には、Amazon Auroraにおけるフェイルオーバー時の再接続の高速化です。AWS ODBC Driver for MySQLはクラスタのトポロジーと各 データベースインスタンスがプライマリなのかレプリカなのかの役割のキャッシュを保持することで、接続先のデータベースインスタンスに障害が発生し、別のデータベースインスタンスへのフェイルオーバーが発生したときに

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

プロダクト開発チームの田中と申します。(社内ではたなしゅんと呼ばれております) 先日新機能のリリースを行いまして、リリース時に既存テーブルに対してのカラム追加が必要だったのですが、カラム追加のALTER TABLEが中々終わらないという問題が以前のリリース時に起きていたこともあり、事前に問題なくDBマイグレーション(Railsを利用しているため、この記事ではALTER TABLEなどのDB操作をマイグレーションと呼びます)が実施できるように調査を行いました。 その際に調査した内容や工夫したことなどを共有したいと思います。 過去のリリース時に起きた問題 ALTER TABLEが終わらない メンテナンスタイム中にデータベースのマイグレーションができるのが理想ですが、hacomonoのサービスの特性上24時間運営の店舗様にもご利用いただいているため、頻繁にメンテナンスタイムを設けることが難しく、

まえがき ちょっと待った。オンラインDDLって何よ？ DDLについて オンラインDDL オンラインDDL実行で起こりかけた問題 ロックを取得する じゃあどうすればいいのさ DDLを流す時にメンテを入れる TO値を設定する あとがき まえがき こんにちは。バックエンドエンジニアの@mobojisan と申します。 この時期は本当にカンファレンスが多いですね！ 個人用GitHub上にSSGを利用したブログ基盤があるのですが、それが使いにくかったので、今流行りのsupabaseでブログ基盤をおっ立て、カンファレンスに参加した時の感想記事でも載っけようかと画策していました。 しかし、作業がカンファレンスの開催スピードにとても追いつかず、カンファレンスのメモが無情にもnotion上に溜まっていきます。 もはやメモをブログとして世に出す頃には来年のカンファレンスが開催されているんじゃないか…？と思いな

記事を書くのが遅くなってしまったが、先日MySQL 8.4シリーズが登場したので紹介をしておこうと思う。新機能の解説については機会を改めて書くとして、今回は主にアップグレードにまつわる重要なポイントを書き記しておく。 LTS = Long Term Support 以前の記事でも紹介した通り、MySQL 8.4はLTS = Long Term Supportのバージョンとなっている。長期間サポートするために互換性を最大限保証するバージョンである。前のメジャーバージョンであるMySQL 8.0シリーズのように、シリーズの途中で互換性が破壊されるような変更が入ることは基本的に無い。「バグ修正のためにどうしても仕様を変えなければならない」というような事態が生じる可能性はゼロではない。なので絶対に互換性が保たれるとは言い切れないところであるが、基本的には仕様変更はない方向で今後リリースされていくこ

はじめに MySQL(InnoDB)でSQLのパフォーマンスチューニングをするときに役に立つ知識をエッセンスとしてまとめました。結合(JOIN)やB-treeインデックスの探索の仕組み、実行計画の基本的な見方を紹介します。 想定する読者は、SQLのパフォーマンスを改善する必要があるが実行計画をみてもいまいちピンと来ない方です。インデックスの作成の経験や、複合インデックスやカーディナリティの知識があることを前提にしています。目標は、実行計画の内容がよく分からない読者が、実行計画をみただけでクエリが実行される様子をイメージでき、自信を持ってクエリの改善にあたることができるようにすることです。 ストレージエンジンはInnoDBを前提としています。また、インデックスはB-treeインデックスを想定しています。全文検索の転置インデックスや空間検索のR-treeインデックスについては触れません。 イン

MySQLにbinlogとredo logの二つの重要なログシステムがあります。本文では、この二つのログの仕組みについて説明します。 #１．基本知識 MySQLは、SQLの解析と実行する機能を実現するServer層とデータアクセス機能を提供するストレージエンジン層で構成されています。ストレージエンジンには、MyISAM、InnoDB、Memoryなどが存在します。 binlogは、Server層が出力するログです。redo logは、InnoDBエンジンが出力するログです。二つのログは、ともにDBテーブル更新時に出力されます。 ディスクアクセスに時間がかかるため、InnoDBエンジンがメモリ上でレコードを更新し、redo log bufferに記録したら、レコード更新操作が完了とします。この仕組みは、WAL（Write　Ahead Logging）といいます。別の専用スレッドが適当のタイミ

１．はじめに RDBでの階層構造の関係を持つデータを扱う上で、 効率的なデータの持ち方や抽出方法について検証を行っています。 結論から先に 階層構造を扱う方法として下記の種類があります。 隣接リスト 経路列挙 入れ子集合 閉包テーブル 再帰クエリ（WITH RECURSIVE）を使うと階層データを扱う上でのパフォーマンスが得られます。 検索性、更新量、データ量など加味すると隣接リストで再帰クエリを用いるのがよさそう。 ２．階層構造を持つデータの概要 階層構造を持つデータとは 複数の要素（データ）が親子関係で結びついている構造を持つデータ 1つの要素が複数の要素の親になることができ、 また、1つの要素が複数の子要素を持つこともあります。 ある要素を親として、細分化された子要素であったり、 類似する要素を抽象化したものを親要素とするようなデータ。 階層構造を持つデータの例 組織における事業部、

#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。

MySQL 5.7とそれ以前では、テーブルの結合を実施する際に、INNER JOINの場合はSTRAIGHT_JOINを利用し結合することで、テーブルのなかで先に読み取りを行うテーブルを決めることができました。最新バージョンのMySQL 8.0からは、Join-Order オプティマイザヒント句を用いてJOINする順番を決めることができるようになりました。 今回は、従来のSTRAIGHT_JOINとJoin-Order オプティマイザヒント句の使い方を確認していきたいとおもいます。なお、使用しているMySQLは8.0.15,OSはCentOS7を利用しています。 STRAIGHT_JOIN STRAIGHT_JOINは、JOINを行う際に対象のテーブルの駆動表を固定したいときに使われる構文です。STRAIGHT_JOINを用いてJOINを行うと、先に出てきたテーブルを駆動表として扱い、IN

今回は2015年11月にバージョン1.0.0がリリースされ、2016年4月19日に1.1がリリースされたmybatis-spring-boot-starterの使い方を紹介します。 MyBatisをSpring Boot上で使う際は、mybatis-springから提供されているSqlSessionFactoryBeanやSqlSessionTemplateのBean定義を開発者が行う必要がありましたが、mybatis-spring-boot-starterの登場によりこれらのBean定義は自動コンフィギュレーションによって解決されます まずは、実際にmybatis-spring-boot-starterを利用して簡単なCLI(Command Line Interface)アプリケーションを作ってみます 。 Note: 2019/7/16: 追記 JDK 13で導入予定(現時点ではPrev

本日は、MySQL Casual Advent Calendar 2013の20日目である。というわけでカジュアルに小ネタを紹介しよう。 MVCC - Multi Version Concurrency Controlご存知の通り、InnoDBはMVCCを実装している。そのため、分離レベルがREPEATABLE READの場合には、行にロックをかけることなく、一貫した読み取りが可能になっている。 もし、あるトランザクションT1開始後に、別のトランザクションT2によって同じ行が書き換えられてしまった場合には、T1はロールバックセグメントにある古いバージョンの値を読み取ることができるので、T1内で実行したSELECTは常にT1開始時点のデータを参照することができるのである。大事なのでもう一度言うが、REPEATABLE READにおける単純なSELECTでは行ロックは必要ない。 Lost Up

株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。 bashパフォーマンスMySQLInnoDBDB設計インデックス こんにちは、羽山です。 今回は MySQL のプライマリキーに UUID を採用する場合に起きるパフォーマンスの問題を仕組みから解説します。 MySQL(InnoDB) & UUID のパフォーマンスについては各所でさんざん議論・検証されていますが、論理的に解説した記事が少なかったり一部には誤解を招くようなものもあるため、しっかりと理由から理解するための情報として役立つことができればと思っています。 UUID と比較される古き良き昇順/降順のプライマリキーはというと、 MySQL の InnoDB において良いパフォーマンスを出すために縁の下の力持ちのような働きをしてくれているケースが実は少な

4. ロックおさらい（簡易） • 共有ロック（LOCK_S） 共有ロック同士は互いにブロックしない 例：SELECT LOCK IN SHARE MODE • 排他ロック（LOCK_X） 何も受け付けないぞ、排他 例：INSERT(成功), UPDATE, DELETE, SELECT FOR UPDATE X S X Conflict Conflict S Conflict Compatible 4 大きく分けてロックは2種類 5. 5 > BEGIN; > SELECT * FROM player WHERE id = 100 LOCK IN SHARE MODE; > BEGIN; トランザクションA トランザクションB 共有と排他順によるデッドロック例 6. 6 > BEGIN; > SELECT * FROM player WHERE id = 100 LOCK IN SHARE MO

はじめに MySQLはよく使っているのですが外部キー制約はほとんど使った事ありませんでした。 使うデメリットとしてはデータの登録作業が面倒だから・・・程度で考えていました が、今回は既に外部キーを採用しているシステムでの作業でしたがほとんど経験なかったので少し苦労しました 発生した現象としては原因不明のデッドロックエラーでこのようなエラーでした Deadlock found when trying to get lock; try restarting transactionなぜ意味不明かと思ったかと言うと以下からそう思っていました ・対象のテーブルを使用している箇所が1箇所だけ ・必ず一意となるデータをINSERTするだけ 概要 会員テーブル(user) 会員ID(id) 会員名(name) カウント(count) 1 太郎 0 2 花子 0 商品テーブル(item) 商品ID(id)

はじめに こんにちは。webエンジニア社会人をしている ningenMe です。 タイトル通り。MySQLで3億レコード物理削除した話。 ちょっとハマったので備忘録。 はじまりはアラート はじまりはアラートだった。 僕が運用・保守しているバッチサーバでは、mysqlからちょうど直近1ヶ月分のデータを毎日1回selectする定期処理をしている。 いつもなら1時間程度で終わる処理のはずが、その日は7,8時間経っても終わらずアラートが鳴り止まない.....。 原因追求 とりあえずリトライしたり、ログ見たりしたもののあんまり悪いところがなかった。 クエリもちゃんとindex効いてる。なんでだろうと思ったらDBの容量が結構大きくなっていたことに気づいた。 3億5千レコード。インデックスちゃんと効いてたので多分普通に遅いだけっぽい。 必要なデータ取得は1ヶ月分である12'000'000件ほど。このse

こんにちは、shallow1729:detailです。今回は先日MyNA会というイベントで発表したMySQLの標準のストレージエンジンであるInnoDBのMVCCのガベージコレクションについて書こうと思います。発表自体もアーカイブされているので以下から見る事ができます。 「日本MySQLユーザ会会(MyNA会) 2021年07月 -下位レイヤ勉強会-」 公開版 - YouTube まず前半ではMVCCに関連するデータ構造を見ながらガベージコレクションの重要性やlong-running transactionの問題点について解説します。後半では実際のガベージコレクション(purge)の処理をソースコードレベルで追いながら、ユーザーに提供されているパラメーターを解説をします。 これまでに比べると踏み込んだ話題なのであまり基礎的な事は解説しません。知らない単語が多いかもしれないですが、適宜調べな

こんにちは。id:shallow1729です。先日はredo logを中心にストレージエンジンについて解説を行いましたが、今回は同時実行制御、特にMySQLなど多くのデータベースで採用されているMultiversion Concurrency Control(MVCC)という技術にフォーカスしようと思います。 今回の記事ではまず前半でMVCCというものがどういうものかについて解説をして、次にMVCCの実装方法についてInnoDBの実装を参考にしながら見ていこうと思います。前提知識はあまりいらないと思いますが、リレーショナルデータベースの操作経験はあったほうがいいかなと思います。また、前回のストレージエンジンの解説で述べた内容はあまり説明しないので、軽く目を通してもらえると頭に入りやすいかなと思います。 shallow1729.hatenablog.com トランザクションの原子性 まずトラ