「日本国内でもトップレベルのスキルを持った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

10/22(金) 追記 この記事で解説している内容について解説する勉強会を開催することとなりました。以下のconnpassよりお申し込みください。 pixiv.connpass.com 10/22(金) 追記 pixivのブックマークについて ブックマークDBの問題について 具体的な対策内容 論理削除廃止・index追加・ブックマークタグのテーブル分割 適応ハッシュインデックスの無効化 アプリケーションコードのリファクタリング・全発行クエリの列挙と見直し 大きな更新処理の非同期化 結果 あわせてよみたい pixivではサービスの成長に伴い、気に入った作品に対して付けることができるブックマークの総数が急速に増加しており、ユーザーの皆様に滞りなくサービスを提供し続けるためブックマークに関するデータベース(以後DB)の負荷対策が必要になりました。 2021年2月より対策を行うプロジェクトを発足し

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

こんにちは。クラウド運用チームの飯塚です。 私たちは 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

こんにちは。クラウド運用チームで 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 したデータのリストア時のディスク

こんにちは。コネクト支援チームの風穴（かざあな）です。 この度サイボウズでは、GMOメディア株式会社とコンサルティング業務委託契約を締結させていただき、MySQLエキスパートのyoku0825さんに、いろいろと相談に乗って頂けることになりました。 MySQLについて検索したことがあるエンジニアなら、yoku0825さんのブログ「日々の覚書」のお世話になったことがない人はいないでしょう。それぐらいポピュラーなブログで、日本語で読めるMySQLの技術情報を長年発信し続けているのがyoku0825さんです。 yoku0825さん ということで、Garoonプログラマの杉山くんと一緒に、yoku0825さんにお話を伺ってみました。 yoku0825さんのお仕事 ──（風穴）：普段、どんなお仕事をされてるのですか？ yoku0825さん（以下、敬称略）：GMOメディアという、BtoC向けのWebサー

GitHubが障害を総括、43秒間のネットワーク断が1日のサービス障害につながった：データベースの不整合解消に時間 GitHubは2018年10月30日（米国時間）、2018年10月21日16時頃（米国太平洋時）から約24時間にわたって発生した障害に関する分析報告を、同社のブログに掲載した。これによると、ネットワーク機器の部品交換で生じた43秒のネットワーク接続断が、GitHubのメタデータ管理データベースの不整合を引き起こし、復旧に時間を要したという。 GitHubは2018年10月30日（米国時間）、2018年10月21日16時頃（米国太平洋時）から約24時間にわたって発生した障害に関する分析報告を、同社のブログに掲載した。これによると、ネットワーク機器の部品交換で生じた43秒のネットワーク接続断が、GitHubのメタデータを管理するデータベースの不整合を引き起こし、復旧に時間を要した

かなり昔に紹介したJdbcRunnerを、7年ぶりに更新しました。JdbcRunnerは各種データベースを対象とした負荷テストツールで、スクリプトでトランザクションを定義して多重実行し、スループットとレスポンスタイムを測定することができます。レスポンスタイムはきれいにグラフ化もできます。 JdbcRunner - 汎用データベース負荷テストツール - dbstudy.info sh2/jdbcrunner - GitHub Oracle Database 18c、MySQL 8.0、PostgreSQL 10といった現行バージョンへの追従がメインです。Oracle Database 18cとPostgreSQL 10は昔のままでも動いたのですが、MySQL 8.0に接続するためにConnector/J 8.0が推奨されていて、Connector/J 8.0を動かすためにはJava SE 8

「AWS、またパッチ当てたってよ」と聞いたので3度目のAurora（MySQL互換）R4テスト（mysqlslap）MySQLAWSAurora タイトル通り、です。 ※パッチを当てたのか別のことをしたのかは、自分ではまだ情報を捕捉できていません。そのため、今後情報を追記する可能性があります。 結果、「元の性能に戻ったみたい」です。 ※以下の記事の続報です。 MeltdownとかSpectreとか騒ぎがあったので、Amazon Aurora（MySQL互換）R4インスタンス再テスト（mysqlslap） 2018/01/15追記（01/16一部修正）： AWSとしては「対応を完了した」という認識のようですが、詳細な情報は出していません。 Processor Speculative Execution Research Disclosure ※2018/01/13 13:00 PST 更新版

