こんにちは、ヌーラボの中村です。BacklogのGitチームで開発やメンテナンス、その他諸々をやっています。本記事ではMySQLクライアントのバージョンアップの際に出くわしたおもしろい挙動を解説します。 概要 MySQL 5.7サーバーへの接続について、MySQL5系クライアントからMySQL8系クライアントへのバージョンアップを検証していたところ、特定のクエリだけ実行結果が0件になる現象が発生しました。(あるPerlのプログラムで5系のクライアントをサポートしていない環境があり、やむを得ずアップグレードを実施しました) インターネットで検索すると、「クエリに空白を入れる」「改行を追加する」などおまじないのような解決方法が散見されましたが、そんなはずはないと思い調査を進めました。 調査したところ、原因は以下の3つが合わさったことによるものでした。 MySQL 5.7ではクエリキャッシュが有
はじめに MySQL8.0 を使ったユニットテストがどうにも遅いので、気になって計測してみた。特に Truncate が遅い気がしたので検証。 MySQL5.7(5.7.44)と MySQL8.0(8.0.28)で比較する。 検証コード iwahara/mysql_performance: 記事用のパフォーマンス計測コード 検証用テーブル 検証に使うテーブル定義は以下の通り。主キーのみのテーブルと、index を1つ、2つ、3つ設定したテーブルを用意した。 照合順序は揃えてある。 CREATE TABLE `no_index` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `name` varchar(256) NOT NULL, `code1` varchar(8) NOT NULL, `code2` varchar(8) NOT NU
この記事は、はてなエンジニア 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
mysql57to8.md 確認すること メンテナンス時間をどれくらい取れるかで戦略が決まる。 基本的にはメンテナンス時間を十分に取れたほうが良い。 またリスクをどれだけ許容できるかもビジネスによるので要確認しておくべき。 基本的には一度切り替えてしまうとロールバックすることは簡単ではない。 覚悟を決めて突き進む必要がある 最初に諦めること MyISAMを使いたい 8でも動くけど諦めろ、もう未来はない InnoDBのほうがDisk サイズを消費する、countが遅い、などの課題はあるので簡単ではないが… InnoDB memcached Pluginとか使ってるんだよね 諦めろ、未来はない これを機にアーキテクチャを見直しましょう PKが無いtableがあるんだよね すべてのtableにまずPKを付けるんだ このあと、DMSを使ったりとかなにをするにしても死ぬ そもそもデータモデルとして死
Photo by Rubaitul Azad on Unsplashはじめにこんにちは、2021年4月にFinatextに新卒で入社し、まもなく3年目になるToshiya Matsuzakiです。サーバーサイドエンジニアとして、AWSでのインフラ構築とGoによるシステム開発を行っています。 先日、MySQL5.7系互換であるAmazon Aurora v2を使用していたリリース前のプロダクトのデータベースを、MySQL8.0系互換であるAmazon Aurora v3にアップグレードした際に、予期せぬバグが発生しました。調べたところ、MySQL5.7から8.0へのアップグレードに含まれていた破壊的変更点によるものでした。 そこで、今回のバグから得た学びと対応方法について書きたいと思います。現在稼働しているシステムに対して、MySQL5.7系から8.0系にアップグレードをすることを検討してい
MySQL 5.7と比べると、8.0の方が性能が良いという噂を簡単な検証で確認してみました。 結論としては、 8.0の方がINSERTは早い8.0の方がSELECTも早いけど、正しくインデックス貼られていれば同程度UPDATE、DELETEは同程度という結果でしたー! なお、サポート期限は以下のようになっています。
1.アップグレードの意義 バージョンアップを行うことは、パフォーマンスの向上、新機能の追加、セキュリティの強化など、それぞれに意義がある。 特にセキュリティに関しては、バージョンアップを行わないと、脆弱性に関するパッチを充てられない。 安全にWeb開発を行うためにも、サポート期限が切れる前にバージョンアップは行おう。 2.デフォルトの文字コードの変更 MySQL8から、デフォルトの文字コードがutf8mb4になった。 これにより、絵文字や幾つかの特殊な文字を保存できるようになった。 これらはメリットではあるが、絵文字や特殊な文字を使わないという方は、 今まで通り使用していた文字コードを指定して、過去のデータベースと互換性を保つ方が良いだろう。 加えて、defaultのcharacter setで設定していた人は、 今まで使っていた文字コードと変わってしまうので、自分で以前使っていた文字コー
この記事は、株式会社カオナビ 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倍遅くなるってやばいぞということで報告してくれた担当者と同じテストを自分でも実施してみると再現性があり、それが以下のどの
こんにちは。クラウド運用チームの飯塚です。 私たちは cybozu.com 本番環境の MySQL を昨年末から順次 8.0 系へアップグレードしており、前回の定期メンテナンスにおいて全てのインスタンスのアップグレードを完了しました。この記事では、私たちが MySQL 8.0 への移行に取り組んだ理由と必要になった対応について紹介します。 なぜ MySQL 8.0 へ移行したのか GTID-based レプリケーションにおける制限の緩和 再起動時に AUTO_INCREMENT のカウンタが巻き戻る問題の解消 実際に対応が必要だった MySQL 8.0 の変更点 utf8mb4 の照合順序のデフォルト値の変更 SQL_CALC_FOUND_ROWS と FOUND_ROWS() が deprecated に Connector/J のメタデータ取得処理の性能低下 sys.innodb_lo
静岡市でWeb開発しているkazuomatzです。 以前、こちらの記事で、Rails + MySQL で位置情報を扱う時に標準だったライブラリ activerecord-mysql2spatial-adapterについて書きました。 ライブラリの開発が止まってしまい、新しいRailsのバージョンに更新しようとすると対応されていないので、リポジトリをforkして、Rails6.0で何とか動かした話です。 今年、AWSのRDSのMySQL5.7系のサポートの終了がアナウンスされました。2024年2月以降、RDSでMySQL5.7を利用し続けるには、有償の延長サポートに入る必要があります。 というわけで今年は、MySQL5.7で稼働しているシステムをMySQL8に更新するお仕事が数件ありました(2023年12月現在、まだまだ絶賛実施中です)。 当然、MySQL5.7とMySQL8.0に移行するに
この記事は、hacomono Advent Calender 2023の20日目の記事です。 はじめに こんにちは、プラットフォームチーム所属のまこたすです。 この記事は主にMySQL5.7,MySQL8.0のcollation周りの挙動の違いについて書いています。AWS RDS MySQL5.7がEOLを迎える今、一番話したい内容はRails x MySQL5.7環境からRails x MySQL8.0環境へ移行する際にハマった話とそこからみる気をつけるべき観点という話題ではあるのですが、前提の話が長いので記事を2つに分けてお伝えします。今回はRailsの話は触れず、MySQLのcollation周りの話のみをします。 この記事で書くこと MySQL5.7, MySQL8.0でのサーバー, データベース, テーブルのcollationの決まり方とSHOW CREATE (TABLE|DA
railsが参照しているrdsをmysql5.7から8.0にアップグレードした時の注意点メモ utf8mb4を指定した場合は以下のパラメーターグループをutf8mb4にする必要がある character_set_database データベースの文字セットを定義します。文字セットは、文字を数値で表現する方法を定義するデータエンコーディングの一種です。 この設定は、新しく作成されるテーブルとそのカラムに使用されるデフォルトの文字セットを指定します。特定のテーブルやカラムに対して異なる文字セットを設定することも可能ですが、character_set_databaseはデフォルトの設定で、特定でない指定がない場合はこれが適用されます。 character_set_client ユーザーからのSQLステートメントがエンコードされている方法を定義します。クライアントからデータベースサーバーに送信される
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
タイトルの通り、「MySQL 8.0 の薄い本」(薄くない)を以下のリポジトリで配布しています。 https://github.com/hmatsu47/mysql80_no_usui_hon 出掛けた先のイベント・勉強会などでも物理本を配布しています。 2019/08/08 追記:MySQL 8.0.17 対応版をリリースしました。 2019/10/27 追記:MySQL 8.0.18 対応版をリリースしました。 2019/12/20 追記:MySQL 8.0.18 対応版第 2 刷をリリースしました。 2020/01/04 追記:MySQL 8.0.18 対応版第 3 刷をリリースしました。 2020/01/19 追記:MySQL 8.0.19 対応版をリリースしました。 2020/03/22 追記:MySQL 8.0.19 対応版第 2 刷をリリースしました。 2020/05/15
MySQL 8.0 にアップグレードする前に、このセクションで説明されている変更を確認して、現在の MySQL インストールおよびアプリケーションに適用される変更を特定します。 推奨されるアクションを実行します。 互換性のない変更としてマークされた変更は、以前のバージョンの MySQL との互換性がないため、アップグレード前に注意する必要がある場合があります。 弊社の目的はそれらの変更を避けることですが、各リリースの間の非適合性よりもさらに深刻な問題を修正するために必要である場合もあります。 インストールに適用可能なアップグレードの問題に互換性がない場合は、説明に示されている手順に従ってください。 MySQL Server 8.0 には、トランザクションテーブルのデータベースオブジェクトに関する情報を含むグローバルデータディクショナリが組み込まれています。 以前の MySQL シリーズでは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く