Repro で遭遇した Aurora MySQL にまつわるトラブル 5 選 - Repro Tech Blog
こんにちは、Platform Team の荒引 (@a_bicky) です。前回は続・何でも屋になっている SRE 的なチームから責務を分離するまでの道のり 〜新設チームでオンコール体制を構築するまで〜という話を書いたんですが、今回は Repro の運用に 7 年以上携わる中で私が遭遇して印象的だった Aurora MySQL 絡みのトラブルについて紹介します。 Aurora MySQL が詰まってデータ処理のスループットが下がるとか、API のレスポンスが遅くなるとか、ALTER TABLE する度にアプリケーションエラーが発生するとか、胃が痛くなる胸が熱くなる話が多いので、Aurora MySQL を利用していなくても楽しんでいただけるのではないかと思います。Aurora MySQL を利用している方であれば参考になる情報もあるでしょうし、通常の MySQL にも適用可能な話もあります
MySQL/Aurora/TiDBロック入門 – 第３回ロック読取りも SELECT は止められない【解説動画付】｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
MySQL/Aurora/TiDBロック入門 – 第３回ロック読取りも SELECT は止められない【解説動画付】 MySQL とその互換 DB のロックの挙動を紹介する入門シリーズ、第３回は第２回で紹介したロックモニターを使って、業務ではよく使われているロック読取りについて解説します。 ロック読取りは、ゲームのバックエンドサーバーなど「同時に多数の処理をこなすけど、データとしての一貫性も重要」な場合に必須となるテクニックです。既に使っているという方も復習を兼ねてぜひご覧ください！ ★ 第１回 トランザクション分離レベル ★ 第２回 ロックモニターの読み方 ★ 第３回 ロック読取りも SELECT は止められない ★ 第４回 INSERT を止めるインテンションロック ★ 第５回 WHERE 条件と違うロック読取り ★ 第６回 performance_schema ★ 第７回ギャップロック
MySQL/Aurora/TiDBロック入門 – 第１回トランザクション分離レベル｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
MySQL/Aurora/TiDBロック入門 – 第１回トランザクション分離レベル MySQL InnoDB および AWS Aurora や PingCAP TiDB におけるロックの仕組みやトランザクションの動作を全１１回のシリーズで解説します！ 最初はベースとして重要な MySQL 8.0 InnoDB 前提でユーザー視点でのロックの仕組みを学び、後半第１０回以降では MySQL 互換 DB として人気の高い AWS Aurora や PingCAP TiDB と MySQL InnoDB との違いについて学びます。 １回目の今回はロック機構と切っても切り離せないトランザクションとその分離レベルについて、実際に挙動を確かめながら解説します。ライブ感のある説明も理解に役立ちますので、解説動画も付けてみました。合わせてご覧ください！ ★ 第１回 トランザクション分離レベル ★ 第２回 ロ
MySQL(InnoDB)のSQLパフォーマンスチューニングのエッセンス
はじめに MySQL(InnoDB)でSQLのパフォーマンスチューニングをするときに役に立つ知識をエッセンスとしてまとめました。結合(JOIN)やB-treeインデックスの探索の仕組み、実行計画の基本的な見方を紹介します。 想定する読者は、SQLのパフォーマンスを改善する必要があるが実行計画をみてもいまいちピンと来ない方です。インデックスの作成の経験や、複合インデックスやカーディナリティの知識があることを前提にしています。目標は、実行計画の内容がよく分からない読者が、実行計画をみただけでクエリが実行される様子をイメージでき、自信を持ってクエリの改善にあたることができるようにすることです。 ストレージエンジンはInnoDBを前提としています。また、インデックスはB-treeインデックスを想定しています。全文検索の転置インデックスや空間検索のR-treeインデックスについては触れません。 イン
オンライン DDL を期待して ALTER 文を実行したら障害になりかけた話 - カミナシ エンジニアブログ
こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 カミナシではマルチプロダクト化に向けて、認証・認可の切り出しを進めています。その対応を進める中で、既存テーブルへのカラム追加が必要になりました。 先日、そのリリースのために本番データベースにマイグレーションの ALTER 文を実行したところ、クエリが詰まって危うく障害になるところでした（幸いすぐにキャンセルして事なきを得ました）。 原因を調べたところ、オンライン DDL は複数の条件が関係することがわかりました。オンライン DDL に対する知識不足と事前検証の甘さゆえのミスでしたが、結果的には良い学びが得られました。 カミナシのバリューのひとつである「全開オープン」の気持ちで、事の顛末やそこから得た学びを公開します。 なお、今回の話は MySQL 5.7 互換の Amazon Aurora MySQL 2 で確
MySQLとOracleの実行計画を比較してみた - ASMのきもち
まいえすきゅーえりたい ぽすぐれない おらくるってる（狂ってる）tomoです。 今日はいつものMySQLリファレンスを読むではなく、夏休みの宿題にしていたこれをやってみます。 MySQLとOracleDBの実行計画を比較してみた さて同じようなテーブルで同じデータを載せて。 実行計画を取ってみた時、どのくらい情報量が違うのか簡単に違いを見てみましょう。 前提として、以下をご認識ください。 一方はOSSのDBエンジン、もう一方はガチガチ商用DBエンジンです。情報量が違うのは当たり前であって、良し悪しを比較したいのではありません。そして製品比較をしたいのではありません。いつも商用DBメインで使っているエンジニアが、OSSのDBにこうゆう情報も出してほしいな！というのをお願いしたいと思っていて、それを考える元ネタメモだと思ってください。 OSSでこれだけの情報出せるMySQLや、今回紹介しません
MySQLユーザー必見！世界の名だたる企業が活用する「TiDB」の特徴と強みに迫る - Qiita Zine
チタンのような堅牢なデータベースを目指して「TiDB」と命名 ――はじめに、読者にそれぞれ自己紹介をお願いします。 Sunny Bains氏（以下、Bains）：私は2000年からずっと、データベースのカーネルやストレージエンジンといったコアな部分の開発に取り組んできました。PingCAPにジョインしたのは2022年4月で、現在はクラウドチームに属しています。入社前はオラクルのソフトウェア開発部門のシニアディレクターとして、MySQLの最も大切なエンジンであるInnoDBに関わっていました。 Eric Han氏（以下、Eric）：来日してから13年が経ちました。キャリア最初期の2年間はインフラエンジニアとして働き、その後、約10年間は外資系メーカーでプリセールスなどを経験しました。2年前にPingCAP日本法人の立ち上げに伴ってジョインし、現在はPingCAPの日本代表となり、日々、市場開
MySQLで階層構造を扱うための再帰的なクエリの実装方法と実用例
１．はじめに RDBでの階層構造の関係を持つデータを扱う上で、 効率的なデータの持ち方や抽出方法について検証を行っています。 結論から先に 階層構造を扱う方法として下記の種類があります。 隣接リスト 経路列挙 入れ子集合 閉包テーブル 再帰クエリ（WITH RECURSIVE）を使うと階層データを扱う上でのパフォーマンスが得られます。 検索性、更新量、データ量など加味すると隣接リストで再帰クエリを用いるのがよさそう。 ２．階層構造を持つデータの概要 階層構造を持つデータとは 複数の要素（データ）が親子関係で結びついている構造を持つデータ 1つの要素が複数の要素の親になることができ、 また、1つの要素が複数の子要素を持つこともあります。 ある要素を親として、細分化された子要素であったり、 類似する要素を抽象化したものを親要素とするようなデータ。 階層構造を持つデータの例 組織における事業部、
yoku0825さんがMySQLスペシャリストになるまでにやってきた勉強法を、私たちにすべて教えてください！ - Findy Engineer Lab
「日本国内でもトップレベルのスキルを持ったMySQLエキスパートは誰か？」 そう問われたときに、多くのエンジニアが名前を挙げる人物がいます。LINE株式会社のITサービスセンター データベース室 MySQL1チームでDBA（Database Administrator）として働くyoku0825さん*（@yoku0825）です。 日本人として3人目のMySQL分野のOracle ACEであり、2015年には「default_password_lifetime」の功績でMySQL 5.7 Community Contributor Awardに選出されたyoku0825さん。彼はひたむきに自己研鑽を続けるだけではなく、ブログ「日々の覚書」や技術イベントへの登壇などを通してMySQL関連の情報発信を行ってきました。 今回はそんなyoku0825さんに「これまでどのようなトレーニングをして、DB
MySQLからPostgreSQLに移行する際のTips - そーだいなるらくがき帳
このエントリーは Classi developers Advent Calendar 2022の18日目。 ネタはなんでもいいよ！とのことなので、Claasiに全く関係なく、MysqlからPostgreSQLに移行する際の注意点を書く。 なお、まだRDSにPostgreSQLがなかった頃のような昔の記事だがこちらに無いことを書いていく。 soudai1025.blogspot.com soudai1025.blogspot.com MySQL から PostgreSQLにデータ移行する際の注意点 MySQLとPostgreSQLは互換性がもちろんありませんので、細かいところで違いが発生します。 よく踏むデータ移行の注意点は以下の通り。 timestampやdatetimeを移行する先はtimestamp型になるが、timestamp型はタイムゾーン付きと無しがある timestamp wi
GoでDBを使ったアプリを書くときみんなどうしてる？ Tonamelはどうしているか晒してみます - KAYAC Engineers' Blog
こんにちは。ゲームコミュニティ事業部サーバサイドエンジニアの谷脇です。 この記事はTech KAYAC Advent Calendar 2022の2日目です。 私はTonamelというWebサービスを運営しています。Tonamelでは、GoとPerlを用いてサーバサイドアプリケーションを構築しています。 この記事ではTonamelでのパッケージ構成や、DBを使う際に用いているライブラリについて紹介します。 そもそもTonamelって何 パッケージ構成やは、アプリケーションの特性や、実装の複雑さなども考慮するため、前提として作っているものを説明します。 tonamel.com Tonamelとはeスポーツを始めとした競技の大会を開催するときに用いるプラットフォームです。大会主催者と参加者双方が利用します。 Tonamelの機能説明 この図に挙げているように、『参加者管理』と『トーナメント表』
主要RDBMS製品の比較 – アーキテクチャ, スキーマ, データベース, メモリ | コーソルDatabaseエンジニアのBlog
Microsoft SQL ServerMySQLOracle DatabasePostgreSQLSolarWinds DPAデータベース運用主要RDBMS製品の比較 2022.09.01 渡部 亮太 主要RDBMS製品の比較 – アーキテクチャ, スキーマ, データベース, メモリ Oracle ACE Proの渡部です。 主要なRDBMS製品についてアーキテクチャを比較します。 大枠を整理することが最大の目的です。細かい例外事項や拡張機能は適宜記載を割愛しています。 2022年9月時点の最新バージョンをベースに記載していますが、記載内容にバージョン依存は少ないはずです。 時間ができた時に随時追記予定です。 もし誤りを見つけた場合は、優しく教えていただけると嬉しいです。→ https://twitter.com/wrcsus4 or ryota.watabe at cosol dot
MySQL/Postgres におけるトランザクション分離レベル
MySQL/Postgres におけるトランザクション分離レベルと発生するアノマリーを整理する https://zenn.dev/mpyw/articles/rdb-transaction-isolations 上記のスライドの具体的な結論に至るまでの導入として，知識があまりない状態でも段階的に読み込んでいけるように心がけたスライドで，株式会社ゆめみの社内勉強会にて発表しました。 スライドの途中の URL などは PDF としてダウンロードするとクリックできると思います。 事前のレビュー協力者 - https://twitter.com/neko_han25 - https://twitter.com/KentarouTakeda
WHERE 条件のフィールドを UPDATE するのって，明示的にロックしてなくても安全？全パターン調べてみました！ - Qiita
WHERE 条件のフィールドを UPDATE するのって，明示的にロックしてなくても安全？全パターン調べてみました！MySQLSQLPostgreSQLDatabaseQiitaEngineerFesta2022 TL; DR MySQL/Postgres とも， MVCC アーキテクチャの恩恵で， SELECT と UPDATE は基本的には競合しない。 単一レコードのシンプルな UPDATE でも排他ロックされ，排他ロック中のレコードへの UPDATE での変更操作は トランザクション分離レベルによらず ブロックされる。UPDATE 文に含まれる WHERE 句での検索もブロックされ，これはブロックされない SELECT による検索とは別扱いになる。 但し UPDATE 文の WHERE 句上で，更新対象をサブクエリの SELECT から自己参照している場合は例外。トランザクション分離
Postgres と MySQL における id, created_at, updated_at に関するベストプラクティス
読者対象 ある程度データベースに関する知識を持っている，経験年数 1 年以上のバックエンドエンジニア 特定のプログラミング言語に依存する部分は含めないため，すべての SQL 使用者を対象とする また，ゼロからの丁寧な説明というよりは，リファレンス感覚で使える記事という形にまとめる。 RDBMS の対象バージョン PostgreSQL: 9.4 以降 MySQL: 8.0.28 以降 id （データ型と INSERT 時のデフォルト埋め） 導入 一般的に採用されやすいプライマリキー用の値として，以下を考える。 連番整数 MySQL では AUTO_INCREMENT， Postgres では IDENTITY や SERIAL と呼ばれるもの UUID v1: ハードウェアごとにユニークな単調増加値 UUID v4: ランダム値 UUID v7（ドラフト）: 単調増加であるタイムスタンプとラ
PlanetScaleとは何か、なぜ外部キー制約をサポートしていないのか
PlanetScaleとは PlanetScaleはMySQLのマネージドサービスです。 内部の実装には元々YouTubeのために開発されたMySQLのクラスタリングシステムであるVitessが使用されています。 Vitessの開発に携わってらっしゃるSugu SougoumaraneさんがCTOとして在籍しており、スケーラブルなデータベースを構築するためのサービスとなっています。 すでにSlack, Square, GitHubなどの企業で採用されているそうです。 この記事ではPlanetScaleのどういった点が優れているのか、これまでMySQLが抱えていた問題点をどのように解決しているのかといったことをまとめます。 その中でタイトルにもつけましたが、なぜ外部キー制約をサポートしていないのかといった点も交えて説明します。 これまでのMySQLの問題点 大量のレコードが存在するテーブルの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Zendesk、DynamoDBからMySQLとS3へ移行し、コストを80％以上削減
「TiDB」は待ち望んだDBか？ LINEヤフーとメルカリの“MySQL”プロが赤裸々に語り合う
PostgreSQLとMySQLのメジャーバージョンアップのためのチートシート作った - そーだいなるらくがき帳
GitHub - devops-works/dw-query-digest: MySQL slow log analyzer. Alternative to pt-query-digest.