MySQL 5.1＋InnoDB Plugin 1.0以降でのロック状態確認方法としては、こちらの記事が有名です。 MySQL InnoDBにおけるロック競合の解析手順（SH2の日記／SH2さん） 利用しているのがMySQL 5.6以前だったり、MySQL 5.7を利用していても複数バージョンが混在している環境では同一のクエリで確認できるメリットがありますので、今でもこれを使われている方が多いのではないかと思います（MySQL Casual Advent Calendar 2017の20日目でも、@soudai1025さんがビューの作成を勧められていました）。 なぜあなたは SHOW ENGINE INNODB STATUS を読まないのか（そーだいなるらくがき帳／そーだいさん） 一方、MySQL 5.7では、sysスキーマにロック状態確認ができるビューとしてsys.innodb_lock

MeltdownとかSpectreとか騒ぎがあったので、Amazon Aurora（MySQL互換）R4インスタンス再テスト（mysqlslap）MySQLAWSAurora 2018/01/13追記： 「AWSが再度パッチを当てたみたい」という情報があったので、3度目のベンチマークを行ったところ、db.r4.largeおよびdb.r4.xlargeについて、2017/10/末頃とほぼ同じ速度に戻ったことを確認しました。 「AWS、またパッチ当てたってよ」と聞いたので3度目のAurora（MySQL互換）R4テスト（mysqlslap） （以下、古い情報なので現在とは状況が異なります。） 以前、R4インスタンスが使えるようになったときにmysqlslapで性能テストをしたので、今回、同じ条件で再度R4インスタンスだけmysqlslapしてみました。 Amazon AuroraでR4インスタ

武蔵野Advent Calendar 2017の20日目の記事です。品川から参加しています。 今日はMySQL InnoDBの領域管理について勉強し、いくつか動作例を見ながらInnoDBに対する理解を深めていきたいと思います。アプリケーション開発者やデータベース管理者の方にとって明日からすぐに使えるノウハウとまではいきませんが、いつか何かの役に立てば幸いです。 まとめ InnoDBにはテーブルスペース、セグメント、エクステント、ページというデータの管理単位があるよ エクステント単位で空き領域が管理されているよ。だけどそれを知ったところであまり役には立たないよ 昇順INSERTが得意でランダムINSERTが苦手なのはよく知られているけれど、実は降順INSERTが得意だよ テーブルスペース、セグメント、エクステント、ページ InnoDBのデータが格納されるファイルのことをテーブルスペースと呼び

※ この記事はMySQL Casual Advent Calendar 2017の11日目の記事です。 A critique of ANSI SQL isolation levelsを読んで(読んだブログ)、MySQL(innodb)で分離レベルごとのanomaly(不整合)の発生について実験しました。使ったのはDockerで立てられる 8.0.3-rc-log MySQL Community Sereverです。 ここでは上記の論文であげられているanomalyとid:kumagiさんのブログ(いろんなAnomaly)で知ったread only anomalyが起こるかを分離レベルごとに試してみます。 最初に、それぞれのanomalyについての簡単な説明とkumagiさんのブログで使っている書き方を真似た図、それに対応するプランを整理し、(実行経過は省略してw)結果だけ書きます。 ※ こ

サンプルサーバーのパケットフィルタは最初は以下の内容で設定し、セキュリティを確保しています。 tcp 22 はプライベートLANからの受信のみ許可 tcp 3306 は 153.127.195.113 のappサーバーだけに公開 tcp 80 は公開 tcp, udp の 32768-61000 はアウトバウンド通信の戻りパケット用に許可 ストリーミングのフラグメントパケットは公開 ip は基本拒否 また IP アドレスを打たずにホスト名でアクセス出来るように /etc/hosts に以下のエントリを追加しました。 153.127.195.113 app 153.127.203.176 db MySQLクライアントで接続して TCP の状態を観察 ここから実際にサーバーを動かして、その挙動を観察していきます。db サーバーに db1 データベースを作成し、アクセスユーザー user1 を追

Keep your databases in control with the fabFORCE DBDesigner4. Whether you have to design an new database or manage your data and models. DBDesigner4 Online Forum fabFORCE provides OpenSource utilities, components and infos for Kylix and Delphi programmers. All released under the GPL. Utilities Components Kylix Infos Film, video and music production, editing and post production. 3D animation and im

2017/09/05 db tech showcase Tokyo 2017 http://www.db-tech-showcase.com/dbts/tokyo