それが僕には楽しかったんです。

僕と MySQL と時々 MariaDB

Go 再入門 ~基本的なデータ構造周り~

はじめに

どうも、最近自分と同い年のプロダクトに触れて死ぬほど苦しんだけんつです。
ここ数ヶ月ずっと MySQL の検証や DBMS の勉強をしてきて思ったのだが、コード書いてない。
読む機会は履いて捨てるほどあるが、コード書くことなさすぎてめちゃくちゃ書けなくなっていた。昨日書いてみてこんなに書けないかと驚いた。
なので、リハビリをかねてハイパー中途半端に知っているぐらいの Go の再入門やろうと思います。
未読だった Effective Go で「ここわかんねーわ」とか「お、これは学びだな」と、思ったところをやっていきます。

golang.org

今日はデータ構造周り。

Allocation with new()

Go にはメモリ割当を行うための組み込み関数として new と make がある。まずは new から。
new は単純に、ある型 T に対して new(T) と使用すると、メモリ領域を初期化せずに zero-value を持たせた上で確保しそのポインタを返すという挙動を取る。
例えば次のようなコードを実行する場合、実行結果は以下の通りになる。

package main

import "fmt"

type Person struct {
	Age  int
	Name string
}

func main() {
	p := new(Person)
	fmt.Printf("%+v\n", p)

	num := new(int)
	fmt.Println(*num)
}
❯ go run alloc_new.go
&{Age:0 Name:}
0

これが例えば、Effective Go にあるような sync.Mutex や bytes.Buffer にあるようなものだとこうなる。

package main

import (
	"fmt"
	"sync"
	"bytes"
)

type SyncedBuffer struct {
	Lock sync.Mutex
	Buffer bytes.Buffer
}

func main() {
	p := new(SyncedBuffer)
	fmt.Printf("%+v\n", p)
	
}
❯ go run alloc_new2.go
&{Lock:{state:0 sema:0} Buffer:{buf:[] off:0 lastRead:0}}

zero value によってすぐに利用できる構造体も存在する。
ちなみに var hoge T で変数を宣言した場合、それはポインタではないが new と同じように zero value をもつ。
初期化を伴わない*1と言われることが多い。

Allocation with make()

次は組み込み関数の make。make(T, args) という形を取るが、T に当てはまる型は slice, map, channel だけという特徴がある。
また new は返す値がポインタなのに対してこっちはポインタではない。またこちらは初期化を伴う。zero value と初期化の違いがわかりにくいので、中でもわかりやすい slice を例にする。
make を使って int を要素にもつスライスを作成するコードとその実行結果をあげる。

package main

import "fmt"

func main() {
	s := make([]int, 10, 100)
	fmt.Println(s)
	fmt.Printf("len(%d)\n", len(s))
	fmt.Printf("cap(%d)\n", cap(s))
}
❯ go run alloc_make.go
[0 0 0 0 0 0 0 0 0 0]
len(10)
cap(100)

実行結果からわかるように make を使用してスライスを作成した場合は array, len, cap *2の初期化を伴う。
これが new, make の違いとなる。

Arrays

配列はメモリの詳細なレイアウトを決める時に役立ち、割当を回避することができる場合もあるが基本的にはスライスのビルディングブロッックになっている。
また C の配列と比較して以下の違いを持っている。

  • 配列は値。配列に配列を渡すと全ての値がコピーされる。
  • 関数へ渡す時はポインタではなくコピーが渡される
  • サイズも含めて配列は一つの型として扱われる。[3]int, [2]int は別の型として扱われる。

Slices

Slice は Array のラッパーで連続するデータに対して、汎用的で強力なインターフェースを提供している。
行列のように明確な次元をもつ必要が無い限り、大抵は Slice を利用する。Slice は元になる配列への参照を持っていて、あるスライスを別のスライスに代入すると二つのスライスは単一の配列に対する参照を持つこととなっている。
これは関数の引数にする場合も同様に動作することに注意が必要。

例えば以下のコードを実行すると、次のような結果が得られる。

package main

import "fmt"

func main() {
	a := [10]int{1,2,3,4,5,6,7,8,9,10}
	s1 := a[:]
	s2 := a[2:]
	fmt.Println(a)
	fmt.Println(s1)
	fmt.Println(s2)

	s1 = s2
	s2[0] = 1
	fmt.Println(a)
	fmt.Println(s1)
	fmt.Println(s2)
}
❯ go run slice.go
[1 2 3 4 5 6 7 8 9 10]
[1 2 3 4 5 6 7 8 9 10]
[3 4 5 6 7 8 9 10]
[1 2 1 4 5 6 7 8 9 10]
[1 4 5 6 7 8 9 10]
[1 4 5 6 7 8 9 10]

おわりに

この調子で進めていきたい

*1:Go の変数は宣言だけだったとしても zero value が必ず入るためわかりにくいが、初期化とは区別されているみたい

*2:src/runtime/slice.go - The Go Programming Language

Database Internals を読み解く ~Introduction and Overview~

はじめに

ゴールデンウィークが外出自粛一択になってしまったので前から気になっていた Database Internals を買った。
なので、ぼちぼち読み始めつつ学んだことをメモ程度にまとめていきたい。

shop.oreilly.com

参考文献の構成

前半はストレージエンジン、後半は分散システムについての二部構成になっている。
ストレージエンジン部分は B-Tree Index やトランザクション処理とリカバリー、ファイルフォーマットなど、これぞストレージエンジン感のある部分が解説されている。
分散システム部分は分散トランザクションレプリケーション、分散システムにおける一貫性などの話が展開される。

愚直に最初から読んでいく。

Introduction and Overview

DBMS Architecture

コンポーネント間の区別などに違いがある場合もあるがDBMS の大まかなアーキテクチャは以下の図のようになっている。*1 *2
f:id:RabbitFoot141:20200504181338p:plain

DBMS は一般的にサーバ・クライアントモデルを取る。クライアントからのリクエストはトランスポートサブシステムで受け取り、下のレイヤーへと伝播していく。
サーバインスタンスはリクエストを受け取り次第、クエリをパーサーにかける。ここでは単なる構文解析の他にアクセスコントロールの確認を行う。これらの手順を全てパスした場合、オプティマイザによる最適化が行われる。ここでの最適化というのは冗長な部分やそもそもに不要な部分の除去、その後に行われるカーディナリティ*3をはじめとした統計情報を用いた効率的な実行方法の構築などを指す。
クライアントのリクエストによってわたってきたクエリが最適化までされた段階で実行計画が提供される。ここで提供される実行計画は結果が確実に返却される一連の流れであり、結果は同じだが効率が異なる複数の実行計画から最適なものが選択される。
その後はストレージエンジン内で複数のコンポーネントを跨いで実行される。ストレージエンジンには次の要素が含まれる。

  • Transaction Manager

Transaction Manager では DBMS 内で論理的整合性が崩れないようにトランザクションを管理する。

  • Lock Manager

Lock Manager はトランザクションが実行されている間、データベースオブジェクトが整合性などに違反しない状態を維持するために必要な同時実行制御上必要なロックを管理する。

ディスク上のデータ整理とアクセスを管理する。ここでのアクセスメソッドとはヒープファイルや B-Tree, LSM Trees などの選択を含む。

  • Buffer Pools

メモリ上のデータ管理、キャッシュする。リカバリに関するログなどもここで扱う場合がある。

On-Memory vs Disk-Based DBMS

DBMS はメモリ上にデータを持っておく場合*4と、ディスク上にデータを持っている場合がある。*5
オンメモリといっても、一次データをメモリ上に持っているだけで WAL のような機構を持っている場合はログをディスク上に吐く場合が多い。ディスクベースの DBMS はディスク上に一次データを持っているが、一時的なストレージとしてメモリ上にキャッシュしている。
オンメモリの利点としては比較的低いアクセスコスト、パフォーマンス、アクセス粒度の面でディスクベースの DBMS より優位な点がある。またその実装を主にメモリが対象になるためディスクベースのそれと比較してシンプルになりやすい。

OS の観点から見るのであれば、オンメモリであればメモリの確保、開放といった管理を抽象化できるという利点存在し、ディスクベースではデータのシリアライズ方式や参照方法、断片の再構成*6などを行う必要があるため複雑化しやすい。
メモリ上でデータを管理する場合、揮発することを考慮しなければならないことが大きな制限となるがこの点は不揮発性メモリの登場によって解消される可能性が出てきている。

Durability in On-memory DBMS

オンメモリでデータを扱う場合はその耐久性はどのように確保されるかが重要な観点となっている。
この問題は、多くの場合ディスク上にバックアップをとることで解決している。*7 また、実際にデータそのものをシリアライズして持っているのではなく WAL (Write-Ahead Log) のようなにシーケンシャルなログを持っている場合が多い。

Column Versus Row-Oriented DBMS

列指向か行指向かという話なので、RDB に関しての話。
それぞれ、行と列でデータ構造を分割して*8保存する。MySQL, PostgreSQL は行指向データベース。

Row Oriented Data Layout

このタイプの DBMS はデータをレコードか行として保持する。
表形式にすごく近い表現方法をもつデータレイアウトだが、表形式とは異なる。またこの形式の場合、レコードや行を一意に特定できるキー*9が存在するなら様々な面でうまく働く。
また行指向データレイアウトの大きな利点として行単位でデータにアクセスし、保存することが前提となるので空間局所性*10が向上する。これはディスクの1ブロック内*11 (()) にページがもつ全てのデータを格納できる場合、特に効果を発揮する。

Column Oriented Data Layout

