はてなブックマーク

この記事はMySQLのカレンダー | Advent Calendar 2023 - Qiitaの19日目の記事です。 MySQLのredoログには何が書かれているのだろうか? そんな疑問を解決するために私はアマゾンの奥地へと旅立つことにしました。 MySQLはSQLをパースし、実行計画を立てたあと、実際にストレージ(メモリ含む)でデータを処理する部分はプラガブルなストレージエンジンに実装を移譲する設計になっています。 しかし、処理をストレージエンジンがトランザクションをサポートしないことも選択できるため、クラッシュリカバリのための機構を実装していない可能性もあります。 そのため、レプリケーションにも利用されるバイナリログがWrite Ahead Loggingされていて、クラッシュリカバリやPITRにもバイナリログが主に使われています。(と、筆者は理解しています。). なので、運用上はバイ

概要 この記事ではTiDBv6.1でのPoint In Time Recovery(PITR)について私なりの方法を紹介します。 運用中にめったに行うことはないですが、PITR (wikipedia)がいつでもできることは運用上重要ですよね。 しかし、残念なことに2022年07月06日現在、TiDB公式ドキュメントにPITRの説明はないようです。まずはこのことを確認し、その後、TiDB Binlogを利用してユーザデータをPITRする方法を紹介します。 ユーザデータと書いたのはTiDB Binlogという更新差分を取得する仕組みがDCLによる変更内容を補足しないためです。つまり、CREATE USER文やGRANT文は厳密にPITRすることができません。 (DCLによって更新されるデータを"ACLデータ"、それ以外のデータを"ユーザデータ"とします) 以前の記事に引き続き、GCP上で動作確認

あるMySQLインスタンスで検証のためにschema(database)をコピーしてほしい。というリクエストを受けたときに最速で対応する方法は何か検証してみました。 MySQLにschemaをコピーするコマンドはありません。 schemaをコピーする方法として例えば以下の5つがあります。同じMySQLインスタンス上でschemaをコピーするならどの方法が最速でしょうか? INSERT INTO ... SELECT ... mysqldumpしてrestore mydumper/myloaderでdump&insert xtrabackupしてrestore Transporable Tablespaceでdump & import アプリケーション開発者視点で実行しやすい方法から、DBAなどインフラエンジニアの権限(*1)がないと実行が難しい方法の順で並べてみました。 schema Aを

せっかくのGWなので、おもちゃを作りました。 Query Review Helperです。 github.com 背景 最近MySQLで実行されるクエリをレビューするタスクが異常に多くなってきました。 開発者の全員がindexやjoin, partition, limit offsetなどなどのハマりどころを知っているというのが理想ではありますが、そうも行きません。 大体EXPLAINをかけてtable scanになっていないか、sortやlimit offsetで劇的に重いクエリがないか確認すれば、すぐに問題になるようなことはありませんがいくつか問題があります。 複数のサービスを横串に見ていると各サービスのテーブル設計の詳細を知らない 大きいサービスだとテーブル数やカラム数が異常に多い(数百テーブル, 各テーブルに数十カラムとFKが、、、とか) tableやcolumn, subquer

概要 8.0.22のリリースノートを見るとprepared statementの挙動が変わっているらしい。 特にこれが気になったので、試してみる For a prepared statement of the form SELECT expr1, expr2, ... FROM table ORDER BY ?, passing an integer value N for the parameter no longer causes ordering of the results by the Nth expression in the select list; the results are no longer ordered, as is expected with ORDER BY constant. どうやら8.0.22からはSELECT expr1, expr2, ... FR

運用をしているとダウンタイムかありかに関わらず、alter tableにどれくらいの時間がかかるのか作業前に把握したいことはよくあります。 各種statusを見ることで一定時間でどれくらいの行を書き換えるかを把握することはでき、作業を始めてからであれば、あとどれくらい掛かりそうかは見積もれますが、alter tableの話が出た瞬間にどれくらい掛かりそうかの目処はつけたいです。 今回はalter時に実行されるDMLがなく、テーブルに断片化もないという理想的な環境で、各種Alter操作にどれくらいの時間がかかるのかを実験してみました。 環境やconfigの詳細はあえて書いていませんが、どちらにしろ実際には様々な要因が絡むので、このくらいの情報があれば充分かと思います。 概要 alter tableにかかる時間を計測 on/off memoryでALTER TABLEにどれくらい時間がかわるか

