MySQLが得意なこと、不得意なこと(仮)2021/12/17 Engineers in CARTA vol.2 #MySQL https://voyagegroup.connpass.com/event/231708/ 得意なことというより特異なことを紹介するコーナーになってしまった
pixivのブックマークに関する負荷対策をしました - pixiv inside
10/22(金) 追記 この記事で解説している内容について解説する勉強会を開催することとなりました。以下のconnpassよりお申し込みください。 pixiv.connpass.com 10/22(金) 追記 pixivのブックマークについて ブックマークDBの問題について 具体的な対策内容 論理削除廃止・index追加・ブックマークタグのテーブル分割 適応ハッシュインデックスの無効化 アプリケーションコードのリファクタリング・全発行クエリの列挙と見直し 大きな更新処理の非同期化 結果 あわせてよみたい pixivではサービスの成長に伴い、気に入った作品に対して付けることができるブックマークの総数が急速に増加しており、ユーザーの皆様に滞りなくサービスを提供し続けるためブックマークに関するデータベース(以後DB)の負荷対策が必要になりました。 2021年2月より対策を行うプロジェクトを発足し
「MySQLのフェイルオーバーテストをする」と聞いてぼんやり思ったこと
TL;DR 負荷をかけながらフェイルオーバーテストをするなら、負荷クライアント側で「どの書き込みが成功したのか」のログは必ず取っておく でないと、フェイルオーバー起因でデータロストが発生するのかしないのかのチェックができない フェイルオーバーシナリオ スイッチオーバー(手動での切り替え)を含めてざっと思いつくのはこれくらい。 スイッチオーバー mysqldの正常終了 mysqldの異常終了、特に、mysqld_safeやsystemdがmysqldを再起動させてしまう環境 mysqldのハングアップ カーネルパニック ファイルシステムのハングアップ 電プチ スイッチオーバー たぶんHAソリューションを作る時にちゃんとテストするからこれはそんなに問題にならない気がするけれど、(レプリケーションベースのソリューションの場合)「レプリケーション遅延が起こってる時のスイッチオーバー」で何が起こるか
MySQL実行計画の簡易検査ツールの開発とCIへの組み込み - ZOZO TECH BLOG
こんにちは、ECプラットフォーム部の権守です。普段はID基盤やAPI Gatewayの開発を行い、ZOZOTOWNのリプレイスに携わっています。 本記事では、ID基盤で開発・導入したMySQL実行計画の簡易検査を行うツールを紹介します。 ツール開発の経緯 RDBにおけるテーブル設計は利用するクエリに応じて適切なインデックスを設定するなど専門的な知識を必要とし、設計できる人が限られてきます。しかし、アプリケーション上で利用されるクエリは機能の追加・改修に伴って日々変化していくため、それら全てに目を通し、漏れなく適切な設計することは困難です。そこで、専門的な知識がなくても設計に問題がないかの簡易的な検査を行えるツールを開発し、CIに組み込むことで自動的に問題を検出できるようにしました。 ツール開発のアプローチ ID基盤ではDBMSとしてAmazon Aurora MySQLを使用しています。そ
プライマリーキー(primary key)はシーケンシャルな値で良いと思うよ - 角待ちは対空
zenn.dev を読んでの感想です。「シーケンスナンバーをPKにする」以外の項目については言及しませんが、言及しないことは正当性や妥当性を保証していることにはならないです。 InnoDB(MySQL)を想定してます。が、原理は割と一般的なので他のDBでも適用できることが多いと思います。 追記:一般的とは分散でないような"普通の"RDBMSを想定してましたが、分散システム(distributed systemないしreplicated system)のような場合では話が違います。 なぜシーケンシャルな値がよいか 端的にいうと書き込み操作時にバッファープール(baffuer pool)に読み混む必要のあるページが少なくて済むからです。その結果書き込み操作時にバッファープールにページが存在する可能性が高くレイテンシー的に有利になる可能性が高いです。 バッファープール、ページ、btreeなど具体
SELECT ... FOR UPDATEとUPDATEでデッドロックが出る人へ - 41から始めました
はじめに 最近は主に花粉症に悩まされており、目が痒くてたまりません。 また、娘の生活がガラッと変わったせいで、毎日貧乏ヒマ無しです。 そんな中、たまたま早起きできたので奮起して久々に書いてみました。 問題が起きる環境 MySQL8.0.17以前 transaction_isolationがREAD-COMMITTED WHERE句の条件が一意ではない。（フルテーブルスキャンだと発生しやすくなる） キーの値がたすきがけになってる トランザクション開始＋SELECT ...FOR UPDATE→UPDATEのようにロックを取っている 先に実行されたトランザクションが、たすきがけになっているキー値の若い（っていうのかな？）方のロックを取る 何が起きるかと言うと、SELECT ...FOR UPDATEのWHERE句で抽出した行に対してロックを取ってるのに、 後から別セッションで実行されたSELE
MySQLとインデックスと私
2021/05/24 サイボウズ開運研修 動画が以下のサイトからリンクされています - https://blog.cybozu.io/entry/2021/07/20/100000 - これに矢印を書きながらぐりぐりやっていたわけなので、資料単体だとわかりづらいと思います…
MySQL 8.0 への移行が完了しました ～さようなら全ての MySQL 5.7～ - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。クラウド運用チームの飯塚です。 私たちは 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
MySQL 異なるバージョン間でのmysqldumpおよびリストアについて - Database JUNKY
異なるバージョン、もしくは、異なる サーバ間で、データベースのdump (mysqldump) および restore リストアを実施した時に、リストア先にデータベースもテーブルもないはずなのに、キー重複（Duplicate entry)が起きたりしたことはありませんか？ え？、なにもないはずなのに。。。って。オカルトですよね。 この原因って、dump時の文字コードが原因している場合が多いですって話です。。。 プログラマのための文字コード技術入門 (WEB+DB PRESS plus) (WEB+DB PRESS plusシリーズ) 作者: 矢野啓介出版社/メーカー: 技術評論社発売日: 2010/02/18メディア: 単行本（ソフトカバー）購入: 34人 クリック: 578回この商品を含むブログ (129件) を見る 今回は、MySQL5.7のdumpをMySQL8.0にリストアしている
Djangoで文字コードutf8mb4でMySQLに接続する方法 - aoishiの備忘録
はじめに Djangoで文字コードがutf8mb4のMySQLデータベースを利用するためのメモです。 絵文字を含むデータを使うために文字コードがutf8mb4のデータベースを作成したのですが、クライアント側の文字コード設定を忘れてしまい、レコード追加時に下記のエラーが発生してしまったので設定方法をまとめました。 django.db.utils.InternalError: (1366, "Incorrect string value: '\\xF0\\x9F\\x8C\\xBF\\x0Ai...' for column 'message' at row 1") 環境 CentOS 7.4 Python 3.6.3 Django 1.11.5 MySQL 5.7.20 PyMYSQL 0.7.11 方法 MySQL接続に必要なパッケージのインストール Python実装のMySQLクライアント
MySQL 8.0登場！立ち止まることを知らない進化はこれからも続く。
ゴールデンウィークはいかがお過ごしされただろうか。今年は天気も良く、行楽日和が続いたように思う。 さて、先日MySQL 8.0が正式にリリースされた。少し時間が経ってしまったが、今回はMySQL 8.0の新機能について紹介したい。コミュニティ版のダウンロードはこちらから可能だ。 ひとつ前の正式バージョンはMySQL 5.7だったのだが、MySQL 8.0は非常に大きなリファクタリングが含まれており、5.x台のバージョン番号を捨て去ろうという話があった。そこで、次のメジャーバージョンは最初の桁を増やすということになったのだが、MySQL 6.0は過去に既に存在し、買収などの騒ぎで開発が頓挫してしまった経緯がある。7.xはMySQL NDB Clusterと被っている。というわけで、5.7の7の部分の次という意味合いもあって、8.0というバージョン番号を引っさげ、満を持しての登場となった。その
MySQLのFLOAT型を使う理由が見つからない件 - hnwの日記
MySQLのデータ型としてFLOAT型という型があるのですが、これを採用するのは混乱の元ではないか？と感じたので、その詳細を紹介します。 そもそもこの話のきっかけは「MySQLで6桁までの小数点を丸めずに扱うならFLOAT型を使うべき理由」という記事が目に止まったことです。それなりに人気を集めている記事のようですが、私の読んだ限りではFLOAT型を使うだけの根拠が文中から読み取れず、さらに類似する一次情報や英語記事が全く見つからなかったので、真偽が怪しい情報だと感じました。 その後、MySQL上で実験したりCソースコードを読んでみたりした結果、私の得た結論は真逆のものになりました。MySQL警察の方や浮動小数点数警察の方、追試や反論など頂けると助かります。 MySQLのFLOAT型とは MySQLのFLOAT型は原則としてIEEE754浮動小数点数単精度型（32bit）で実現されます*1。
mysqlでユーザ定義変数をつかう - maco's life
SELECTで取ってきたレコードをソートして、ソートした結果に連番でidふるみたいなことできないかなーとおもってmysqlのドキュメント読んでたら変数を使えることを知りました。 MySQL :: MySQL 5.7 Reference Manual :: 9.4 User-Defined Variables 変数使えるなら連番ふれるじゃんとおもってさっそくやってみた。 やりたいこと 先程も書いた通り結果を小さい順にソートして、小さい方から1,2,3...と通しの番号をふる テーブル mysql> SHOW CREATE TABLE user_point\G; *************************** 1. row *************************** Table: user_point Create Table: CREATE TABLE `user_poi
外部キー制約を無視してデータを操作する - R42日記
外部キー制約って、テーブルをドロップするときに邪魔ですよね。 ドロップの順序をキチンと指定しないと外部キー制約違反になるので。 そんな時は、こうしましょう。 SET FOREIGN_KEY_CHECKS=0; これで外部キー制約を無視してテーブルをドロップできます。 テーブルのドロップが終わったら SET FOREIGN_KEY_CHECKS=1; で元に戻しておくことを忘れずに。
雑なMySQLパフォーマンスチューニング
【第26回Elasticsearch勉強会】Logstashとともに振り返る、やっちまった事例ごった煮Hibino Hisashi
MySQL with InnoDB のインデックスの基礎知識とありがちな間違い - クックパッド開発者ブログ
こんにちは、サービス開発部の荒引 (@a_bicky) です。 突然ですが、RDBMS の既存のテーブルを見てみたら「何でこんなにインデックスだらけなの？」みたいな経験はありませんか？不要なインデックスは容量を圧迫したり、挿入が遅くなったりと良いことがありません。 そんなわけで、今回はレコードを検索するために必要なインデックスの基礎知識と、よく見かける不適切なインデックスについて解説します。クックパッドでは Rails のデータベースとして主に MySQL 5.6、MySQL のストレージエンジンとして主に InnoDB を使っているので、MySQL 5.6 の InnoDB について解説します。 InnoDB のインデックスに関する基礎知識 インデックスの構造 (B+ 木) InnoDB では B+ 木が使われています。B+ 木は次のような特徴を持った木構造です。 次数を b とすると、
SQLを繰り返し実行したら段階的に応答速度が上がった話 - なからなLife
MySQL Casual Advent Calendar 2016 - Qiitaの6日目の記事です。 AdventCalendar自体初参加でドキドキ、してたら、成り行きで2日連続。 コレ用のきれいなエビデンス取れるような環境要していなかったので、普段より荒っぽいですが、Casualな感じで失礼します。 大きなテーブルを繰り返しSELECTしてたら、挙動が変わったんですよ。 バッファに載っているなら載っているで早いだろうし、載っていいなら最初ガッツリ遅くて、次からグイっと速くなるだろうと思っていたんですよ。 バッファに載りきらないなら、何回やっても遅いだろうと思っていたんですよ。 で、ちょいと計測的なことをやってた関係で、同じSQLを何度か叩いて平均、中央を見ようと思っていたんです。 そしたら、 45.71秒、44.90秒、24.44秒、13.32秒、13.12秒・・・ と、段階的に応答
Amazon RDS編～RDSの設定を変更してみよう！～
こんにちは！中の人です。 前回までのレシピでは『Amazon Redshift編～パフォーマンス比較（MySQL vs Redshift）後編～』と題して、パフォーマンス比較の検証を行いました。 今回は『Amazon RDS編～RDSの設定を変更してみよう！～』ということで、一度立ち上げたRDSインスタンスに対して設定変更する方法について説明します。 その前に、Amazon RDSに関する情報をご紹介しましょう！ 先日AWSより、Amazon RDSがMySQL 5.6のサポートを開始したことが発表されました。 これにより、MySQLの様々な新機能が利用出来るようになるので、より便利にAmazon RDSを使用することが出来るようになりますね！ ※今回の発表の詳細に関するAWS公式ブログはこちら それでは実際に、作業をおこなっていきましょう！ 今回行うのは、DB parameterの変更と
macのMySQL5.7でエラー - tanaka's Programming Memo
MySQLでmysqldumpなどを使うときに以下のようなエラーが発生。 mysqldump: Couldn't execute 'SHOW VARIABLES LIKE 'gtid\_mode'': Table 'performance_schema.session_variables' doesn't exist (1146) 原因は、データベースの構造が更新されていないことでした。 mysqlを起動 以下でデータベースをアップグレード sudo mysql_upgrade -u root -p mysqlを再起動 以上で治りました。 以下、参考にしたURLです。 参考 MySQLをアップデートしたらエラーになったのでmysql_upgradeで直した | 本日も乙 MySQL :: MySQL 5.7 Reference Manual :: 4.4.7 mysql_upgrade —
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
逝くぞ最新版、罠の貯蔵は十分か