列指向データベースは行を列に分けて保存する。あまり馴染みがないと思ったのは正しく、なぜならいわゆる Web 系のデファクトスタンダードである DBMS では採用されていないことが多いため。
この列指向データレイアウトを採用する場合どこに利点があるのかと、データ分析に利用する場合は行指向であれば不必要なデータも一旦読み込まれてしまう*12ことがあるが、列指向はその名の通り列で分かれているためパフォーマンスを出しやすい。
列で分割されていると普通に使う時辛くないかとおもうことがあるかもしれないが、それを解消するため列指向データレイアウトはデータの最小構成単位がタプルになっていることが多い。このタプルは仮想IDと列の値の組になっていることが多く一意に行に相当するものを探索することが可能となる。

Data file and Index File

DBMS の最も大事な目的はデータを管理し、迅速なアクセスを提供することにある。そのために、物理的なデータをどのように管理するかを考慮する必要がある。*13
実データはファイルに持っておくことがほとんどだが、フラットファイルではなく実装依存の固有形式なファイルフォーマットをとっていることが多い。これにはいくつかの理由がある。
まずはストレージの観点から、ファイル操作時のオーバヘッドを最小にしたいという理由がある。次にアクセス、正確には読み込みに関連して限りなく小さいステップでデータを読み込むため。最後に更新時になるべく変更回数を小さくするため。
このような理由を可能な限り満たすために Slotted Page といった形式が存在する。また削除については多くの DBMS では削除マーカーを置いて論理削除することで削除したように見せている。

DBMS はデータ操作、特に検索においてインデックスと呼ばれるものを補助的に使用している。インデックスはレコードのメタデータを持っているため、全てのレコードを探索することなく少ない回数でレコードを探索することができる。

Data Files

データファイルは index-organized table, heap-organized table, hash-organized table などを用いて実装することができる。
index organized table はデータ自身とそのインデックス情報を含み構成される。またそのレコード自体は順に配置されるため、実際にスキャンするときはその内容をシーケンシャルスキャンすればよい。
heap organized table は順序関係ないレコードの列挙で構成されるヒープファイルの集まりとなる。順序は関係ないが基本的にレコード順になっている。レコードが追加されてもファイルの再構成などを必要としないが、特に検索時にそれぞれのレコードに対するインデックスがないとフルスキャンするはめになる。
hash-organized table ではレコードそのものはキーのハッシュ値によってバケットに格納される。レコードは追加順かキー順でソートすることで検索が高速化できると言われている。

Index Files

インデックスは前述の通り、レコードを効率的に検索できるように構造化したものを指す。インデックスを構築するのに必要なデータはレコードを識別するキー*14か主キーになる。
インデックスには大きくわけて二つの種類がある。プライマリインデックスとセカンダリインデックス。MySQL で言えば主キーがあれば自動的に付与される*15ものがプライマリインデックスで、手動で後から貼ったインデックスをセカンダリインデックスという。
記憶がただしければ、セカンダリインデックスを用いて検索した場合、セカンダリインデックスのリーフノードの値はプライマリインデックスの値であり、それが判明した段階でプライマリインデックスで検索し最終的にレコードにたどり着くはず。
インデックスを含む場合、ファイルの構成方法を二つ存在する。 インデックスを含めたまま物理ファイルにするタイプと、インデックスは別ファイルに分割するタイプ。前者を Index organized table というらしい。
前者はプライマリインデックス、後者はセカンダリインデックスでよく使われるみたい。

最後に

ここで学んだこととしてあげたものはこの後詳細な解説がやってくるのでざっくりとまとめておいた。
次はインデックス、 B-Tree に関する話。

*1:分散 DB など分散システムを前提とする場合はコンポーネント間の関係はこの限りではない。これはあくまでも単一のサーバインスタンスとして DBMS を利用する場合。

*2:図はまとめていい部分や今回読まない部分を含んでいるため書籍の図と差分がある

*3:カラムの値の種類がレコードの数に対して多いか少ないか https://www.shift-the-oracle.com/words/cardinality.html

*4:Redis のようなオンメモリ KVS

*5:大体の RDBMS はディスク上に一次データを持っている。MySQL もこれ。

*6:slotted-page などで論理削除を用いない場合を考えるとわかりやすい

*7:Redis であれば AOF, RDB がまさにそれにあたる

*8:正確にはデータのシリアライズに関連する

*9:いわゆる主キー、Primary Key、PK と呼ばれるやつら

*10:キャッシュを考慮する場合に重要となる指標のひとつ。連続または近傍領域に対して比較的近い時間にアクセスがされればされるほど空間局所性があるという。ある特定の行の次の行にアクセスすることは冷静に考えてそれなりに存在する

*11:多くの場合は 4 KB ではあるが、DBMS によってはページサイズが 8 KB, 16 KB になっている場合もある。さらにページを 16 KB として、それを連続して配置させるスペースという概念で管理する場合もある。

*12:SELECT column FROM hoge みたいにすれば列だけ読み込めるじゃんと思うかもしれないが、内部的には必ずしも特定の列のみをストレージメディアから読み込んでいるとは限らない。

*13:オンメモリは考えない。あくまでも確定した実データをディスクに持っている場合の話。

*14:重複が認められているもの。ただし重複しすぎると大体インデックスが効かなくなる

*15:主キーがない場合はその代替に相当するもので構成される

MySQL 8.0.20 で導入された binlog transaction compression をハイパー雑に検証する

はじめに

どうも、共通新人研修がビジネス職よりで割とコードとか書いている暇がなかったけんつです。
今週からはエンジニアの研修で RFC と格闘することが強制されて息を吹き返してます。


MySQL 8.0.20 がリリースされて、めちゃくちゃ気になったのが binlog 圧縮。
他にも検証をしていたのだけど、なんか急に気になったので全てを放り投げて調べてみたくなった。
zstd というアルゴリズムを用いて binlog を可逆圧縮する機能が追加になったので、どれだけ圧縮されるのか調べてみた。
MySQL の運用に関わったことがなく、完全に趣味で追っているので binlog 関連の検証として正しい方法なのかはわかっていないので間違っているところがあったり、改善点があれば教えて欲しい。

前提環境と検証方法

github.com

ここの master ブランチにあるコンテナ群で検証した。
MySQL 8.0.19, zstd を有効にしたMySQL 8.0.20, zstd を無効にした MySQL 8.0.20 で特定の sql ファイルを実行して生成される binlog ファイルのサイズを比較する。
binlog 圧縮を有効にすることと、パスワードログインを可能にする設定以外は全てデフォルト。
圧縮レベルも指定できるが今回はデフォルトの 3 で行っている。

それぞれの設定は以下にある。
https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_binlog_transaction_compression_level_zstd
https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_binlog_transaction_compression

圧縮レベルは増加すればするほど、ストレージ領域とネットワーク帯域を節約できるが CPU リソースを多く使用してしまうという
いつものトレードオフが存在している。


リリースノートの文献

以下のリリースノートにある、引用部分を参照する。
dev.mysql.com

From MySQL 8.0.20, you can enable binary log transaction compression on a MySQL server instance. When binary log transaction compression is enabled, transaction payloads are compressed using the zstd algorithm, and then written to the server's binary log file as a single event (a Transaction_payload_event). Compressed transaction payloads remain in a compressed state while they are sent in the replication stream to replication slaves, other Group Replication group members, or clients such as mysqlbinlog. They are not decompressed by receiver threads, and are written to the relay log still in their compressed state. Binary log transaction compression therefore saves storage space both on the originator of the transaction and on the recipient (and for their backups), and saves network bandwidth when the transactions are sent between server instances.

You can enable binary log transaction compression on a MySQL server instance using the binlog_transaction_compression system variable, which defaults to OFF. You can also use the binlog_transaction_compression_level_zstd system variable to set the level for the zstd algorithm that is used for compression. This value determines the compression effort, from 1 (the lowest effort) to 22 (the highest effort).

ハイパー雑に和訳すると。

MySQL 8.0.20 からサーバインスタンスでバイナリトランザクションを圧縮することが可能になった。
圧縮する場合、トランザクションペイロードは zstd アルゴリズムを使用してバイナリログを圧縮する。
このときサーバはバイナリログファイルに1つのイベントとして書き込む。
スタンドアローン時やレプリケーション時を問わず圧縮された状態で送信され、受信時に解凍されない。
この特性によりトランザクションの送信、受信においてストレージ領域とネットワーク領域を節約する。

やってみた

MySQL 8.0.19, 8.0.20 の docker コンテナを起動して mysql client に入ってから以下の sql ファイルを実行する。

mysql> source sql/class.up.sql
mysql> source sql/hashjoin.up.sql

この状態で ./docker/mysql8019|mysql8020/data/ 以下の binlog ファイルのサイズを確認する。

// MySQL 8.0.19
-rw-r-----    1 hoge  hoge   3102158  4 29 03:01 binlog.000001
-rw-r-----    1 hoge  hoge    890060  4 29 03:03 binlog.000002
// MySQL 8.0.20
-rw-r-----    1 hoge  hoge    298346  4 29 03:01 binlog.000001
-rw-r-----    1 hoge  hoge    130275  4 29 03:02 binlog.000002
// MySQL 8.0.20 without zstd compression
-rw-r-----    1 hoge  hoge   3102159  4 29 03:55 binlog.000001
-rw-r-----    1 hoge  hoge    890061  4 29 03:56 binlog.000002

大体 binlog.000001 は 1/10 ~ 1/9 あたりのサイズになっているっぽい。
binlog ファイルの分割が発生した上で binlog.000001 のサイズが縮小しているのでおそらくそのぐらい圧縮されるとみても良いのか?というところ。

binlog.000002 に関しては 1/9 ほどになっている。

これだと怪しいのでみんな大好き sakila sample database で試してみた。

// MySQL 8.0.20
❯ ll ./docker/mysql8020/data | grep "binlog"
-rw-r-----    1 hoge  hoge    298170  4 29 10:57 binlog.000001
-rw-r-----    1 hoge  hoge       156  4 29 10:57 binlog.000002
-rw-r-----    1 hoge  hoge        32  4 29 10:57 binlog.index