先週開催されたVLDB(Very Large Data Base)というDatabase分野のトップカンファレンスで松信さんがFirst authorの論文 MyRocks: LSM-Tree Database Storage Engine Serving Facebook's Social Graph が発表され、Best Industrial Paper Awardを受賞されました。 ↑ VLDB 2020 Awards - VLDB2020 Tokyoのスクショ 特にTwitterやブログ等で書いている人がいないようなので、この内容を紹介します。 VLDBはDatabase分野ではトップ中のトップカンファレンスで、新規のアーキテクチャやアルゴリズムが掲載されるものだと思っていました。 なので、VLDBにMyRocks論文が掲載されたと知って正直驚きましたが、内容を読んでみると松信さん

Database Internalsの輪読会の第7回 chapter 6, B-Tree Variantsの発表予定です。 chapter 6は6つの論文を軸にB treeの応用(亜種)について書かれていますが、それぞれの論文を紹介するにはページ数が少なく、「こんなのもあるよー」程度になっています。そのため、適当に読み飛ばす人も多いのではと思いますが、一つ一つの論文を読んでみるとかなり面白いです。 ここではchapter 6で紹介されている6つの論文を中心にB treeの研究を漁ってみた経過を超簡単にまとめます。 これらは論文を読みながら作ったメモなので、詳細については当日発表します。 興味のある方は勉強会に参加してみてください。 databaseinternals.connpass.com 僕はそもそもデータのIndexingに興味があり、この勉強会と関係なくこの調査及び実践(実装)は継

