MySQL の binlog について調べたメモ - まっしろけっけ
MySQL の binlog について 実際に実行された更新系クエリの情報が記述されていてなんらかの理由によりデータが壊れた際の データ復旧とかにも役にたつ。 binlog の format には以下の 3 種類ある フォーマットの種類 設定値(文字列) 設定値(数字) 備考 ステートメントベース STATEMENT 1 実際に実行された SQL を記録 行ベース ROW 2 実際に変更された行のデータの情報を記録 ミックス MIXED 0 基本的にはステートメントベースと同じで非決定性のクエリの際は行ベースと同じ形式のログを出力する ここら辺は DB server を構築する際にレプリケーションとかを考えると思うので 基本的には理解している内容だと思われます。 今回は binlog の中身を除いて実際にどうなってるの？というところを調べた。 実際にログを出力させて比べる 環境 Mac M
MySQL8.0で低速になったSELECT COUNTを高速化する - CyberAgent SRG #ca_srg
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
リレーショナル・データベースの世界
序文 私の仕事は、DBエンジニアです。といっても別に望んでデータベースの世界へきたわけではなく、当初、私はこの分野が面白くありませんでした。「Web系は花形、データベースは日陰」という言葉も囁かれていました。今でも囁かれているかもしれません。 ですが、しばらくデータベースを触っているうちに、私はこの世界にとても興味深いテーマが多くあることを知りました。なぜもっと早く気づかなかったのか、後悔することしきりです。 もちろん、自分の不明が最大の原因ですが、この世界に足を踏み入れた当時、先生も、導きの書となる入門書もなかったことも事実です。 今でこそバイブルと仰ぐ『プログラマのためのSQL 第2版』も新入社員には敷居が高すぎました (2015年2月追記：その後、自分で第4版を訳出できたのだから、 人生は何があるか分からないものです)。 そこで、です。このサイトの目的は、データベースの世界に足を踏み
The growing pains of database architecture | Figma Blog
While these fixes moved the needle, they had limitations. By analyzing our database traffic, we learned that writes— like gathering, updating, or deleting data—contributed to a significant portion of database utilization. Additionally, not all reads or data fetching could be moved to replicas due to application sensitivity to replication lag. So, from both a read and write perspective, we still ne
New – Amazon RDS Optimized Reads and Optimized Writes | Amazon Web Services
AWS News Blog New – Amazon RDS Optimized Reads and Optimized Writes Way back in 2009 I wrote Introducing Amazon RDS – The Amazon Relational Database Service and told you that: RDS makes it easier for you to set up, operate, and scale a relational database in the cloud. You get direct database access without worrying about infrastructure provisioning, software maintenance, or common database manage
[mysql 16253] Re: [mysql 16252] ORDER BY句を指定しなかった場合のSELECT結果について
From: "yoku ts." <"yoku ts." <yoku0825@xxxxxxxxxx>> Date: Thu, 9 Jul 2015 20:13:07 +0900 Subject: [mysql 16253] Re: [mysql 16252] ORDER BY句を指定しなかった場合のSELECT結果について こんばんは、yoku0825といいます。 わたしもマニュアルに見つけられなかったんですが、 実装上は「条件が揃えば同じレコードが返る」です。 テーブルスキャンの場合、 * InnoDBではクラスターインデックスの昇順に並びます * PRIMARY KEYがあればPRIMARY KEY, PRIMARY KEYがなくてUNIQUE KEYがあれば最初に定義されたUNIQUE KEY, どちらもなければ6バイトの暗黙の行ID順に並べられます。 https://gist.gi
MySQLでORDER BYをつけないときの並び順 - かみぽわーる
メリークリスマス！🎅🎄 このエントリはMySQL Casual Advent Calendar 2016の24日目です。 今日はこれの話です！ @eagletmt 実装と実行計画依存です(たとえばInnoDBで単一カラムのインデックスが使われた場合のsort orderはprimary keyになるはずです)— Ryuta Kamizono (@kamipo) December 4, 2016 @eagletmt すいません、すこし間違いがありました。もし hoge_id = ? のような絞り込みで単一カラムのインデックスが採用された場合はsort orderはprimary keyになるはずです。InnoDB前提なら基本的に実行計画依存です。— Ryuta Kamizono (@kamipo) December 4, 2016 @eagletmt MySQLでorder by無しのと
MySQLの不要データをテーブルローテーションでイージーに削除した - LIFULL Creators Blog
検索エンジンチームにいながら外部公開APIのメンテナンスもしている加藤宏脩です。 この記事では、毎日大量に書き込まれ膨れ上がったMySQLのテーブルを、 テーブルローテーションさせることで不要なデータを継続的かつ安全に削除する処理の実装をしたのでそれについてお話したいと思います。 利用している技術 Amazon RDS for MySQL Engine version: 5.7.41 Amazon ElastiCache for Redis Engine version: 6.2.6 起きていた問題 LIFULLのとあるサービスは、アプリケーションとMySQL、DBの結果をキャッシュするRedisがあるというよくみる一般的なアーキテクチャで運用しています。 このMySQLのテーブルは毎日100万件以上のレコードが追加されていく状態になっており、 総レコード数は６億件を超え、容量は2TBを超
Amazon RDS Blue/Green Deployments を色々と検証してみた！
こんにちは！ スターフェスティバルでインフラエンジニアをやっております @koonagiです。 早いことにもう1月も終わりますね。 1月のうちにブログを書こうと思っていたら、あっという間に終盤になってしまっていて急いでこの記事を書いていますｗ さて、先月のre:Inventでリリースされた Amazon RDS Blue/Green Deployments について、最近検証したのでそのことについて書いていこうと思います。 Aurora v1(MySQL 5.6)が2月末でサポート終了となるため、Aurora v2(MySQL 5.7)へのバージョンアップの際にAmazon RDS Blue/Green Deploymentsを活用しようと考えており、事前準備として検証を進めました。 Amazon RDS Blue/Green Deploymentsとは 公式からの引用です。 ブルー/グリ
受取期限の過ぎたデータをMySQL上から削除する話 | GREE Engineering
こんにちわ。せじまです。今回は地味で泥臭い話をします。ただ、割と平易な内容かと思いますので、初学者の方にもオススメです。 はじめに ゲームでは、受取期限のついたログインボーナス的なものがよくあります。ユーザが期限までに受け取らないと、ユーザからそのデータは不可視になりますが、必ずしも、不可視になった瞬間にデータベースから直ちに削除される、というわけでもありません。バッチジョブか何かで、ガベージコレクションのように削除するケースが多いのではないでしょうか。 また、論理削除という概念もあります。論理削除についてはいろいろ意見や考え方があるかと思いますので、ここでそれについては論じませんが、「削除フラグが立ってユーザから不可視になった後、三ヶ月以上経過したデータを削除したい」みたいなことは、ゲームに限らず、しばしばあるんじゃないかなと思います。 こういった、ユーザから不可視になってしばらく経過し
index->lock の競合について 〜ベンチマークはちゃんとチューニングして〜
他に忘れないうちに書きたいこともあったのですが、世に出るまで書けないので、ソースと関係ない一般的なこと（バージョン5.7以降）を書きます。（書かない方のことは書けるようになる頃には忘れてしまうかも…） index->lockの競合を直して欲しい。という人がいまだに居たりするのです。色々試しましたが、多分殆どの場合は理解不足・チューニング不足です。私自身はindex->lockの競合が不可避なベンチマークに結局会っていません。 特にMySQLとその他のRDBMSを比べる場合にはちゃんと最適化した負荷をかけないとMySQLが悪く見えるのでベンチマークをする際には気をつけて欲しいものです。 5.7で更新・参照並列性を高めるために導入された、index->lockのSXロック（Sロックは可能・SX/Xロックは不可）は、基本的にそのindexにpageを追加・削除するような処理をする際に保持されます
MySQL with InnoDB のインデックスの基礎知識とありがちな間違い - クックパッド開発者ブログ
こんにちは、サービス開発部の荒引 (@a_bicky) です。 突然ですが、RDBMS の既存のテーブルを見てみたら「何でこんなにインデックスだらけなの？」みたいな経験はありませんか？不要なインデックスは容量を圧迫したり、挿入が遅くなったりと良いことがありません。 そんなわけで、今回はレコードを検索するために必要なインデックスの基礎知識と、よく見かける不適切なインデックスについて解説します。クックパッドでは Rails のデータベースとして主に MySQL 5.6、MySQL のストレージエンジンとして主に InnoDB を使っているので、MySQL 5.6 の InnoDB について解説します。 InnoDB のインデックスに関する基礎知識 インデックスの構造 (B+ 木) InnoDB では B+ 木が使われています。B+ 木は次のような特徴を持った木構造です。 次数を b とすると、
InnoDB の行レベルロックについて解説してみる
自分の浅はかな理解だと、Deadlock が起こる理由が説明できないケースに遭遇したので、InnoDB の行レベルロックについて調べてまとめてみました。 「行レベルロックだと、同じ行を更新する場合にしか Deadlock が起こらないんでしょ」と思っているような人が対象です。 また、主に InnoDBのロックの範囲とネクストキーロックの話 - かみぽわーる を参考にさせていただいたので、そちらの内容がすんなり理解できる方には冗長な内容だと思います。 MySQL のバージョンは 5.6.33 です。 サンプルデータ 次の SQL で作成したデータを扱うことにします。 CREATE TABLE `orders` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `product_id` int(10) unsigned NOT NULL, `us
SQLで羃等にDBスキーマ管理ができるツール「sqldef」を作った - k0kubun's blog
sqldefのリポジトリ github.com これは何か Ridgepoleというツールをご存じでしょうか。 これはRubyのDSLでcreate_tableやadd_index等を書いてスキーマ定義をしておくとそれと実際のスキーマの差異を埋めるために必要なDDLを自動で生成・適用できる便利なツールです。一方、 で言われているように、Ridgepoleを動作させるためにはRubyやActiveRecordといった依存をインストールする必要があり、Railsアプリケーション以外で使う場合には少々面倒なことになります。*1 *2 そこで、Pure Goで書くことでワンバイナリにし、また別言語圏の人でも使いやすいよう、RubyのDSLのかわりに、誰でも知ってるSQLでCREATE TABLEやALTER TABLEを書いて同じことができるようにしたのがsqldefです。 使用例 現時点ではMy
Waiting for table metadata lockの対処の仕方、おさらい。 - なからなLife
MySQL Casual Advent Calendar 2018 - Qiita 8日目の記事です。 駆け込み。 やきなおしです。 わりとニーズがあるらしく、このネタで過去エントリにちょいちょいアクセスがくるので、とにかく急いでいる人用に、シンプルにまとめました。 MySQL5.6、5.7で使えます。 たぶん8.0でも使えるんじゃないかな。知らんけど。 MySQL5.7でPerformance_schema.metadata_locksが追加されたけど、これも設定入れないと使えないんだよね。 犯人を特定する。 1. information_schema.innodb_trxを全件参照する。 列は以下の通り。 trx_id trx_state trx_started trx_requested_lock_id trx_wait_started trx_weight trx_mysql_th
MySQLと「令和」 - tmtms のメモ
新元号が「令和」に決まったことなので、MySQLでの扱いについての話を。 普通の文字 「令」も「和」もJIS第一水準に含まれている基本的な文字なので普通に日本語が使用できるcharsetで使用できます。 mysql> create table t ( utf8mb4 varchar(255) charset utf8mb4, utf8mb3 varchar(255) charset utf8mb3, utf16 varchar(255) charset utf16, utf32 varchar(255) charset utf32, cp932 varchar(255) charset cp932, eucjpms varchar(255) charset eucjpms, sjis varchar(255) charset sjis, ujis varchar(255) charset
そろそろTempTableストレージエンジンについて一言言っておくか
MySQL 8.0で内部的に作成されるテンポラリテーブルが、HEAPストレージエンジンからTempTableストレージエンジンへと変更されたことは、皆さんもご存知だろう。このストレージエンジンはテンポラリテーブル専用として設計されたもので、実体を持ったテーブルとしての利用は想定していない。一応、internal_tmp_mem_storage_engineオプションを指定することで、従来のHEAPストレージエンジンも選択は可能であるが、個人的にはそれはお勧めしない。 TempTableストレージエンジンは、メモリとディスクの両方を自ら使い分ける。これは、従来型のテンポラリテーブルとは違う。HEAPストレージエンジンはインメモリ専用で、tmp_table_sizeあるいはmax_heap_table_sizeを超えるサイズが必要になると、ディスク上のテーブルへと自動的に変換が行われるという仕
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
『Aurora MySQLログの収集と分析基盤の紹介 - LayerX エンジニアブログ』へのコメント
How to count SQL databases quickly in PostgreSQL and MySQL
B+Tree index structures in InnoDB