// MySQL 8.0.19
~/mysqlProject/mysql-poc master*
❯ ll ./docker/mysql8019/data | grep "binlog"
-rw-r-----    1 hoge  hoge   3102158  4 29 10:57 binlog.000001
-rw-r-----    1 hoge  hoge       155  4 29 10:57 binlog.000002
-rw-r-----    1 hoge  hoge        32  4 29 10:57 binlog.index

この状態で以下のファイルを実行すると

mysql> source sakila-db/sakila-schema.sql;
mysql> source sakila-db/sakila-data.sql;
// MySQL 8.0.20
~/mysqlProject/mysql-poc master* 1m 59s
❯ ll ./docker/mysql8020/data | grep "binlog"
-rw-r-----    1 hoge  hoge    298170  4 29 10:57 binlog.000001
-rw-r-----    1 hoge  hoge    590183  4 29 11:01 binlog.000002
-rw-r-----    1 hoge  hoge        32  4 29 10:57 binlog.index

// MySQL 8.0.19
~/mysqlProject/mysql-poc master*
❯ ll ./docker/mysql8019/data | grep "binlog"
-rw-r-----    1 hoge  hoge   3102158  4 29 10:57 binlog.000001
-rw-r-----    1 hoge  hoge  1359983  4 29 11:01 binlog.000002
-rw-r-----    1 hoge  hoge        32  4 29 10:57 binlog.index

大体 1/2 程度、ファイルサイズが減少している。
もうちょっと binlog にいろいろ突っ込みたいので、sakila db を drop してもう一回やり直した場合、次のようになった。

~/mysqlProject/mysql-poc master* 24s
❯ ll ./docker/mysql8020/data | grep "binlog"
-rw-r-----    1 hoge  hoge    298170  4 29 10:57 binlog.000001
-rw-r-----    1 hoge  hoge   1180403  4 29 11:13 binlog.000002
-rw-r-----    1 hoge  hoge        32  4 29 10:57 binlog.index

~/mysqlProject/mysql-poc master*
❯ ll ./docker/mysql8019/data | grep "binlog"
-rw-r-----    1 hoge  hoge   3102158  4 29 10:57 binlog.000001
-rw-r-----    1 hoge  hoge   2719998  4 29 11:13 binlog.000002
-rw-r-----    1 hoge  hoge        32  4 29 10:57 binlog.index

1/2 ~ 1/3 あたりをフワフワしている。

perfomance_shema をみてみる

binary_log_transaction_compression_stats をみるとどの程度圧縮されたのか、圧縮適用外のトランザクションがどれぐらいあったかをみることができる。
MySQL :: MySQL 8.0 Reference Manual :: 26.12.11.11 The binary_log_transaction_compression_stats Table
みてみると、大体 58% ほど圧縮されているようなので大体ただしいのかなといったところ。

mysql> select * from binary_log_transaction_compression_stats\G;
*************************** 1. row ***************************
                            LOG_TYPE: BINARY
                    COMPRESSION_TYPE: ZSTD
                 TRANSACTION_COUNTER: 60
            COMPRESSED_BYTES_COUNTER: 2249088
          UNCOMPRESSED_BYTES_COUNTER: 5293704
              COMPRESSION_PERCENTAGE: 58
                FIRST_TRANSACTION_ID: ANONYMOUS
  FIRST_TRANSACTION_COMPRESSED_BYTES: 2185
FIRST_TRANSACTION_UNCOMPRESSED_BYTES: 4310
         FIRST_TRANSACTION_TIMESTAMP: 2020-04-29 02:32:49.437426
                 LAST_TRANSACTION_ID: ANONYMOUS
   LAST_TRANSACTION_COMPRESSED_BYTES: 193
 LAST_TRANSACTION_UNCOMPRESSED_BYTES: 212
          LAST_TRANSACTION_TIMESTAMP: 2020-04-29 02:36:34.471615
*************************** 2. row ***************************
                            LOG_TYPE: BINARY
                    COMPRESSION_TYPE: NONE
                 TRANSACTION_COUNTER: 151
            COMPRESSED_BYTES_COUNTER: 94042
          UNCOMPRESSED_BYTES_COUNTER: 94042
              COMPRESSION_PERCENTAGE: 0
                FIRST_TRANSACTION_ID: ANONYMOUS
  FIRST_TRANSACTION_COMPRESSED_BYTES: 105
FIRST_TRANSACTION_UNCOMPRESSED_BYTES: 105
         FIRST_TRANSACTION_TIMESTAMP: 2020-04-29 02:32:45.334943
                 LAST_TRANSACTION_ID: ANONYMOUS
   LAST_TRANSACTION_COMPRESSED_BYTES: 209
 LAST_TRANSACTION_UNCOMPRESSED_BYTES: 209
          LAST_TRANSACTION_TIMESTAMP: 2020-04-29 02:36:34.452032
2 rows in set (0.00 sec)
余談

圧縮レベルを最大にして同じことを行い、ファイルサイズを比較しても大体 1/2 ~ 1/3 で推移していて「?」となった。
その辺の設定をみてみると " from 1 (the lowest effort) to 22 (the highest effort). " とあるので、もしかすると圧縮レベル以外に
何か別の要因がないと圧縮率は向上しない?

一回だけ雑に SQL を叩きまくったら 1/7 程度に減少したケースがあったけど再現しなかったので余談としている。要検証。

さいごに

binlog ファイルが良い感じに圧縮されると見ていいのか自信がないが物理的な容量が減少していることはわかった。大体半分ぐらいになるっぽい。
計算リソースについては言及していないので、圧縮レベルとファイルサイズがどのようにそれらと関わってくるかがわかっていない。
あと圧縮レベルを上げても満足に圧縮されないケースがあったので、このへんも努力的な意味合いでのレベルなのかそれとも強制力があるかどうかみたいなところは
まだまだ追っていく必要がありそう。

2020/04/29 4:42

MySQL が死ぬぐらいの SQL (source sql/hashjoin.up.sql をもう一回実行すると死ぬ)をぶん投げると 1/5 程度になることが確認できたけど
その場合、バイナリログの圧縮にどのような影響がでるのか要検証

2020/04/29 11:43

sakila sample database を使った場合に binlog.000002 のファイルサイズがどれくらい減少しているのか検証したので追加している。

2020/04/29 12:08

パフォーマンススキーマで確認できることがわかったので追記。

MySQL 8.0.19 と docker-compose 環境下で Single-Primary InnoDB Cluster を構築する

はじめに

InnoDB Cluster がどういうものか知ってはいるが構築したことがなかったのでとりあえず構築してみた。
github.com
今回は MySQL Shell をホストマシンに置き、MySQL Server x 3, MySQL Router を docker コンテナで建てる。
MySQL Shell のコンテナを使っても良いが、手動で行いたいため今回はホストマシン上で操作する。またこの都合により、MySQL Shellが関連する docker コンテナには固定で IPv4 のアドレスを割り当てている。

環境

  • mysql 8.0.19
  • ubuntu 18.04
  • docker 19.03.5
  • docker-compose 1.23.0

参考資料

dev.mysql.com

InnoDB Cluster の構築

InnoDB Cluster とは

MySQL InnoDB Cluster とは MySQL Group Replication + MySQL Router + MySQL Shell で構築可能な高可用性ソリューションを指す。


Group Replication がベースとなっているため、構築時における要求や制限は Group Replication のものに左右される。*1
また基本的に InnoDB Cluster の基幹は Group Replication であるがそれを InnoDB Cluster として、構成し管理するための AdminAPI が MySQL Shell により提供されるものを利用する。これにより Group Replication を直接操作することなく InnoDB Cluster
を操作出来る。

要件

まず Group Replication を使用するため、サーバインスタンスも Group Replication と同様の要件を満たす必要がある。実際に要件を満たしているかどうかを AdminAPI の dba.checkInstanceConfiguration() で確認する。

ストレージエンジンに関しては InnoDB 以外の MyISAM 等を選択することが Group Replication では可能であるが InnoDB Cluster 構築時は InnoDB のみでメンバを構成する必要がある。またそれと同時に全てのインスタンスでパフォーマンススキーマを有効にする必要がある。

また、バージョン 8.0.17 以降では server_id を通常のレプリケーション構築時と同様に InnoDB Cluster 内で一意に設定する必要がある。

MySQL Shell の導入

手元に MySQL Shell がなかったので以下のドキュメントを参考に導入する。
dev.mysql.com

各サーバインスタンスの設定を修正する

MySQL Shell で dba.checkInstanceConfiguration() を実行することで確認できる。

 mysqlsh -u root -h 127.0.0.1 -p -P 33060
Please provide the password for 'root@127.0.0.1:33060': ****
MySQL Shell 8.0.19

Copyright (c) 2016, 2019, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
Other names may be trademarks of their respective owners.

Type '\help' or '\?' for help; '\quit' to exit.
Creating a session to 'root@127.0.0.1:33060'
Fetching schema names for autocompletion... Press ^C to stop.
Your MySQL connection id is 13
Server version: 8.0.19 MySQL Community Server - GPL
No default schema selected; type \use <schema> to set one.
 MySQL  127.0.0.1:33060 ssl  JS > dba.checkInstanceConfiguration();
Validating local MySQL instance listening at port 33060 for use in an InnoDB cluster...

This instance reports its own address as 7147fa7c00f5:33060
Clients and other cluster members will communicate with it through this address by default. If this is not correct, the report_host MySQL system variable should be changed.

Checking whether existing tables comply with Group Replication requirements...
No incompatible tables detected

Checking instance configuration...

NOTE: Some configuration options need to be fixed:
+--------------------------+---------------+----------------+--------------------------------------------------+
| Variable                 | Current Value | Required Value | Note                                             |
+--------------------------+---------------+----------------+--------------------------------------------------+
| binlog_checksum          | CRC32         | NONE           | Update the server variable                       |
| enforce_gtid_consistency | OFF           | ON             | Update read-only variable and restart the server |
| gtid_mode                | OFF           | ON             | Update read-only variable and restart the server |
+--------------------------+---------------+----------------+--------------------------------------------------+

