サブクエリの書き方を2万文字弱かけてすべて解説する
これはなに ども、レバテック開発部のもりたです。 今回はSQLのサブクエリについてまとめます。仕事でクエリを書く際、サブクエリは頻出の構文だと思うんですが、同時にサブクエリの書き方を完全に理解しているよという人は案外少ないのではないでしょうか？[1] 実際、MySQLの公式ドキュメントを見ると12ページくらいを割かれており、意外と奥深いのがサブクエリです。使いこなせると便利ですし、何よりちょっとSQLのコツみたいなのがわかって面白いよ、ということで記事にしてみました。 前提 この記事は以下の前提を含んでいます。 環境 MySQL8.0系 読者の知識 なんとなくサブクエリが書ける けど相関サブクエリとかになると「あーっ」つってGoogle meetを閉じてしまうくらいのレベル感 記事のボリューム 18,000文字 おれの卒論が20,000文字だった マサカリ 間違ってたら投げてくれ〜〜 それ
GitHub、1200台以上のMySQL 5.7を8.0へアップグレード。サービス無停止のまま成功させる GitHubが提供するGitHub.comは、世界最大のソースコード管理システムを始めとするソフトウェア開発者向け支援サービスを提供しています。 そのGitHub.comはRuby on Railsで構築されており、同社はつねにRubyとRuby on Railsをアップデートし続けていることを今年（2023年）4月に明らかにしています。 参考：GitHubは200万行規模のRailsアプリケーションであり、毎週RailsとRubyを最新版にアップデートし続けている そして同社はこのGitHub.comを支える1200台以上のMySQL 5.7を、GitHub.comのサービスレベルを維持したまま1年以上かけてMySQL 8.0にアップグレードしたことをブログで明らかにしました。 Up
この記事は、株式会社カオナビ Advent Calendar 2023 の3日目です。 はじめに 株式会社カオナビの高橋(@kunit)です。 今回は MySQL バージョンアップ(5.7 -> 8.0) で起きた問題とそれに対してどのように対処したのかを書いていこうと思います。 何が起きたのか MySQL 5.7 から 8.0 にバージョンアップをするにあたって、CI およびローカル環境でテストができるように MySQL 8.0 のイメージを作成し、それをつかって各機能の担当者にテストを開始してもらっていたのですが、以下のような事が起きました。 接続を MySQL 5.7 から 8.0 に切り替えただけでテストの時間が3倍くらいかかるようになった そこを変更するだけで3倍遅くなるってやばいぞということで報告してくれた担当者と同じテストを自分でも実施してみると再現性があり、それが以下のどの
医薬品検索でMySQLの全文検索機能を使った話 - KAKEHASHI Tech Blog
AI在庫管理の開発チームでバックエンドエンジニアをしている沖です。今回は、AI在庫管理の医薬品検索において、MySQLの全文検索機能を使った話を紹介しようと思います。 この記事は秋の技術特集 2024の 8 記事目です。 今までの医薬品検索では満足できないユーザーがいた なぜMySQLの全文検索機能を採用したのか 全文検索機能を導入する 全文検索インデックスを付与したテーブルを作成する パーサー 照合順序と正規化 全文検索インデックスを使用して検索する データを最適な状態に保つために おわりに 今までの医薬品検索では満足できないユーザーがいた AI在庫管理には、医薬品の在庫一覧画面など、医薬品名で絞り込む画面がたくさんあります。この絞り込み機能を実現するために、これまではSQLのLIKE検索を利用していました。 LIKE検索は、使い慣れたSQLを用いて部分一致検索を実現できる便利な方法です
オンライン DDL を期待して ALTER 文を実行したら障害になりかけた話 - カミナシ エンジニアブログ
こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 カミナシではマルチプロダクト化に向けて、認証・認可の切り出しを進めています。その対応を進める中で、既存テーブルへのカラム追加が必要になりました。 先日、そのリリースのために本番データベースにマイグレーションの ALTER 文を実行したところ、クエリが詰まって危うく障害になるところでした（幸いすぐにキャンセルして事なきを得ました）。 原因を調べたところ、オンライン DDL は複数の条件が関係することがわかりました。オンライン DDL に対する知識不足と事前検証の甘さゆえのミスでしたが、結果的には良い学びが得られました。 カミナシのバリューのひとつである「全開オープン」の気持ちで、事の顛末やそこから得た学びを公開します。 なお、今回の話は MySQL 5.7 互換の Amazon Aurora MySQL 2 で確
MySQLのSQLクエリチューニングの要所を掴む勉強会を開催しました！ - ANDPAD Tech Blog
こんにちは！DBREの福間（fkm_y）です。先月、弊社でデータベースの技術顧問をして頂いてる三谷（mita2）さんに開発本部向けの「MySQL SQLチューニング」勉強会を実施していただきました。 今回はMySQLの得意不得意なことの説明やSQLチューニングの流れ、具体的な事例を元にした対応例、また最近話題のHTAPな製品も紹介していただきとても参考になったのでポイントをおさえてレポートをお伝えします！ 開催背景 本編 MySQL の得意なこと、苦手なこと データベースのチューニング手段と特徴 SQLチューニングの流れ インデックス SQLチューニング例 インデックスフルスキャンとカバーリングインデックス ソート まとめ 当日の資料 さいごに 過去開催されたデータベース勉強会レポート 開催背景 弊社では三谷さんによるデータベース勉強会を定期的に開催しています。数年前にも同じテーマで勉強会
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 との違いについて学びます。 １回目の今回はロック機構と切っても切り離せないトランザクションとその分離レベルについて、実際に挙動を確かめながら解説します。ライブ感のある説明も理解に役立ちますので、解説動画も付けてみました。合わせてご覧ください！ ★ 第１回 トランザクション分離レベル ★ 第２回 ロ
はてなブログの DB を RDS for MySQL 8.0 にアップグレードした話 - Hatena Developer Blog
この記事は、はてなエンジニア Advent Calendar 2023の2024年1月17日の記事です。 はてなエンジニア Advent Calendar 2023 - Hatena Developer Blog id:hagihala です。先日、はてなブログの DB を RDS for MySQL 5.7 から 8.0 へアップグレードしたので、工夫した点などを共有します。 Aurora MySQL 3.x にしなかった理由 MySQL 5.7 -> 8.0 で対応した変更点 character set や collation のデフォルトが変更される explicit_defaults_for_timestamp がデフォルトで有効になる SQL mode の変更 デフォルトの認証プラグインが caching_sha2_password になり、 mysql_native_passw
はじめに MySQL(InnoDB)でSQLのパフォーマンスチューニングをするときに役に立つ知識をエッセンスとしてまとめました。結合(JOIN)やB-treeインデックスの探索の仕組み、実行計画の基本的な見方を紹介します。 想定する読者は、SQLのパフォーマンスを改善する必要があるが実行計画をみてもいまいちピンと来ない方です。インデックスの作成の経験や、複合インデックスやカーディナリティの知識があることを前提にしています。目標は、実行計画の内容がよく分からない読者が、実行計画をみただけでクエリが実行される様子をイメージでき、自信を持ってクエリの改善にあたることができるようにすることです。 ストレージエンジンはInnoDBを前提としています。また、インデックスはB-treeインデックスを想定しています。全文検索の転置インデックスや空間検索のR-treeインデックスについては触れません。 イン
データベースアップグレード後の性能劣化、イヤですよね。 去る2023年某日、弊社ではAmazon Aurora MySQL 互換エディション 2 (MySQL 5.7 互換) から Aurora MySQL 互換エディション 3 (MySQL 8.0 互換) にアップグレードしました。当時の背景やアップグレードに関する知見は以下の記事をぜひ読んでみてください。 blog.smartbank.co.jp ソフトウェアバージョンアップをするとき、旧バージョンが抱えていた問題の解決などの恩恵を我々は期待します。しかし時には予期せぬデグレーションに遭遇することもあります。我々のMySQL 8.0へのアップグレード前後においてもいくつかの問題に遭遇しました。 本記事ではそんな問題の一つ、MySQL 8.0のオプティマイザが選択したセミジョイン最適化が性能劣化を引き起こした事例と解決方法について紹介し
MySQL8.0でSELECT COUNT(*)が低速になる動作は8.0.37で解消されていた！ - CyberAgent SRG #ca_srg
メディア統括本部 サービスリライアビリティグループ（SRG）の鬼海雄太（@fat47）です。 #SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。 本記事は、MySQ
mysql57to8.md 確認すること メンテナンス時間をどれくらい取れるかで戦略が決まる。 基本的にはメンテナンス時間を十分に取れたほうが良い。 またリスクをどれだけ許容できるかもビジネスによるので要確認しておくべき。 基本的には一度切り替えてしまうとロールバックすることは簡単ではない。 覚悟を決めて突き進む必要がある 最初に諦めること MyISAMを使いたい 8でも動くけど諦めろ、もう未来はない InnoDBのほうがDisk サイズを消費する、countが遅い、などの課題はあるので簡単ではないが… InnoDB memcached Pluginとか使ってるんだよね 諦めろ、未来はない これを機にアーキテクチャを見直しましょう PKが無いtableがあるんだよね すべてのtableにまずPKを付けるんだ このあと、DMSを使ったりとかなにをするにしても死ぬ そもそもデータモデルとして死
はじめに こんにちは。雑食系エンジニアの勝又です。 今回は、私が2年ほど参画させていただいた大規模サービスのインフラやDevOps周りを全面的にリプレイスしたお話について簡単にご紹介させていただきます。(内容に関しては事前に参画先企業様に確認していただいております) サービス概要 詳細な内容は伏せますが、メインとなるテーブルのレコード数が数十億件、スパイク時には数万〜数十万のユーザーが一斉にアクセスする大規模サービスです。 技術的負債 長く運用されてきたサービスのあるあるですが、新機能の追加が最優先されてきたことにより、こちらのサービスにも下記のような技術的負債が大量に積み上がっていました。 RubyやRailsやMySQLのバージョンがかなり古い インフラの構成がコードではなくドキュメントで管理されている アプリケーションの構成管理がおこなわれていない CI/CDパイプラインが構築されて
Aurora MySQL におけるロック競合（ブロッキング）の原因を事後調査できる仕組みを作った話
こんにちは。 DBRE チーム所属の @p2sk です。 DBRE（Database Reliability Engineering）チームでは、横断組織としてデータベースに関する課題解決や、組織のアジリティとガバナンスのバランスを取るためのプラットフォーム開発などを行なっております。DBRE は比較的新しい概念で、DBRE という組織がある会社も少なく、あったとしても取り組んでいる内容や考え方が異なるような、発展途上の非常に面白い領域です。 弊社における DBRE チーム発足の背景やチームの役割については「KTC における DBRE の必要性」というテックブログをご覧ください。 本記事では、Aurora MySQL でロック競合（ブロッキング）起因のタイムアウトエラーが発生した際に根本原因を特定することができなかったので、原因を後追いするために必要な情報を定期的に収集する仕組みを構築した
メディア統括本部 サービスリライアビリティグループ（SRG）の鬼海雄太（@fat47）です。 #SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。 本記事では、MyS
いろいろありますが、今後のことを考える前にまずは、バージョン8.0.xの現状を一旦整理・理解してから決めようと思います。 念を押しておきますが、このブログの「内容は個人の考えであって、所属組織とは方針が異なる」と考えてください。 MySQL内部の人は、クラウドとか最新のサーバーとかしか利用していないのかも知れず、MySQL 8.0 が日に日に遅くなっていることに気づいていない人しかいないのでしょう。しかし、数年前のローカルPCで動かすと年々動作が鈍くなっているのを感じます。マイナーバージョンアップで単スレッド性能が下がり続けるなんて商用システムではリスキーです。 証明が難しく、ずっと放置せざるを得なかったのですが、非常に重要な事柄ですので今一度、オープンになっているソースを基に分析をしてみます。 まず、測るモノサシを決めましょう。以前のエントリ「MySQLバージョンアップによるInnoDB
Amazon RDS ブルー/グリーンデプロイを利用してMySQLのアップグレードをした話 - Pepabo Tech Portal
こんにちは。技術部プラットフォームグループのharukinです。 この記事では、私たちが提供するネットショップ作成・運用のためのECプラットフォーム「カラーミーショップ」のデータベースを、Amazon RDSのブルー/グリーンデプロイを利用し、MySQLのバージョン5.7.38から8.0.35へアップグレードした経験についてご紹介します。カラーミーショップにおいてはこれが初の試みでした。Amazon RDS固有のファーストタッチレイテンシーの解除方法や、ダウンタイム時間の計測についてもお伝えします。 Amazon RDSのブルー/グリーンデプロイを活用するメリットは、本番環境に準ずるステージング環境を構築し事前検証が可能であることです。ステージング環境は約1分で本番環境に昇格させることができ、昇格時に許容ダウンタイムを超えたり、レプリケーションやインスタンスの問題が生じた場合は、自動的にプ
AWSのDMSやブルー/グリーンデプロイを使ってMySQL8.0へ移行した話 - BASEプロダクトチームブログ
はじめに Data Strategyチーム（以下、DSチーム）でDWHやBIツールの運用をしている@shota.imazekiと不正検知やAWS基盤運用をしている@tawamuraです。 Aurora MySQL v2（MySQL5.7互換）が2024/10/31に標準サポート終了となるため、DSチームでは2024年6月にAurora MySQL v3（MySQL8.0互換）へのアップグレードを実施しました。 その際に得られた課題や知見について紹介していきます。主にAWS DMSやAmazon RDS ブルー/グリーンデプロイを用いたアップグレード方法の話になります。 DSチームのインフラ構成 DSチームはBASEの機械学習基盤を構築・運用しており、APIなどを介してプロダクト側へ機械学習モデルの推論結果などを返しています。学習・推論のために使うプロダクト側のデータはDMSを用いて、DS環
はてなにおけるEKSの運用と自動化 (2024年版) - Hatena Developer Blog
サービスプラットフォームチームで SRE を担当している id:masayosu です。 先月からですが Hatena Developer Blog にて SRE 連載を始めました。先月の記事は はてなブログの DB を RDS for MySQL 8.0 にアップグレードした話 - Hatena Developer Blog です。 毎月はてなの SRE が交代でブログ記事を書きますのでお楽しみに。 この記事は2024年2月の SRE 連載の記事です。 はてなの EKS 利用について 私が所属するサービスプラットフォームチームでは EKS の運用を続けており、先日 Kubernetes 1.23 から 1.28 へのアップグレードを完了しました。 私のチームは少人数で形成されているのですが、担当しているサービスは大小様々あり EKS クラスター上では数十個のサービスが稼働しています。 少
TL;DR RDS の メジャーバージョンアップグレード を行なった PostgreSQL 11.6 -> 15.5 MySQL 5.7.44 -> 8.0.36 PostgreSQL は AWS CDK を利用した、自前での手動切り替えをベースにした Blue/Green デプロイによるアップグレードを行なった MySQL は AWS コンソールから AWSが提供している機能である RDS Blue/Green Deployments による MySQL のアップグレードを行なった nginx の ngx_http_proxy_module を活用してサービスのダウンタイムを防止した はじめに 初めまして。株式会社ジーニーの GENIEE CHAT開発チームのマネージャーを担当しています。 今回は、データベースのメジャーアップグレードを行った際の手順やポイントなどを書いていこうと思います
MySQL 8.4 LTS登場！！
記事を書くのが遅くなってしまったが、先日MySQL 8.4シリーズが登場したので紹介をしておこうと思う。新機能の解説については機会を改めて書くとして、今回は主にアップグレードにまつわる重要なポイントを書き記しておく。 LTS = Long Term Support 以前の記事でも紹介した通り、MySQL 8.4はLTS = Long Term Supportのバージョンとなっている。長期間サポートするために互換性を最大限保証するバージョンである。前のメジャーバージョンであるMySQL 8.0シリーズのように、シリーズの途中で互換性が破壊されるような変更が入ることは基本的に無い。「バグ修正のためにどうしても仕様を変えなければならない」というような事態が生じる可能性はゼロではない。なので絶対に互換性が保たれるとは言い切れないところであるが、基本的には仕様変更はない方向で今後リリースされていくこ
非 Aurora な RDS から Aurora へ移行する時に考えること全部盛り - ゆるっと Tech Blog
Japan AWS Jr. Champions Advent Calendar 23日目の投稿です！クリスマスイブイブですね。 今回は、Aurora でない RDS で稼働している DB を Aurora へ移行することを検討してみます。 現在の データベース 具体的な例があった方が分かりやすいので、移行対象の DB の情報を仮定しておきます。 データベースの情報 利用サービス：RDS (非Aurora) インスタンスタイプ：db.t3.medium (2vCPU/4GiB) ディスク容量：50GiB DBエンジン：MySQL 8.0系 MultiAZ構成 (Active-Standby) リードレプリカなし オンデマンドインスタンス 利用状況 CPU利用量：余裕あり ディスク利用量：余裕あり メモリ利用量：2GiB弱程度で安定推移 システム稼働：時間帯や日による変化はなく、一定した稼働
Elasticsearch 6系および7系への無停止アップグレード事例 - はてなブックマーク編 - Hatena Developer Blog
はてなブックマークチームのエンジニアリングマネージャー id:yigarashi です。はてなブックマークでは全文検索エンジンとしてElasticsearchを利用しており、最近6.8および7.10への無停止アップグレードを実施しました。非互換な変更の影響を真っ向から受けるユースケースでしたが、リスクを分割し少しずつ対処することで迅速かつ安全にアップグレードできました。本記事ではポイントを絞りつつアップグレードの様子をまとめます。 アップグレードに至る経緯 はてなブックマークでは長らくElasticsearchの5系を使っていました。エントリーとブックマークの検索を中心にサービスのかなりの部分を支える重要なミドルウェアですが、大きな変化は以下の記事にある2020年のAWSへの移転が最後（その時もメジャーバージョンは変わらず）で、なかなかElasticsearchの面倒を見られていませんでし
Amazon Aurora MySQL バージョン 2 (MySQL 5.7 互換) からバージョン 3 (MySQL 8.0 互換) へのアップグレードのチェックリスト、パート 1 | Amazon Web Services
Amazon Web Services ブログ Amazon Aurora MySQL バージョン 2 (MySQL 5.7 互換) からバージョン 3 (MySQL 8.0 互換) へのアップグレードのチェックリスト、パート 1 本記事は、Amazon Aurora MySQL version 2 (with MySQL 5.7 compatibility) to version 3 (with MySQL 8.0 compatibility) upgrade checklist, Part 1 を翻訳したものです。 Amazon Aurora MySQL 互換エディション バージョン 2 (MySQL 5.7 互換)は 2024 年 10 月 31 日に標準サポートの終了が予定されています。Amazon Aurora MySQL バージョン 2 の標準サポートの終了タイムラインについて
SQL/コマンドインジェクション、XSS等を横串で理解する - 「インジェクション」脆弱性への向き合い方 - Flatt Security Blog
こんにちは、@hamayanhamayan です。 本稿ではWebセキュリティに対する有用な文書として広く参照されているOWASP Top 10の1つ「インジェクション」について考えていきます。色々なインジェクションを例に挙げながら、どのようにインジェクションが起こるのかという発生原理から、どのようにインジェクションを捉え、より広くインジェクションの考え方を自身のプロダクト開発に適用していくかについて扱っていきます。 SQLインジェクションやコマンドインジェクション、XSSのようなインジェクションに関わる有名な手法について横断的に解説をしながら、インジェクションの概念を説明していきます。初めてインジェクションに触れる方にとっては、インジェクションの実例や基本的な考え方に触れることができ、その全体像を把握する助けになるかと思います。 また、既にいくつかのインジェクション手法を知っている方にと
note ではメインデータベースとして Aurora MySQL を採用し、日々発生する膨大なトラフィックを処理しています。Aurora MySQL v2 (MySQL 5.7 互換) の標準サポートは2024/10/31 に終了するため、これを機に v3 (MySQL 8.0 互換) へのアップグレードを行いました。 アップグレードは無事に完了しましたが、いくつかの問題にも直面しました。これらを共有することで、これからアップグレードを検討している方へ参考になればと思います。 事前に検討した課題アップグレード後に致命的な問題が起きたらどうするかv3 へのアップグレード後に v2 へ切り戻すことは容易ではなく、スナップショットなどからの復元が必要になります。データをロールバックすることになるため、ユーザ影響が極めて大きく避けたい事態です。 そのため、基本的に切り戻しはできないという前提でアッ
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
MySQL公式のDockerリポジトリがcontainer-registry.oracle.comに引っ越していた
この記事は MySQLのカレンダー | Advent Calendar 2023 の10日目の記事です。昨日は meijik さんの 最新のSQL標準(SQL:2023)とFirebird/MySQL/PostgreSQL | キムラデービーブログ でした。 TL;DRdockerhub のMySQLイメージはもうメンテナンスしていないっぽい ややこしいのだけれど、 docker pull mysql で取得するのは「Docker社がビルドしたMySQLイメージ」で、 docker pull mysql/mysql-server で取得するのが「Oracle社がビルドしたMySQLイメージ」だった引っ越したのは後者のみMySQL Server Community Edition - Repository Detail 5.7は5.7.16と5.7.33だけ、8.0は8.0.22とそれ以降し
前のエントリの続きです。 念を押しておきますが、このブログの「内容は個人の考えであって、所属組織とは方針が異なる」と考えてください。 さて、MySQL 8.0.xの単スレッド性能がどんどん遅くなってきた要因は幾つかありそうなので切り分けていきたいと思います。 まずは、数年前のエントリ「やはりC++はCよりも遅い？」の影響をできるだけ正確に見積もりたいところです。実行バイナリの最適化レベルを合わせて比較して初めて、ロジックの劣化が判るわけです。コンパイラのオプションの範疇でできるだけ最大の最適化を行って計測したいところです。いくつか試した結果、clangのPGO+LTO が手軽な中では最も効果があったのでそれで同じ計測をしてみましょう。(GCCのPGO+LTO と clangのPGOのみ はこれよりも少し劣ったのでとりあえず。) (補足) PGO は、一旦ターゲットとなる処理をプロファイリン
MySQLのREPEATABLE READとREAD COMMITTEDの違いを知るために色々試した - $shibayu36->blog;
MySQLのトランザクション分離レベルについてふんわりとした理解しかないなと感じた。もう少し理解するために、とくにREPEATABLE READとREAD COMMITTEDの違いを手を動かして色々確認してみた。 以下の記事を参考にした。 [RDBMS][SQL]トランザクション分離レベルについて極力分かりやすく解説 #SQL - Qiita MySQL :: MySQL 8.0 リファレンスマニュアル :: 15.7.2.1 トランザクション分離レベル 大まかな違い 公式ドキュメントを見る限り ノンリピータブルリード、ファントムリードが発生するか 範囲に含まれるギャップへのほかのセッションによる挿入をブロックするか の違いがありそうに見える。 ノンリピータブルリード、ファントムリードが発生するかを試す 以下のテーブルを作る。 CREATE TABLE `posts` ( `title`
GitHub.com を MySQL 8.0にアップグレード
GitHubは、15年以上前に単一のMySQLデータベースを持つRuby on Railsアプリケーションとしてスタートしました。それ以来、GitHubは高可用性を構築する、テスト自動化を実装する、データのパーティショニングを行うなど、プラットフォームのスケーリングと可用性のニーズを満たすために、MySQLアーキテクチャを進化させてきました。今日、MySQLはGitHubのインフラストラクチャの中核を担い、選択可能なリレーショナルデータベースの一部です。 このブログは、1200台以上のMySQLホストを8.0にアップグレードした物語です。私たちのサービスレベル目標(SLO)に影響を与えることなくフリートをアップグレードすることは小手先の技で済むようなものではありませんでした。計画、テスト、そしてアップグレード自体は1年以上かかり、GitHub内の複数のチームが協力しました。 アップグレード
Aurora 3.04.2 での DDL の予期しない挙動と Rails での対策 - freee Developers Hub
こんにちは、DBRE (Database Reliability Engineer) の shinta です。 今回は、Aurora 3.04.2 に存在する DDL の予期しない挙動について紹介したいと思います。 発見のきっかけ きっかけは、Aurora 3.04.1 に存在した以下の事象の検証でした。（CyberAgent 様の記事で事象の存在を知り、検証するに至りました。ありがとうございます！） ca-srg.dev これがどんな事象かというと、「ALGORITHM=INPLACE で特定の online DDL を実行している間、そのテーブルに reader からアクセスできなくなる」というものでした。 writer で DDL を実行している間、reader からそのテーブルにクエリを投げると以下のエラーが出ます。 Table 'db_name.tbl_name' doesn't
この記事は、『Software Design 2024年6月号』（2024年5月17日発売）の第1特集「SQLチューニングする前に知っておきたい 実行計画＆インデックスのしくみ」の連動企画です。ぜひ本誌特集1もお読みください。 適切なインデックスを設計する インデックスの調整によるクエリの高速化は、RDBMSを使用する際の数あるチューニングテクニックの中でも最もお手軽なものです。テーブルのカラムの定義を変えるわけではないので、クエリの結果に違いが生じず、アプリケーションを変更する必要性がないからです。適切なインデックスを付与するだけでチューニングが済むというのは極めて効率的です。それでは適切なインデックスとはどのようなものでしょうか。本記事では、まずインデックスを設計する際に重要なポイントを解説します。 インデックスとSQL構文 「どのカラムの組み合わせに対してインデックスを作成すべきか」
この記事は新野淳一氏のブログ「Publickey」に掲載された「GitHub、1200台以上のMySQL 5.7を8.0へアップグレード。サービス無停止のまま成功させる」（2023年12月12日掲載）を、ITmedia NEWS編集部で一部編集し、転載したものです。 米GitHubが提供するGitHub.comは、世界最大のソースコード管理システムを始めとするソフトウェア開発者向け支援サービスを提供しています。 そのGitHub.comはRuby on Railsで構築されており、同社はつねにRubyとRuby on Railsをアップデートし続けていることを今年（2023年）4月に明らかにしています。 参考：GitHubは200万行規模のRailsアプリケーションであり、毎週RailsとRubyを最新版にアップデートし続けている そして同社はこのGitHub.comを支える1200台以上
今年の汚れ、今年のうちに！MySQLで使っていないインデックスを削除しよう - クラウドワークス エンジニアブログ
この記事は クラウドワークス Advent Calendar 2023 シリーズ2 2日目の記事です。 こんにちは。crowdworks.jp SRE チーム 田中（@kangaechu）です。 年末といえば大掃除ですね。 皆さんのデータベースにも使っていないインデックスが溜まっていませんか？ お掃除してきれいな新年を迎えましょう。 手順 1. MySQLで使っていないインデックスの一覧を取得 未使用のインデックスは sys.unused_indexes ビューで確認できます。 dev.mysql.com しかし、このビューの元データである performance_schema テーブルは起動時から終了時までのデータしか保持していません。 Tables in the Performance Schema are in-memory tables that use no persistent
OCIについて知らない方向け AWSは知ってるがOCIを知らないという方は取り急ぎ以下のようなページを読むとイメージが掴みやすいかと思いますのでリンクを貼っておきます。 本件では細かい用語の違いなどの説明は省略します。 OCIへの移行理由 今回移行した理由はコスト削減が最大の理由でした。 オンプレからAWSに移行したのは3年前の2021年2月で当時のドル円相場は約106円でした。 2021年のAWS移行当時、RDSのReserved InstancesとEC2のSavings Plansを3年で購入していました。（通常は1年などで購入されるケースの方が多いと思いますが、歴史のあるサービスなので急激なリソースの増減はあまり無さそうではと考えたためとなります。結果としては円が強いタイミングで安く買えて助かりました） 移行を検討し始めたのはRI/SPが切れる1年前くらいで、その時点のドル円レート
Cloud SQL for MySQL 5.7 のデータを Cloud SQL for MySQL 8.x へ DMS を利用して移行してみた - VISASQ Dev Blog
はじめに こんにちは！DPE（Developer Productivity Engineering）チームの高畑です。 最近カーオーディオにハマっていて、スピーカーを変えたり DSP アンプを導入したりとオーディオの沼に腰あたりまで浸かってしまいました。 スピーカーケーブルをちょっと良いやつに変えたりしてみたんですが、正直違いが分かっていないので頭まで浸かるのはまだ先のようです。 現在、ビザスクでは遅ればせながら MySQL 5.7 から MySQL 8.x へアップグレードするためのプロジェクトが進行しており、既存のデータを移行するため諸々の検証を行なっていました。 検証を進めるにあたり、データの移行に DMS (Database Migration Service) を利用する方針となったので、経緯や方法をご紹介したいと思います。 移行方法の検討 当初、既存の MySQL 5.7 デー
MySQL アンカンファレンス開催したい。というかします。 概要 最近のMySQLはバージョニング方針も変わって、周辺ツールを含めた機能追加も着々とされている一方で、MySQL関連のイベントは減ってしまったような気がします。 コロナ以降、イベントが少ない気がするのは残念に思いつつも、最近の私には社外で活動できる余力がなく、社内にMySQLのプロ、その他DBのプロがたくさんいるので、なんとなく満足してしまっていました。 ですが、MySQL Advent Calendar 2023でいろいろなブログを一気に読んでいて、社内の会話だけで満足するのはもったいない。2024年はMySQLコミュニティのイベントに参加していきたいと思っていました。 オフラインで集まることも以前ほど慎重にならなくて良いので、MySQL Casualを開催することもできます(手を上げれば誰でも開催できると思っていますし、私
こんにちは。kimihiro_nです。 今回はアプリケーションの動作を保証するために不可欠なテストコードの書き方についてです。 特に外部依存要素のテストに焦点を当ててみていきたいと思います。 外部に依存するテストコード 皆さんはアプリケーションのテストコードを書いていますか？ 内部的な状態を持たず、入力と出力が常に変化しない関数であれば、テストコードを書くのは比較的容易です。実際に関数を呼び出ししてその出力と期待値が一致しているかをみればテストすることができます。 しかし実際にアプリケーションを開発する場合、データベースへの接続だったり外部へのAPI呼び出しだったりといった外部の状態に依存した処理が含まれることが多いです。このような場合、素直にテストを書くのが難しいです。 多くの場合モックを利用して実際のデータベース呼び出しを置き換えたり、テスト用のリソースをdockerなどで構築してダミ
2024年4月30日に、MySQLの新たなメジャーバージョン「MySQL 8.4.0」がリリースされました。本記事では、MySQLの新しい開発モデル「LTS」版と「Innovation Release」について紹介します。 はじめに 2024年4月30日に、MySQLの新たなメジャーバージョン(シリーズ)である「MySQL 8.4.0」がリリースされました。2018年4月にMySQL 8.0シリーズが正式リリースされて以来、実に6年ぶりのメジャーバージョン・リリースです。それまでのMySQLは概ね3年程度で新しいメジャーバージョンが公開されてきたので、今回の6年というのは、まさに「待望の」新バージョンと呼んでも差し支えないでしょう。 リリース方針の変更 MySQL 8.0シリーズが快調にリリースされ続けていた2023年7月に、今後のリリース方針の大きな変更に関するアナウンスがありました。か
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub、1200台以上のMySQL 5.7を8.0へアップグレード。サービス無停止のまま成功させる
MySQL 5.7 から 8.0 にしたらテストが激遅になった - Qiita
MySQL(InnoDB)のSQLパフォーマンスチューニングのエッセンス
MySQL 8.0アップグレード後に性能劣化したクエリ: セミジョイン編 - inSmartBank
MySQL 5.7 to 8 check list
大規模サービスのインフラを全面的にリプレイスした話 - Qiita
MySQL8.0で低速になったSELECT COUNTを高速化する - CyberAgent SRG #ca_srg
MySQL 8.0 は遅くなってきてる？何故？（１）
Blue/Green デプロイを使用した、RDS MySQL/PostgreSQLのアップグレード
note の Aurora MySQL を v2 から v3 へアップグレードしました｜tic40
Upgrading GitHub.com to MySQL 8.0
MySQL 8.0 は遅くなってきてる？何故？（２）
［Software Design連動企画］ 実践クエリチューニング | gihyo.jp
GitHub、1200台以上のMySQL 5.7を8.0へアップグレード サービス無停止のまま成功させる
AWS から OCI に移行してコストを約半額にした話 - Qiita
MySQL アンカンファレンスを開催したい - tom__bo’s Blog
アプリケーションの動作を担保するテストをどう書くか - JX通信社エンジニアブログ
実に6年ぶり!「MySQL」のメジャーバージョン「8.4.0 LTS」が新しいリリーススタイルで登場