MySQLのストレージエンジンはplugableになっていて、APIを実装すれば自作のストレージエンジンを組み込むことができる。 ということで、試しにRedisをストレージエンジンとして使うRedis Storage Engineを作りました。 github.com 途中で飽きてしまった ちまちま実装するよりC++の勉強とInnoDB読んだほうが良さそうと思ったので、お蔵入りするつもりでしたが、Yahoo! Japanでストレージエンジンを研究開発しているという話で個人的に盛り上がったので、改めて作ったところまでを見直して、整理しておこうという趣旨です。 実装したものはCREATE TABLEとDMLがある程度カバーされたおもちゃですが、自作ストレージエンジン開発のためのドキュメントはなくなっていく一方なので(MySQL internal documentを含む既存のドキュメント・ブログ・

sakaikさんのブログで今月の日付一覧を得るクエリを読んでいて、ここで紹介されているクエリが手元で実行できなかったので、メモ。 sakaik.hateblo.jp 原因は手元の環境が8.0.17でVALUES()関数がなかったことが原因。 よく見るとvalues()関数でテーブルを作って、それを自己結合しつつ出力を作ってソートしている。 再帰CTEでシーケンスが作れるので、それを使っても良いかもなと思い、復習がてら書いてみました。 with recursive rec(V, D) as ( select 1, cast(date_format(@dt, '%Y-%m-01') as date) union all select V+1, date_add(D, interval +1 day) from rec where D < last_day(@dt) ) select D as

slow logの時間は何を計測しているのか? きっかけ とあるMySQLインスタンスで1Gbのネットワーク帯域を使い切ってレスポンスタイムが悪化していたという話を聞いた。 確かに遅いがlong_query_timeを小さくしてもslow_logは特に出ていなかったため、どのクエリが問題なのかを特定しづらかったらしい。 これを聞いたときはRedisとかインメモリのDBならまだしもMySQLがストレージより先に1GbのNICを使い切ることがあるのかーと驚いた。まあ、100GB以上のメモリも珍しくないので、ほとんどメモリから結果を返していれば1Gb/s以上返すことは難しくなさそうではある。 だが、long_query_timeを小さくしてもslow_logにクエリが出力されなかったという部分は気になった。 具体的にlong_query_timeがどれくらいなのか、同時接続数はどれくらいでQPS

Percona LIVE 2019に参加してきました。 前回の続きで初日(Tutorial Day)から Session Day 1, 2の3日間のうち2日目(Session Day 1)の内容です。 おそらく発表のスライドが公開されることと思いますが、全体が非公開になるものや非公開になるページがあるかもしれないので、ここではあえて概要だけと会場の雰囲気や僕の感想を書こうと思います。 また、英語の聞き取り能力が高くないため、勘違いした内容を書いている可能性が多分にあります。あくまで参考程度に読んでください。 各発表ごとのサブタイトルは発表中のものもあれば、メモを忘れて僕が勝手に書いたものもあります。 (メモからの校生も面倒なので、ここで丁寧語は終了です) Session Day 1 (2日目) 1日目のスケジュール -> https://www.percona.com/live/19/sc

MySQL8.0の機能を調べてまとめている。 Descending indexについて読んだまとめ。 dev.mysql.com MySQL 8.0では、Descending index(DESC, 降順のindex)がサポートされるようになった。 これまではASC(昇順)のindexを逆順にスキャンすることはできたが、パフォーマンス上のペナルティがあった。 Descending indexを使うことで、降順のアクセスでも正順でスキャンすることができる。 optimizerはDESCを含むマルチカラムindexであってもコストを考慮してこれを利用してくれる。 サンプル c1, c2カラムにasc, descの組み合わせでカラムを作った。 index名はasc, descの頭1文字をとってaかd mysql> create table t4 ( -> id int not null auto

where句なしでupdate文を実行するというオペミスがあった際にdummyのrelay_log(binlogをrenameしたもの)を使って、1ホスト単体でMTSを利用した一人replication的なことをしてPITRする方法の検証をしてみた。 何いってんだと思ったら下のlefredの発表資料を見てみてください。 その過程でいくつかの疑問が出てきたので、そこまでを書いていく。 ↓の発言に至った経緯と思ってもらえると良いです。 stopポジションとして指定したクエリまで、 mysqlbinlog -> 実行しない stop slave sql_thread until (file and pos)... -> 実行する(beginをまたいだ場合そのトランザクションごと実行??)— :tom__bo: (@tom__bo) 2019年1月17日 MySQL 5.7.17, GTID=OF

この記事はMySQL Casual Advent Calendar 2018 10日目の記事です。 皆さんMySQLの学習はどのようにされていますか? MySQLを含めたデータベースが落ちることはそのままサービスの停止につながることが多く、安定運用にはそれなりの知識と経験が必要だと思います。 データを管理しているという特性上、設定や運用方法に欠陥があると一時的にサービスが止まるだけではなく、取り返しのつかない障害になってしまう可能性もあります。 そのため、失敗しながら学ぶといったことは許されないにもかかわらず、運用する中でどういった問題が起こるのかは運用してみないとわかりにくく、さらに本番運用を想定したテストをすることも難しいため初学者が誰の手も借りずに一人前になるのはほとんど不可能だと思います。 MySQLは世界でもっとも普及しているオープンソースデータベースソフトウェア(公式HP)と公

最近いくつかのキーの反応が鈍くなってきて、はんだ付け入門しようかと迷っていたら2018年からキースイッチがハンダ付け不要で交換できるようになっていた。 たいした話ではないけど、買うとどんな感じなのかをほぼ写真で説明していく。 ergodox-ez.com Change any keyswitch on your ErgoDox EZ, at any time, without soldering and without voiding the warranty とあるようにキースイッチ(キーキャップじゃなくて)がはんだ付けなしで、付属のキーの引き抜き器具を使って簡単にキースイッチを外して超簡単に変えられる。 はんだ付けはそんなに経験がないので、うまく行くか怪しいし全部のキースイッチでやるととんでもない時間がかかりそうなので、新しいのを買うことにした。 ちょうど1週間で届いたので、供給も改善

"A critique of ANSI SQL isolation levels"(http://dl.acm.org/citation.cfm?id=223785)を読んだ。 1995年にMSの人とJim GrayでANSI SQL-92を批判する論文で、いろいろなところで解説記事等を見かける。 もう20年以上の前の論文だけど、最近はてなのid:alpicolaさんがこの論文の紹介を書いている。 developer.hatenastaff.com また、この論文を直接紹介しているわけではないけど、id:kumagiさんが書いているブログもこの論文と同じ内容をわかりやすく解説している。 qiita.com qiita.com さらにid:okachimachiorzさんがhttp://d.hatena.ne.jp/okachimachiorz/20121028/1351390461とhtt

※(注記) この記事は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)結果だけ書きます。 ※(注記) こ

mytxという、トランザクション分離レベルの違いを調査したり、並列するトランザクションでどのようにロックがかけられているかを実験するためのツールを作りました。 mytxとは MySQLで分離レベルごとの挙動を実験しようとした時に、ウィンドウを複数開いて順番にコマンド叩いていくのが面倒だなーと思ったので作りました。 github.com gihyoの第50回 トランザクション分離レベルを試してみるでもやっているような、トランザクションごとにコネクションを張って、ウィンドウを行き来しつつコマンドを打って、場合によっては確認用のウィンドウも作ってロックの状況を確認して、とやるところを、予めSQLをファイルに用意しておくことで簡単に試せるようになります。 これくらいなら他のDBにも対応しようと思えば出来ますが、今はMySQLを対象にしています。 例えば2つのトランザクションを次のような順番で実行し

Speedy Transactions in Multicore In-Memory Databases読んだ。 2013年にSOSPで発表された論文。 ↓論文リンク Speedy transactions in multicore in-memory databases 下手をするとただの論文の和訳になりかねないので、できるだけ要点に絞って書くようにする。 一方で、提案手法のアーキテクチャ・動作原理に関しては僕の理解も含めて詳細に書く。 (と言いつつ、結局全訳感が拭えないものになってしまった) ※(注記) この記事内の[n]は論文中のrefer番号をそのまま使ってその論文へのリンクとしています。 概要 Siloは近年のマルチコア化した環境でscalabilityを持つ、非常にパフォーマンスの高いインメモリDB Siloはメモリを有効活用するために、トランザクションIDを含む競合となりえるポイント

[n] は論文中のreferの番号をそのまま使っています。 Abstract この論文では2013年から存在したVoltDB DBMSの設計上の決断について説明している。 特に"concurrency control"と高可用性について議論している。 Introduction VoltDBの目的は伝統的なRDBMS(MySQL,DB2,SQL Server)より高速に動作することである。 これらのRDBMSは伝統的なトランザクション処理(TP)を行う一方で、最近のTPアプリケーションでは従来とは違ったユースケースが必要となっている。 例えばインターネットゲームの状態管理や、リアルタイム広告配信などで、これらでは大量のメッセージによる更新の繰り返しに、信頼性のあるTPを高速に行わなければならない。 この論文ではこういったTPをModernTPと呼んでいる。 VoltDBと研究面でのプロトタイ

大学のジムに登録して週3くらいで筋トレするようになって3ヶ月経った。 だいたい週3日1時間~1:30程度の筋トレが習慣になっている。 この3ヶ月は基本的な体づくりとしてBIG3の筋トレを基本に鍛えてきた。 最近はベンチプレスの重量を上げることばっかりになっている気もする。 3ヶ月経ったので、ざっくりここまでの感想を書いてみる。 トレーニング種目毎のフォーム、栄養学等調べたことも色々あるけれど、それはまたの機会に。。。 プロテイン ホエイプロテイン・カゼイン多めのプロテイン・クレアチンと3種類飲んでいる。 筋トレ後のホエイ、普段のクレアチンはしっかり効果を感じる。カゼインはあんまりいらないかなーと思っていて今ある分がなくなったら買わないかも。 体組成計での計測断念 最初の1ヶ月くらいは筋トレするしないに関わらず体組成計で毎日のように体脂肪量、骨格筋量を測っていた。 本当に僅かではあるけれど、

最近PHPのマイクロフレームワークであるsilexを使っていて、そろそろORMも使っていきたいので、symfonyでもおなじみのDoctrine ORMのチュートリアルを英語の勉強も兼ねて和訳・実行していくことにしました。 英語がきっちり訳せず理解できず変な部分もあるので、公開後も修正していくと思います (|| ́ロ`)o ではでは始めていきます( -_-)ノ 参考: Getting Started with Doctrine — Doctrine 2 ORM 2 documentation Getting Started with Doctrine 以下のことがわかるらしい ・ Doctrine ORMのインスコと構成の仕方 ・ PHPオブジェクトをDBにマッピングする ・ PHPオブジェクトからDBスキーマを生成する ・ EntityManagerを使ってDBにCRUD操作をする Gui

Systems Performance: Enterprise and Cloudを読んでいく。 前回の続き。 5章後半部分。 5.4 Methodology and Analysis このセクションでは、アプリケーションの分析とチューニングのための方法論について説明する。 分析に使うツールはここで紹介するか他の章を参照する。このトピックについては表5.2にまとめる。 より一般的な方法論については2章を見るように。 システムリソースや可視化についてもこの章で述べている。 これらの方法論は個々にまたは組み合わせて追っていく。筆者の提案はリストになっている順番に試していくことだ。 これらに加えて、開発しているものの言語や特有の分析テクニックを探そう。 そうすることで、すでに知られている問題や簡単な解決策が見つかることも多い。 5.4.1 Thread State Analysis この手法のゴ

はじめに Catechinというチーム名で大学の友人(@Kender_09, @o_sama3)とISUCON6に参加してきました。 結果はタイトル通り惨敗で、最初に気づいたボトルネックに全く手を付けなかったくらい、迷走してしまいました。 チーム内での役割は緩やかに分担していて、DB周りは僕、nginxは@o_sama3、golangのプロファイリングは@Kender_09でしたが、基本的に一人に丸投げではなく、3人で共有しつつ属人化は避けようにしていました。 3人ともそれほど何かに詳しいわけでもなく、ISUCONのために勉強する部分も大きかったので、判断ミスを防いだり、練習時は一緒に議論が出来たりしたので、良かったと思います。 言語はせっかくISUCON参加するならGoでと思って、予選前からGo一択で練習に付き合ってもらっていました。2人ともありがとう。 順位的には残念な結果に終わってし

ISUCON予選1日目にチーム名Catechinで参加しました。 結果が出たら人権をロストする可能性があるので、結果が出る前に当日にやった作業を振り返ってみる。 本選出場者が公開され、学生枠で2位(学生全体では3位)で本戦出場が決定しました(=゚ω゚)ノ 最後までgolangで頑張りました。 10:00~ コンテスト開始 用意しておいたansibleにsyntax errorと言われて驚く 10:20まで インスタンスを立ててから10分後に再起動というレギュレーションと、sshできてもアプリのデプロイができていないという状態をみて、落ち着くまでじっくり待つ 10:30頃 初期実装のperlのままベンチを実行して1288点を確認する 実装をgolangに入れ替えるもスコアが0でうなだれる 11:40まで 環境変数の設定 golangのプロファイラ(pprof)を挟む mysql,nginxで

Systems Performance: Enterprise and Cloudを読んでいく。 前回に引き続き自分用メモ。 後半は3節部分。 このブログに書き起こす作業に予想以上のコストがかかっているので、今後の章ではSolarisベースの説明に関しては書かないことにした。 Linuxの比較として特に重要と思われる部分は書くかもしれないが基本的には省いて書く予定。 3.3 Kernels このセクションではSolarisとLinuxベースのカーネルについて、歴史と特徴、パフォーマンスにおける違いの議論について紹介していく。 また、背景として、Unixの起源についても議論する。 いくつかの明確な違いとして、ファイルシステムのサポートと、パフォーマンス観測フレームワークの違いがある。 また、システムコールや、ネットワークスタックのアーキテクチャ、リアルタイムサポートやCPU, disk, I

Systems Performance: Enterprise and Cloudを読んでいく。 前回に引き続き自分用メモ 3章は長かったので、2分割。前半は2節まで。 3 Operating Systems OSとその内部のカーネルへの理解はシステムパフォーマンスに必要不可欠である。 この章ではこの本全体にわたって扱われるOSとカーネルの概要について触れる。 自分自身の知識と照らしあわせて読みすすめるとよい。 この章は2つのパートからなっている。 Background: 基本的な用語とOSの基礎知識 Kernels: LinuxとSolarisベースのカーネルについてまとめ パフォーマンスに関する、CPUスケジューリング、メモリ、ディスク、ファイルシステム、ネットワーキングがこの章の後に続く。 3.1 Terminology 以下がこの本で扱われるOSに関する用語である。 Operati