Some variables need to be changed, but cannot be done dynamically on the server.
NOTE: Please use the dba.configureInstance() command to repair these issues.

{
    "config_errors": [
        {
            "action": "server_update", 
            "current": "CRC32", 
            "option": "binlog_checksum", 
            "required": "NONE"
        }, 
        {
            "action": "server_update+restart", 
            "current": "OFF", 
            "option": "enforce_gtid_consistency", 
            "required": "ON"
        }, 
        {
            "action": "server_update+restart", 
            "current": "OFF", 
            "option": "gtid_mode", 
            "required": "ON"
        }
    ], 
    "status": "error"
}

binlog_checksum, enforce_gtid_consistency, gtid_mode の設定を修正する必要があるみたい。

binlog_checksum

このオプションではバイナリログの各イベントにチェックサムを付与することが可能になる。デフォルトは CRC32。
マスタースレーブ環境下でスレーブに認識されない異なるチェックサムの形式を指定している場合にスレーブが自身の binlog_checksum を NONE に変更しレプリケーションを停止する。後方互換性において懸念がある場合は明示的に NONE を設定する。
https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_binlog_checksum

enforce_gtid_consistency

GTID を使用したレプリケーションを行う場合にログを確実に記録できる構文のみ実行を許可することで強制的に GTID の一貫性を確保したい場合に設定する。ON, OFF 以外に WARN があり、その場合は一貫性に反することが許容されるが警告が出るようになる。
https://dev.mysql.com/doc/refman/8.0/en/replication-options-gtids.html#sysvar_enforce_gtid_consistency

gtid_mode

GTID ベースのログを有効にするかどうかの設定を行う。
https://dev.mysql.com/doc/refman/8.0/en/replication-options-gtids.html#sysvar_gtid_mode

InnoDB Cluster の構築

InnoDB Cluster は MySQL Shell から、AdminAPI を使いサーバインスタンスを操作することで構築可能となっている。
手順自体は簡単で

  1. dba.createCluster('hoge'); でクラスタを作成
  2. dba.addInstance(other_node_option) でノードを追加する

これだけとなっている。
ただここにたどり着くまでの設定などで docker を前提とする場合いくつかの罠が存在したり
公式ドキュメントにはないが Group Replication の設定を追加する必要がある。それは最後にまとめて記述する。

まずは InnoDB クラスタを作成する。

 MySQL  172.30.0.60:3306 ssl  JS > var cluster = dba.createCluster('singlePrimaryCluster');
A new InnoDB cluster will be created on instance '172.30.0.60:3306'.

Validating instance configuration at 172.30.0.60:3306...

This instance reports its own address as 172.30.0.60:3306

Instance configuration is suitable.
NOTE: Group Replication will communicate with other members using '172.30.0.60:33061'. Use the localAddress option to override.

Creating InnoDB cluster 'singlePrimaryCluster' on '172.30.0.60:3306'...

Adding Seed Instance...
Cluster successfully created. Use Cluster.addInstance() to add MySQL instances.
At least 3 instances are needed for the cluster to be able to withstand up to
one server failure.

createCluster は無事に完了したのでステータスを確認する。

 MySQL  172.30.0.60:3306 ssl  JS > cluster.status();
{
    "clusterName": "singlePrimaryCluster", 
    "defaultReplicaSet": {
        "name": "default", 
        "primary": "172.30.0.60:3306", 
        "ssl": "REQUIRED", 
        "status": "OK_NO_TOLERANCE", 
        "statusText": "Cluster is NOT tolerant to any failures.", 
        "topology": {
            "172.30.0.60:3306": {
                "address": "172.30.0.60:3306", 
                "mode": "R/W", 
                "readReplicas": {}, 
                "replicationLag": null, 
                "role": "HA", 
                "status": "ONLINE", 
                "version": "8.0.19"
            }
        }, 
        "topologyMode": "Single-Primary"
    }, 
    "groupInformationSourceMember": "172.30.0.60:3306"
}

大丈夫っぽい。

次にこのプライマリに対してノードを2つ追加する。

 MySQL  172.30.0.60:3306 ssl  JS > cluster.addInstance('root@172.30.0.68:3308')

WARNING: A GTID set check of the MySQL instance at '172.30.0.68:3308' determined that it contains transactions that do not originate from the cluster, which must be discarded before it can join the cluster.

172.30.0.68:3308 has the following errant GTIDs that do not exist in the cluster:
98f05a53-691a-11ea-9705-0242ac1e0044:1-9

WARNING: Discarding these extra GTID events can either be done manually or by completely overwriting the state of 172.30.0.68:3308 with a physical snapshot from an existing cluster member. To use this method by default, set the 'recoveryMethod' option to 'clone'.

Having extra GTID events is not expected, and it is recommended to investigate this further and ensure that the data can be removed prior to choosing the clone recovery method.

Please select a recovery method [C]lone/[A]bort (default Abort): C
NOTE: Group Replication will communicate with other members using '172.30.0.68:33081'. Use the localAddress option to override.

Validating instance configuration at 172.30.0.68:3308...

This instance reports its own address as 172.30.0.68:3308

Instance configuration is suitable.
A new instance will be added to the InnoDB cluster. Depending on the amount of
data on the cluster this might take from a few seconds to several hours.

Adding instance to the cluster...

Monitoring recovery process of the new cluster member. Press ^C to stop monitoring and let it continue in background.
Clone based state recovery is now in progress.

NOTE: A server restart is expected to happen as part of the clone process. If the
server does not support the RESTART command or does not come back after a
while, you may need to manually start it back.

* Waiting for clone to finish...
NOTE: 172.30.0.68:3308 is being cloned from 172.30.0.60:3306
** Stage DROP DATA: Completed
** Clone Transfer  
    FILE COPY  ############################################################  100%  Completed
    PAGE COPY  ############################################################  100%  Completed
    REDO COPY  ############################################################  100%  Completed
** Stage RECOVERY: \
NOTE: 172.30.0.68:3308 is shutting down...

* Waiting for server restart... ready
* 172.30.0.68:3308 has restarted, waiting for clone to finish...
* Clone process has finished: 68.01 MB transferred in about 1 second (~68.01 MB/s)

Incremental state recovery is now in progress.

* Waiting for distributed recovery to finish...
NOTE: '172.30.0.68:3308' is being recovered from '172.30.0.60:3306'
* Distributed recovery has finished

The instance '172.30.0.68:3308' was successfully added to the cluster.

 MySQL  172.30.0.60:3306 ssl  JS > cluster.addInstance('root@172.30.0.69:3309')

WARNING: A GTID set check of the MySQL instance at '172.30.0.69:3309' determined that it contains transactions that do not originate from the cluster, which must be discarded before it can join the cluster.

172.30.0.69:3309 has the following errant GTIDs that do not exist in the cluster:
99fe015f-691a-11ea-bc83-0242ac1e0045:1-9

WARNING: Discarding these extra GTID events can either be done manually or by completely overwriting the state of 172.30.0.69:3309 with a physical snapshot from an existing cluster member. To use this method by default, set the 'recoveryMethod' option to 'clone'.

Having extra GTID events is not expected, and it is recommended to investigate this further and ensure that the data can be removed prior to choosing the clone recovery method.

Please select a recovery method [C]lone/[A]bort (default Abort): C
NOTE: Group Replication will communicate with other members using '172.30.0.69:33091'. Use the localAddress option to override.

Validating instance configuration at 172.30.0.69:3309...

This instance reports its own address as 172.30.0.69:3309

Instance configuration is suitable.
A new instance will be added to the InnoDB cluster. Depending on the amount of
data on the cluster this might take from a few seconds to several hours.

Adding instance to the cluster...

Monitoring recovery process of the new cluster member. Press ^C to stop monitoring and let it continue in background.
Clone based state recovery is now in progress.

NOTE: A server restart is expected to happen as part of the clone process. If the
server does not support the RESTART command or does not come back after a
while, you may need to manually start it back.

* Waiting for clone to finish...
NOTE: 172.30.0.69:3309 is being cloned from 172.30.0.60:3306
** Stage DROP DATA: Completed
** Clone Transfer  
    FILE COPY  ############################################################  100%  Completed
    PAGE COPY  ############################################################  100%  Completed
    REDO COPY  ############################################################  100%  Completed
** Stage RECOVERY: \
NOTE: 172.30.0.69:3309 is shutting down...

* Waiting for server restart... ready
* 172.30.0.69:3309 has restarted, waiting for clone to finish...
* Clone process has finished: 68.01 MB transferred in about 1 second (~1.00 B/s)

Incremental state recovery is now in progress.

* Waiting for distributed recovery to finish...
NOTE: '172.30.0.69:3309' is being recovered from '172.30.0.60:3306'
* Distributed recovery has finished

The instance '172.30.0.69:3309' was successfully added to the cluster.

これで良い。 設定さえ問題なければ cluster.addInstance を実行するだけでノードは追加できる。

 MySQL  172.30.0.60:3306 ssl  JS > cluster.status();
{
    "clusterName": "singlePrimaryCluster", 
    "defaultReplicaSet": {
        "name": "default", 
        "primary": "172.30.0.60:3306", 
        "ssl": "REQUIRED", 
        "status": "OK", 
        "statusText": "Cluster is ONLINE and can tolerate up to ONE failure.", 
        "topology": {
            "172.30.0.60:3306": {
                "address": "172.30.0.60:3306", 
                "mode": "R/W", 
                "readReplicas": {}, 
                "replicationLag": null, 
                "role": "HA", 
                "status": "ONLINE", 
                "version": "8.0.19"
            }, 
            "172.30.0.68:3308": {
                "address": "172.30.0.68:3308", 
                "mode": "R/O", 
                "readReplicas": {}, 
                "replicationLag": null, 
                "role": "HA", 
                "status": "ONLINE", 
                "version": "8.0.19"
            }, 
            "172.30.0.69:3309": {
                "address": "172.30.0.69:3309", 
                "mode": "R/O", 
                "readReplicas": {}, 
                "replicationLag": null, 
                "role": "HA", 
                "status": "ONLINE", 
                "version": "8.0.19"
            }
        }, 
        "topologyMode": "Single-Primary"
    }, 
    "groupInformationSourceMember": "172.30.0.60:3306"
}

ステータスにも反映されていることが確認できる。

ここまで出来たら次は、このクラスターへのアクセスに MySQL Router を挟む。

オプションの類

MySQL Router に関する色々をやるまえに、 ここまでに必要だった設定達をまとめる。
セカンダリとプライマリはほとんど同じ設定を使っているため、プライマリの設定を挙げて書く。

skip-name-resolve=ON
bind_address="172.30.0.60"
report-host="172.30.0.60"
loose-group_replication_local_address="172.30.0.60:3316"
loose-group_replication_local_seeds="172.30.0.60:3316"
loose-group_replication_start_on_boot=OFF

*** ネットワーク周り

ホスト名を使用しないで IP アドレスを使う。
ただし、今回のように docker コンテナとして存在する MySQL に対してホストマシンの MySQL Shell から操作する場合、createCluster 時に何故か名前解決しようとして詰まった。
これは report-host で IP アドレスを指定することで解決した。

group_replication 関連

start_on_boot は、サーバ起動時に自動的にグループレプリケーションを開始するかどうかというあれ。構築時は OFF にする必要があるらしい。
local_address はグループレプリケーションが使用するアドレスとポートを明記する。アドレスは大体サーバと同じだがポートは MySQL サーバが使用しているものとは別のものにする必要がある。

MySQL Router

MySQL Router はいい感じの Docker コンテナがあったのでそれを使う。

lrf141@lrf141-ThinkPad-X220:~/infraProject/mysql-innodb-cluster-dc$ docker exec -it mysql-innodb-cluster-dc_router_1_8c5f6a8ebeca bash
bash-4.2# mysqlrouter --bootstrap root@master1 --user=root
Please enter MySQL password for root: 
# Bootstrapping system MySQL Router instance...

- Creating account(s) (only those that are needed, if any)
- Verifying account (using it to run SQL queries that would be run by Router)
- Storing account in keyring
- Adjusting permissions of generated files
- Creating configuration /etc/mysqlrouter/mysqlrouter.conf

Existing configuration backed up to '/etc/mysqlrouter/mysqlrouter.conf.bak'

# MySQL Router configured for the InnoDB Cluster 'singlePrimaryCluster'

After this MySQL Router has been started with the generated configuration

    $ /etc/init.d/mysqlrouter restart
or
    $ mysqlrouter -c /etc/mysqlrouter/mysqlrouter.conf

the cluster 'singlePrimaryCluster' can be reached by connecting to:

## MySQL Classic protocol

- Read/Write Connections: localhost:6446
- Read/Only Connections:  localhost:6447

## MySQL X protocol

- Read/Write Connections: localhost:64460
- Read/Only Connections:  localhost:64470

これが表示されるならオッケーなはず。
MySQL Router を通して InnoDB Cluster を利用するなら、ここでは localhost:6446,6447 に対してリクエストを投げる。

終わりに

一応できたけども、InnoDB Cluster が正常に起動した状態で docker-compose down でコンテナを落としてから再起動すると
スタンドアロンモードでプライマリが起動し、セカンダリが自動で接続されない現象が起こってしまったのでどうにかしたい。

Redis を Docker 環境でいい感じに使うためのメモ

はじめに

どうも、最近メイドインアビスが「ポップな絵柄で描かれたダークソウル」と聞いて見てみたら想像以上にダークソウルだったのではまりそうなけんつです。

結構、Redis をいい感じに docker-compose とかで使いたい時があるのでこの際にまとめてしまおうといったノリで書いていく。
絶対こういう設定を本番環境で使うべきではないと思う。あくまでも開発時に欲しい設定をまとめている。

前提として、ジョブワーカーの MQ に使う

環境

  • Redis 5.0.1
  • docker-compose version 1.23.0
  • docker 19.03.5

上での構築を前提としている。

データの永続化

Redis のデータ永続化には AOF と RDB というタイプが存在する。
AOF は fsync ポリシーを選択した上で使用される追記専用のログ。AOF で選択できる fsync ポリシーは以下の通り。

  • no: fsync を利用しない。OS が都度データをフラッシュする。
  • always: 追加に関するログが書き込まれる度に fsync を実行する
  • everysec: 毎秒無条件に fsync を実行する。

AOF が肥大化すると、Redis はバックグランドでリライトを行う。この時、新しいファイルにはその時点のデータ・セットを再現するために必要な最小限の手順を記録した情報が付与される。
この肥大化に関わる設定は auto-aof-rewrite-percentage, auto-aof-rewrite-min-size を設定することで定義出来る。

欠点としては、AOF は RDB*1 を利用して永続化するよりもファイルサイズが大きくなりやすい。
他には、fsync ポリシーによっては全体的な性能低下を招くことがある。反対に RDB では、書き込み負荷が高い場合でも最大レイテンシを保証することが出来る。そのため、AOF はパフォーマンスが要求されるような箇所に everysec で使われるべきではない。*2

普段 Redis を使うときはメッセージキューとして利用することが多く、キューのデータをロストすると困るため AOF でデータを永続化させている。
これがクエリのキャッシュだったりする場合は、そもそも永続化とかしなくてもよいかなと思う。

設定は以下の通り。

dir /data
appendonly yes
appendfsync everysec
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 8mb

dir でデータを保持するディレクトリを設定する。これは Redis の docker コンテナ*3を利用するとき、何故か /data がデフォルトで aof を吐く。
aof ファイルは 8mb*4を最小サイズとして aof ファイルサイズが倍増した段階でリライトするようになっている。これはキューを2つしか使わない場合が多いからこうなっている。

ログ

開発時に見たい情報が多々あるので、ログレベルも設定して置きたい。基本的には debug としている。
また、Redis では logfile "" がデフォルトとなっているためログは /dev/null に吐かれるらしい。*5
STDOUT にログが吐かれるので docker-compose 側で fluentd や syslog とかを使っても面白そうだけど今回はやっていない。

loglevel debug
logfile ""

メモリ周り

Redis は基本的にオンメモリ KVS のため、利用できる最大メモリ量や仮にメモリを確保できなくて書き込めない場合にどのような挙動をするか設定することができる。

メモリ解放ポリシーは以下の通り。

  • volatile-lru: 期限切れのものを LRU によって削除する
  • allkeys-lru: 全てのキーを対象に LRU に基づいて削除する
  • volatile-ramdom: 期限切れのキーをランダムに削除する
  • allkeys-random: 全てのキーをランダムに削除する
  • volatile-ttl: TTL を比較して小さい順に削除する
  • noeviction: 削除せずに書き込みエラーとして返す

ジョブワーカー用のキューを作ることがおおいので、どのようなポリシーであっても削除されるとジョブの情報が失われるので noeviction を設定する。

最大メモリ使用量は 100MB 程度としておく。あまり利用されてホストマシンに影響がでても困るので。

maxmemory 100mb
maxmemory-policy noeviction

おわりに

とりあえず開発用にいつも使いたい設定たちはこんな感じだろうか。
書いていてログ周りが docker 環境ではやや面倒くさいのでレプリケーションクラスタを組んだ時にでも fluentd か syslog を使っていい感じにするやつをまとめる

*1:リレーショナル・データベースのことではなく、Redis の永続化手法の一つ。

*2:と、思う。

*3:redis:latest で振ってくるもの

*4:Redis での 8mb は 1024 * 1024 * 8 byte。 8m だと 8 * 10^6 byte となる

*5:これ結構びっくりした

MySQL 8.0.18 の実装を読み解きながら簡単なストレージエンジンを自作する

はじめに

卒論書くのに飽きてきて何かやりたくなったので急にストレージエンジンを書くことにしてみた。
MySQL のストレージエンジンを実装していく中で、色々できるかなと思っていたけど、やってみると MySQL の内部実装について色々知らないといけないことが多くインデックスとかトランザクションとかそういうところは実装できなかった。

github.com

MySQL をビルドする

ストレージエンジンを開発するためにはまずソースコードをビルドする必要がある。

$ cd /tmp
$ wget  https://dev.mysql.com/get/Downloads/MySQL-8.0/mysql-boost-8.0.18.tar.gz
$ tar xzvf mysql-boost-8.0.18.tar.gz

ビルドに必要なパッケージを引っ張ってくる。

$ sudo apt-get install -y cmake libncurses5-dev libssl-dev build-essential

ビルドする。

$ cd mysql-8.0.18/
$ cmake . -DWITH_BOOST=./boost -DFORCE_INSOURCE_BUILD=1
$ make

ビルドまでしたら次は make install をするべきなのだけど、ストレージエンジンのプラグインは make すれば共有ライブラリ(.so) として吐かれるため
それを MySQL の docker コンテナ内に突っ込んで適用する。

ストレージエンジンを自作する

Example エンジンをベースにする

MySQLのストレージエンジンを自作してみる - 備忘録の裏のチラシ
↑この記事と

第84回 ストレージエンジンをビルドしてみる:MySQL道普請便り|gihyo.jp … 技術評論社
この記事を参考にしている。

まず storage ディレクトリ以下にストレージエンジンのコードがエンジン別のディレクトリに分かれているので作成する。
ここでは、example エンジンをベースにする。

$ cd mysql-8.0.18
// cp -R storage/example/ storage/gambit ここで自分は gambit という名前にしている
$ cp -R storage/example/ storage/{好きな名前}

ここまでやると storage/gambit が次の様な構成になっているはず。

mysql-8.0.18/storage/gambit$ ls
CMakeFiles      CTestTestfile.cmake  cmake_install.cmake  ha_example.h
CMakeLists.txt  Makefile             ha_example.cc

このあとが少し面倒で、コピーした example エンジンのコード内にある example, EXAMPLE を gambit, GAMBIT に修正する必要がある。

まず修正するのは Makefile
Makefile 内の example -> gambit に置換する。

次に CMakeList.txt をひらいて、 example -> gambit, EXAMPLE->GAMBIT に置換する。
それが終わったら ha_example.* を ha_gambit.* に置換して、そのコード内の Example, EXAMPLE, example を置換する。

ここまでおわったら MySQL のプロジェクトルートに cd して

$ cmake . -DWITH_BOOST=./boost -DFORCE_INSOURCE_BUILD=1
$ make

これで再度適用して、 show engines で該当するストレージエンジンがあれば問題ない。
ストレージエンジンのコードを修正した場合は、make すれば、 plugin_output_directory にビルドされる。

handlerton の作成とインスタンス

handlerton (handler singleton の略らしい)は、ストレージエンジンの定義と諸々の処理に対するメソッドポインタを持っている。
これを作成し、インスタンス化することで MySQL はストレージエンジンを使用することができる。
また、ストレージエンジンのハンドラを作成しているのは

handlerton *gambit_hton
static int gambit_init_func(void *p) {
  DBUG_TRACE;

  gambit_hton = (handlerton *)p;
  gambit_hton->state = SHOW_OPTION_YES;
  gambit_hton->create = gambit_create_handler;
  gambit_hton->flags = HTON_CAN_RECREATE;
  gambit_hton->is_supported_system_table = gambit_is_supported_system_table;

  return 0;
}

に含まれる gambit_hton->crate = gambit_create_handler が行う。

この gambit_create_handler は以下処理を行う。

static handler *gambit_create_handler(handlerton *hton, TABLE_SHARE *table,
                                       bool, MEM_ROOT *mem_root) {
  return new (mem_root) ha_gambit(hton, table);
}

またここで呼ばれる ha_gambit は以下の通り。

ha_gambit::ha_gambit(handlerton *hton, TABLE_SHARE *table_arg)
    : handler(hton, table_arg) {}

以下のドキュメントとは微妙にこのハンドラの特に定義部分が異なるが、メソッドポインタなどの登録は初期化関数内で行った方が良さそう。
また、これはどういうことなのかまだわかっていないがストレージエンジンのメタ情報は以下の mysql_declare_plugin で定義するようになっているみたい。*1

mysql_declare_plugin(gambit){
    MYSQL_STORAGE_ENGINE_PLUGIN,
    &gambit_storage_engine,
    "GAMBIT",
    "lrf141",
    "Gambit simple storage engine",
    PLUGIN_LICENSE_GPL,
    gambit_init_func, /* Plugin Init */
    NULL,              /* Plugin check uninstall */
    NULL,              /* Plugin Deinit */
    0x0001 /* 0.1 */,
    func_status,              /* status variables */
    gambit_system_variables, /* system variables */
    NULL,                     /* config options */
    0,                        /* flags */
} mysql_declare_plugin_end;

この mysql_declare_plugin の実体はマクロ。
mysql-server/plugin.h at 4869291f7ee258e136ef03f5a50135fe7329ffb9 · mysql/mysql-server · GitHub
mysql-server/plugin.h at 4869291f7ee258e136ef03f5a50135fe7329ffb9 · mysql/mysql-server · GitHub



ドキュメントは以下を参照している。
dev.mysql.com

テーブルを作成する

ここまでで、前提となるストレージエンジンの大まかな解説は終わりにして、早速実装していく。
まずはテーブルを作るところから。
基本的には ha_gambit.cc の ha_gambit::create メソッドを実装していく形になる。
公式ドキュメントは以下のページ。
MySQL :: MySQL Internals Manual :: 23.8 Creating Tables

この関数はテーブルを作る際に呼ばれるとなっていて、基本的には my_create を呼び出すことでファイルを作成するようになっている。
ただ、その前にドキュメントには記載されていない create メソッドにあるこの存在。
まずはこれが何か読み解く。

int ha_gambit::create(const char *name. TABLE *, HA_CREATE_INFO *. dd::Table) {
...

  /*
    It's just an gambit of THDVAR_SET() usage below.
  */
  THD *thd = ha_thd();
  char *buf = (char *)my_malloc(PSI_NOT_INSTRUMENTED, SHOW_VAR_FUNC_BUFF_SIZE,
                                MYF(MY_FAE));
  snprintf(buf, SHOW_VAR_FUNC_BUFF_SIZE, "Last creation '%s'", name);
  THDVAR_SET(thd, last_create_thdvar, buf);
  my_free(buf);

  uint count = THDVAR(thd, create_count_thdvar) + 1;
  THDVAR_SET(thd, create_count_thdvar, &count);

  return 0;
}

MySQL: THD Class Reference
THD はクライアントの接続毎に、Thread/Connction ディスクリプタとして動作する個別のスレッドを作成するクラス。
このクラスがもつメソッド達をみても間違いないはず。

一度スレッドを取得したあとは、メモリを確保してバッファにログ(?)を書き込む。
そのあとはスレッドローカルの値を buf に更新する。
そして、スレッド数を1加算してからスレッドローカルに同様に保存している。

このスレッドに何の意味があるかわからなかったので InnoDB の ha_innobase::create を読んでみると trx とあったのでおそらくトランザクションを実装するときに使うのだろうと思った。ここはトランザクション関連をやるまでわからない。
それか、PSI とあるので性能計測系のスレッドかもしれない。
mysql-server/ha_innodb.cc at 91a17cedb1ee880fe7915fb14cfd74c04e8d6588 · mysql/mysql-server · GitHub

その前にいくつか前提を抑えておく。
この create メソッドでは基本的に my_craate 関数を使ってデータを保存するファイルを作るっぽいが、my_create が何を引数にして何を返すかがドキュメントにはないので以下の MySQL のコードとコードドキュメントを読む。
mysql-server/my_create.cc at 91a17cedb1ee880fe7915fb14cfd74c04e8d6588 · mysql/mysql-server · GitHub
MySQL: Mysys - low level utilities for MySQL

my_create の引数は FileName, CreateFlags, access_Flag, MyFlags とある。
FileName はそのままだが、問題は CreateFlags と access_Flag、 MyFlags。
CreateFlags は O_CREAT と OR が計算されるようになっている。これは open システムコールを呼ぶときにファイルが存在しない場合はそのファイルを作成することが前提となるため。なのでここでは、open システムコールに渡すのと同じものを渡せば確実にそれと同一の挙動を取る。
access_flag は O_CREAT が前提になっているため、どのような権限をそのファイルに付与するかどうかを決定付ける。

問題は MyFlags。
ここで special flag と書かれた myf という型は int のエイリアスとなっている。
MySQL: include/my_inttypes.h File Reference
で、結局これが何者なのかというとさっきの my_create のコードを見てみると明らかにエラーの場合に呼ばれている。
なにやらしらべてみると my_funcs に紐付いた値らしくなんらかの関数を呼ぶのに使用されているみたい。よくわからない。


この my_create では該当ファイルを開いたあと、ディレクトリ情報を同期する。*2
そのあと、ファイル情報を内部的に保持する。
また、ファイルを開く段階で該当ファイルが存在しない場合は作成されるようになっている。
mysql-server/my_create.cc at 91a17cedb1ee880fe7915fb14cfd74c04e8d6588 · mysql/mysql-server · GitHub

ここまで読んで気がついたけど、おそらく my_create は open システムコールのラッパーになっているっぽい。

これで実装していく。

int ha_gambit::create(const char *name, TABLE *, HA_CREATE_INFO *,
                       dd::Table *) {
  DBUG_TRACE;
  File create_file;
  DBUG_ENTER("ha_gambit::create");
  if ((create_file=my_create(name, 0, O_RDWR | O_TRUNC, MYF(0))) < 0)
      DBUG_RETURN(-1);
  if ((my_close(create_file, MYF(0))) < 0)
      DBUG_RETURN(-1);

  /*
    It's just an gambit of THDVAR_SET() usage below.
  */
  THD *thd = ha_thd();
  char *buf = (char *)my_malloc(PSI_NOT_INSTRUMENTED, SHOW_VAR_FUNC_BUFF_SIZE,
                                MYF(MY_FAE));
  snprintf(buf, SHOW_VAR_FUNC_BUFF_SIZE, "Last creation '%s'", name);
  THDVAR_SET(thd, last_create_thdvar, buf);
  my_free(buf);

  uint count = THDVAR(thd, create_count_thdvar) + 1;
  THDVAR_SET(thd, create_count_thdvar, &count);

  return 0;
}

全体としてはこんな感じ。
TABLE, HA_CREATE_INFO. dd::Table は今回使用してない。dd::Table に至っては Internal Manual には記載されていないのでまたコードを追う必要がある。
TABLE は frm に吐かれる情報をもっているとあるのでおそらく sdi に統合されている。 HA_CREATE_INFO もテーブルのメタデータを持っているが今回はとくにそれらをいじったりしないので使っていない。


ここまでやって、make, ストレージエンジンの適用をやったら試してみる。

mysql [sample]> create table test_table(id int, name varchar(255)) engine=gambit;
Query OK, 0 rows affected (0.19 sec)

テーブルをストレージエンジンを指定した状態で作成する。
そうして /var/lib/mysql 以下の sample という DB のディレクトリ以下に次のファイルが存在した。

$ ls
test_table  test_table_339.sdi

できたっぽい。
この sdi ファイルというのは ver 8.0.3 で追加されたものらしく、 serialized dictionary information というもの。
中身は json 形式になっていて、 従来の frm などメタデータを保持していたものの代替となっている。
これは一時的なテーブルスペースと UNDO テーブルスペースを除く全てのテーブルスペースに存在する。
MySQL :: MySQL 8.0 Release Notes :: Changes in MySQL 8.0.3 (2017-09-21, Release Candidate)

余談・気になったところ

これ CREATE TABLE 文使ったら即時、ファイルが生成されたけどチェックポイントとか関係なく動作しているのかどうなのか。

テーブルを開く

テーブルを作成することはできたが問題は、その次に待っているテーブルをオープンするところ。
これはドキュメントがめちゃくちゃ薄い。もっというなら、テーブルを開くことなのにファイルロックを調べてねとしか書いていない。
おそらくそれ以外は本当に特に決まっていなくて、ファイルロックさえ考慮すればどう実装してもいいと思われる。

それではまず、ここでやるべき事を考えていく。
テーブルを SELECT, INSERT などの時に開く処理を ha_gambit::open に実装するのがここでの一番大きな目標。

そのメソッドは次のように宣言されている。

int ha_gambit::open(const char *, int, uint, const dd::Table *)

MySQL Internal のドキュメントとは異なるが、 int はおそらく mode で O_RDONLY, O_RDWR を渡すことを想定していて、 uint はテーブルを開く前にロックをどのようにチェックするかが渡されるはず。

#define HA_OPEN_ABORT_IF_LOCKED   0   /* default */
 #define HA_OPEN_WAIT_IF_LOCKED    1
 #define HA_OPEN_IGNORE_IF_LOCKED  2
 #define HA_OPEN_TMP_TABLE         4   /* Table is a temp table */
 #define HA_OPEN_DELAY_KEY_WRITE   8   /* Don't update index */
 #define HA_OPEN_ABORT_IF_CRASHED  16
 #define HA_OPEN_FOR_REPAIR        32  /* open even if crashed */

MySQL :: MySQL Internals Manual :: 23.9 Opening a Table

そして、EXAMPLE エンジンをベースにしているため、以下の実装が追加されている。

int ha_gambit::open(const char *, int, uint, const dd::Table *) {
  DBUG_TRACE;

  if (!(share = get_share())) return 1;
  thr_lock_data_init(&share->lock, &lock, NULL);

  return 0;
}

get_share を使って、share lock info を取得している。これは get_share() と ha_gambit.h のメンバを見ればわかる。

share という Gambit_share 型のメンバはヘッダーファイルで宣言されていて、 get_share の振る舞いは ha_gambit.cc に存在する。

Gambit_share *ha_gambit::get_share() {
  Gambit_share *tmp_share;

  DBUG_TRACE;

  lock_shared_ha_data();
  if (!(tmp_share = static_cast<Gambit_share *>(get_ha_share_ptr()))) {
    tmp_share = new Gambit_share;
    if (!tmp_share) goto err;

    set_ha_share_ptr(static_cast<Handler_share *>(tmp_share));
  }
err:
  unlock_shared_ha_data();
  return tmp_share;
}

get_share ではまず get_ha_share_ptr で ha_share ポインタを初期化、取得している。
MySQL: handler Class Reference

この ha_share が何者なのかというと Handler_share ポインタを格納・取得するポインタみたい。
そのポインタを取得して Gambit_share 型としてキャストしている。この Gambit_share 型は ha_gambit.h で定義されている。

/** @brief
  Gambit_share is a class that will be shared among all open handlers.
  This gambit implements the minimum of what you will probably need.
*/
class Gambit_share : public Handler_share {
 public:
  THR_LOCK lock;
  Gambit_share();
  ~Gambit_share() { thr_lock_delete(&lock); }
};

でも結局この share とは何なのかという肝心なところがドキュメント*3に書いてない。
なので、ちょっと戻って MySQL Internal Manual の Overview を読んでみる。
MySQL :: MySQL Internals Manual :: 23.2 Overview

The MySQL server is built in a modular fashion:

The storage engines manage data storage and index management for MySQL. The MySQL server communicates with the storage engines through a defined API.

Each storage engine is a class with each instance of the class communicating with the MySQL server through a special handler interface.

Handlers are instanced on the basis of one handler for each thread that needs to work with a specific table. For example: If three connections all start working with the same table, three handler instances will need to be created.

Once a handler instance is created, the MySQL server issues commands to the handler to perform data storage and retrieval tasks such as opening a table, manipulating rows, and managing indexes.

Custom storage engines can be built in a progressive manner: Developers can start with a read-only storage engine and later add support for INSERT, UPDATE, and DELETE operations, and even later add support for indexing, transactions, and other advanced operations.

意訳)
MySQL はモジュールベースで構築されている。

...(中略)...

各ストレージエンジンはクラスであって、そのクラスは handler インターフェースを介してサーバと通信する。
ハンドラーは特定のテーブルを操作する必要があるスレッド毎に1つのハンドラーインスタンスを生成する。例:3つの接続が全て同じテーブルで動作する場合は 3 つのハンドラインスタンスが生成される。

...(中略)...

つまり各コネクション毎にハンドラインスタンスを生成し、それらのハンドラ間ではこの share を共有しているということだった。
また、 ha_share はパーティション化されていないハンドラ*4の場合は TABLE_SHARE::ha_share が呼ばれるらしくその情報を見ると合点がいった。

TABLE_SHARE というものは、テーブル毎に生成され前述の通りテーブル間で共有されるインスタンスでテーブルのメタデータを持っている。
そのため、テーブルファイルの読み込みにはこの share を取得するべきだったらしい。
ここでようやく get_share の話に戻ってくる。 get_share では、この share を取得し、存在する場合はそれを返し存在しない場合は新たに share を生成し該当するポインタに代入して返している。

次に、また話は戻り get_share の後に何が起こるか。
その次は以下の処理が行われる。

thr_lock_data_init(&share->lock, &lock, NULL);

この thr_lock_data_init のドキュメントは以下のリンクにある。
MySQL: include/thr_lock.h File Reference

そもそも、この thr_lock_data_init は thr_lock.h|.cc に実装されているものなのだが、この thr_lock では Posix thread *5を扱う場合の R/W ロックを提供するものが実装されている。thr_lock_data_init はその機能の一部。

MySQL の thr_lock では 2 種類のロックを持つ。
マスターロック(THR_LOCK)とロックインスタンス(THR_LOCK_DATA)があり、任意のスレッドは任意の数だけロックインスタンスを持つことができる。また当然の如く使い終わったら、解放する必要がある。

ここまで来るとなにをやっていたかが分かってきて、 ha_gambit::open メソッドではそれが呼ばれる度に THR_LOCK_DATA インスタンスを生成する処理がなされるということになる。

既存の実装は理解したので、ようやくファイルを開く処理を書く。
まず、ロックなどなどは置いといてまずファイルディスクリプタをどこかで保持する必要がある。ファイルを開いてファイルディスクリプタを取るには my_open を使用する。おそらく my_open もシステムコールの open のラッパーだと思う。
実装は以下の通り。

int ha_gambit::open(const char *name, int, uint, const dd::Table *) {
  DBUG_TRACE;

  File open_file;

  if (!(share = get_share())) return 1;
  thr_lock_data_init(&share->lock, &lock, NULL);
  
  if (!(open_file = my_open(name, O_RDWR, MYF(0))))
      return 1;
  share->table_file = open_file;
  return 0;
}
class Gambit_share : public Handler_share {
 public:
  THR_LOCK lock;
  File table_file;
  Gambit_share();
  ~Gambit_share() { thr_lock_delete(&lock); }
};

テーブル毎に share がひとつ存在するので、ファイルディスクリプタを share で持つようにしている。
スレッドのロックを扱うには thr_multi_lock を使う必要があるのだが、ここではまだ使っていない。

INSERT の実装

ここで本来は SELECT がドキュメントの順番では来るが SELECT するためのデータが無いので先に INSERT を実装する。

INSERTを実装するには ha_gambit::write_row を実装する。
ただここは、本当に実装の例が無いので以下の2つの記事を参考にする。

MySQL - 自作ストレージエンジンで初音ミクさんに歌っていただきましょう - こんぶのつけもの
MySQLのストレージエンジンを自作してみる - 備忘録の裏のチラシ

今回はまず先に実装を載せる。そのあとでなぜそれがそのようなコードになったか書いていく。
というのも、ドキュメントからでは何をしたらよいのかわからなかったため。

まずha_gambit.h に以下のを追加した。

#include "sql_string.h"

class Gambit_share : public Handler_share {
  ...
  const char *name
  File write_file;
  ...
};

class ha_gambit : public handler {
...
  String buffer;
public:
...

まず、share にテーブル名を保持するメンバと書き込み用のディスクリプタを保持するメンバを追加した。
読み込み用のディスクリプタと同じにしてしまうと、ひとつのディスクリプタを R/W で共有することになってしまうのであまりやりたくない。

次に行を格納するためのバッファを handler に追加している。この型は string でなく String *6である。
このクラスは Java で言うところの String, StringBuffer がいい感じに合体したクラスに近い。
MySQL: String Class Reference

次に問題の ha_gambit.cc の実装。

int ha_gambit::write_row(uchar *) {
  ha_statistic_increment(&System_status_var::ha_write_count);

  share->write_file = my_open(share->name, O_RDWR | O_APPEND, MYF(0));

  char att_buf[1024];
  String attribute(att_buf, sizeof(att_buf), &my_charset_bin);
  my_bitmap_map *org_bitmap = tmp_use_all_columns(table, table->read_set);
  buffer.length(0);

  for (Field **field = table->field; *field; field++) {
    const char *p;
    const char *end;
    (*field)->val_str(&attribute, &attribute);
    p = attribute.ptr();
    end = attribute.length() + p;
    buffer.append('"');
    for (; p < end; p++)
        buffer.append(*p);
    buffer.append('"');
    buffer.append(',');
  }
  buffer.length(buffer.length() - 1);
  buffer.append('\n');
  tmp_restore_column_map(table->read_set, org_bitmap);
  int size = buffer.length();
  my_write(share->write_file, (uchar *)buffer.ptr(), size, MYF(0));
  return 0;
}

ha_statistic_increment とは、table が保持する THR 構造体のステータスを加算するもので今回は ha_write_count がインクリメントされている。
これはテーブルのステータス系表示に使われる。ので、最悪なくてもよさ気?
my_bitmap_map の tmp_use_all_columns は読み取りフラグを立てているがそのフラグが一体どこで利用されているかはわからない。

その次は、前述の書き込み用のファイルディスクリプタを取得するやつ。
attribute はこんな書き方があるのかと驚いている、これは C++ 独自の書き方なのかわからないがやっていることは char 型の配列を sql_string.h の String に直してかえしてくれるやつぐらいのイメージしかないが全くわからない。

そのあとはドキュメントに書いてあるように、 Field をループして、 String として値を取得したら 1 文字ずつ取り出して buffer に append している。
これをあとは最初に取得したファイルディスクリプタに登録するだけ。

ha_tina の存在

ha_tina という CSV ストレージエンジンが MySQL のコードにあるがこれを参考にして作られているものが多いのでこれをみるべきだったかもしれない。

テーブルスキャン

いよいよラスト、だがこれが一番面倒。
実装する関数が以下のように複数ある。

  • store_lock
  • external_lock
  • rnd_init
  • info
  • extra
  • rnd_next

実際に CSV ストレージエンジンで 9 行スキャンする場合はこう呼び出される。

ha_tina::store_lock
ha_tina::external_lock
ha_tina::info
ha_tina::rnd_init
ha_tina::extra - ENUM HA_EXTRA_CACHE   Cache record in HA_rrnd()
ha_tina::rnd_next
ha_tina::rnd_next
ha_tina::rnd_next
ha_tina::rnd_next
ha_tina::rnd_next
ha_tina::rnd_next
ha_tina::rnd_next
ha_tina::rnd_next
ha_tina::rnd_next
ha_tina::extra - ENUM HA_EXTRA_NO_CACHE   End caching of records (def)
ha_tina::external_lock
ha_tina::extra - ENUM HA_EXTRA_RESET   Reset database to after open

store_lock の実装

MySQL :: MySQL Internals Manual :: 23.10.1 Implementing the store_lock() Method
このメソッドは R/W の実行前に呼ばれる。行レベルロックやテーブルレベルロックなど内部ロックに関する実装をする。

ロックは今回実装しないので EXAMPLE からいじらない。

THR_LOCK_DATA **ha_gambit::store_lock(THD *, THR_LOCK_DATA **to,
                                       enum thr_lock_type lock_type) {
  if (lock_type != TL_IGNORE && lock.type == TL_UNLOCK) lock.type = lock_type;
  *to++ = &lock;
  return to;
}

やってることは、ハンドラのもつロックインスタンスがアンロック状態で ignore しないなら SELECT 時に共有ロック、 INSERT 系の場合は排他ロックをセットする。

external_lock の実装

これは外部ロックに関する実装。具体的にはデータファイルに対するファイルロックを実装する。
これも今回は実装しないのでそのまま。

int ha_gambit::external_lock(THD *, int) {
  DBUG_TRACE;
  return 0;
}

rnd_init の実装

テーブルスキャンでしようする変数などを初期化するメソッド。
stats.record とポジションに関する情報を初期化しておく。

class ha_gambit : public handler {
...
  off_t current_position;
...
int ha_gambit::rnd_init(bool) {
  current_position = 0;
  stats.records = 0;
  return 0;
}

info の実装

これは先に実装を載せる。

int ha_gambit::info(uint) {
  if (stats.records < 2)
    stats.records= 2;
  return 0;
}

レコード数が 2 未満の場合にオプティマイザの処理が変わるらしく、この場合はレコードが読み込まれない可能性があるため if 文を追加しないといけない。
これはソースコードのコメントの注意書きにあった。

extra の実装

これはストレージエンジンに対してヒントを送るための関数らしいので return 0 のみの状態で今回は放置する。

rnd_next の実装

これがファイルからレコードを読み込むメソッドとなる。書き込みの時とほぼ同じ処理をする。

int ha_gambit::rnd_next(uchar *buf) {
  DBUG_TRACE;
  int err;

  ha_statistic_increment(&System_status_var::ha_read_rnd_next_count);
  err = find_current_row(buf);
  if (!err) 
      stats.records++;
  return err;
}

int ha_gambit::find_current_row(uchar *buf) {
  DBUG_TRACE;

  my_bitmap_map *org_bitmap = tmp_use_all_columns(table, table->write_set);
  uchar read_buf[IO_SIZE];
  bool is_end;
  uchar *p;
  uchar current_char;
  uint bytes_read;

  memset(buf, 0, table->s->null_bytes);
  for (Field **field = table->field; *field; field++) {
    bytes_read = my_pread(share->table_file, read_buf, sizeof(read_buf), current_position, MYF(0));
    if (!bytes_read) {
      tmp_restore_column_map(table->write_set, org_bitmap);
      return HA_ERR_END_OF_FILE;
    }
    p = read_buf;
    current_char = *p;
    buffer.length(0);
    is_end = false;

    for (;;) {
      if (current_char == '"') {
        if (is_end) {
          current_position += 2;
          break;
        }
        is_end = true;
      } else {
        buffer.append(current_char);
      }
      current_char = *++p;
      current_position++;
    }
    (*field)->store(buffer.ptr(), buffer.length(), buffer.charset());
  }
  tmp_restore_column_map(table->write_set, org_bitmap);
  return 0; 
}

memset は今回は null を許容していないため、 先頭にあるカラム分の NULL ビットマップを 0 で埋めている。
この書き込み時の話は度々参考にしている以下のブログによくまとまっている。
MySQLのストレージエンジンを自作してみる - 備忘録の裏のチラシ

おわりに

INSERT, SELECT に関することは調べることが多すぎてめちゃくちゃ駆け足になってしまったのでまたこの手のブログを書くときに実装を追っていきたい。
次、やるときはそのあたりと index or トランザクション周りでもやろうかな
あと、C++ 今回はじめて書いたけどわからない文法が多すぎるからそっちもやらねば。

卒論執筆のいい気分転換になった

*1:ストレージエンジンに限らず、プラグインはこのような定義をソースコード末尾に持っている。

*2:Linux でのみこの動作が発生する

*3:ここで指すドキュメントとは MySQL 8.0.18 の Source Code DOcumentation のこと

*4:何を言っているかわからないがおそらくやっていない

*5:POSIX Thread はスレッドの POSIX 標準。スレッドの生成や操作などの API を定義している。

*6:sql_string.h の String クラス

MySQL のレプリケーション実装

はじめに

どうも、年明けおもしろ荘を見ながらブログを書いているけんつです。
前にMySQL 8 と docker-compose を使ってレプリケーションを構築する記事を書いたのだけど、そこではただバイナリログのポジションベースのレプリケーションを構築しただけだったので
この記事でその実装と仕組みを追っていく。

前のレプリケーション構築記事
GTID ベースのレプリケーションには触れていない。
rabbitfoot141.hatenablog.com

レプリケーション実装

レプリケーションはマスターが DB の全ての更新や削除といった変更をバイナリログベースで追跡することがベースとなっている。
このバイナリログはサーバが起動した瞬間からデータ変更以外にもデータベースの構造が変わるなどのイベントを全て記録する。また変更が伴わない SELECT 等はバイナリログ上で追跡されない。

MySQLレプリケーションは、マスタに変更があった場合にスレーブにデータをプッシュするのではなく、マスターからデータをプルするという表現が近い。
また実際に送信されるデータはバイナリログであり、スレーブはこのバイナリログのイベントを再現することで、マスターと同様のデータを再現する。

また各スレーブは独立しているため、スレーブはデータベースのコピーを独自のペースで読み取り、更新できレプリケーションプロセスを他のレプリケーションプロセスに影響を与えることなく開始、停止することが可能となっている。

実装の詳細

MySQLレプリケーションはマスタサーバに1つ、スレーブサーバに2つのスレッドを使用することで実装されている。

サーバ側

  • Binlog dump thread: マスターがスレーブに接続するときにバイナリログの内容をスレーブに送信するスレッドを作る。これがそれ。マスター側で SHOW PROCESSLIST で binlog dumo thread を確認できる。このスレッドはスレーブに送信される各イベントの読み取りの

スレーブ側

  • Slave I/O Thread: START SLAVE がスレーブ側で実行され、マスターに接続した段階でバイナリログの更新記録の送信を要求する I/O スレッドを要求する。このスレッドは Binlog dump Thread が送信するバイナリログの各イベントを読み取るためにマスターのバイナリログでロックを取る。*1
  • Slave SQL Thread: スレーブは Slave I/O Thread によって書き込まれたリレーログを読み取るこのスレッドを作成し、そこに含まれるイベントを実行する。

スレーブは2つのスレッドを使用して、マスターからの更新を読み取ることと、それらを実行することを独立タスクに分類する。
そのため、ステートメント実行が遅い場合でもステートメントを読み取るタスクが遅くなることはない。

SQL スレッドがかなり遅れている場合でも、全てのバイナリログを起動時にフェッチ出来る。またSQL スレッドがフェッチ済みのステートメントの実行を完了する前にスレーブが停止した場合でも安全なコピーがリレーログとしてスレーブローカルに保存されているため次の起動時に実行を開始することができる。これによってバイナリログは送ってさえしまえばマスターで長時間保持する必要がない。

おわりに

MySQL 8 のドキュメント翻訳みたいになってきた。

*1:イベントがスレーブに送信される前でも