なんかコンパイラ作ってみたくなってしまった

部分的にで良いので、コンパイラを作って見ようと思っている。

忘年会で久しぶりに会った大学の同期が業務でコンパイラの最適化をやり始めたらしく、一緒になにか作ってみようということになった。 どれくらいやるかわからないけど、CコンパイラをC++で書くと言語とコンパイラの仕組み両方の勉強になって良さそうとか思っている。

ドラゴンブックを引っ張り出してきたけど読み直すには長いのでどうするか考え中。。。
Ruiさんのコンパイラ本(低レイヤを知りたい人のためのCコンパイラ作成入門)の現時点のものを読みつつ手を動かしてみた。

github.com

一回途絶えたらすっかり週間がなくなっていた

完全に書くのを忘れていた。

書いていく。 - performance_schemaのinstrumentsを分類ごとに有効化無効化した場合の調査 - query_rewriteプラグイン使ってみる

などしていた。 それぞれ本ブログに書くのでそっちで。

詳解MySQL5.7, 3章読んだ

当然今日1時間の分ではないが、3章optimizerを読み終えた。

一通り読んだだけで、optimizer_traceの実験や3.5.4 サブクエリの実行計画の改善あたりはもう少し手を動かして見る必要がある。

optimizer_traceも実行計画が狂う件一通り追ったことはあるけど、結構忘れているし、8.0での改善も気になるので比較してみたい。 サブクエリ周辺は5.5 -> 5.6 -> 5.7あたりで順々に変わっていくところを追えば1つちゃんとしたブログがかけそう。

テンポラリテーブルが5.7でようやくInnoDBになったのよいけど、これどれくらい高速化したのか気になる、どういうときにbuffer_poolに乗り切るのかもよくわかっていないので、なかなか予想が厳しい。

テンポラリテーブル、ソートバッファの使い方は別途調べて見る必要がありそう。

MySQLのプロトコル紹介の資料作り

作った。 結構怪しいところがあるけど、社内で発表の機会があるので、いずれどこかで。 まだステートもって処理できてないし、年内には終わらせないといい加減時間かけすぎてる。。。

プロジェクトは並行させずに短期間でどこまで完成度上げられるかが勝負だとまた思い知らされている、、、

詳解MySQL5.7 p48まで

疑問

repli_semi_syncの開始にmasterの再起動が必要ではないか？ (p40あたり)

dynamicに変更可能 https://dev.mysql.com/doc/refman/5.6/ja/server-system-variables.html#sysvar_rpl_semi_sync_master_enabled

innodb_support_xa

https://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html#sysvar_innodb_support_xa

メモ - 準同期レプリケーションでのmasterの永続化はbinlogのfsync完了できまる 1. binlogにwrite 1. binlogをfsync <- ここが完了すればリカバリされる 1. ストレージエンジン(innodb)にcommit

config

• sync_binlog = 1
• innodb_support_xa = 1
• rpl_semi_sync_master_wait_point
  • AFTER_COMMIT (< 5.6)
  • AFTER_SYNC (> 5.7)
• rpl_semi_sync_master_wait_for_slave_count
• rpl_semi_sync_master_wait_no_slave
• master_info_repository = TABLE
• クラッシュセーフスレーブの条件
  • relay_log_info_repository = TABLE
  • relay_log_recovery = ON
  • relay_log_purge = ON
• 5.6以降から?binlog_order_commits = ON (default)を買えるべきでない

詳解MySQL5.7 読書メモ

2. レプリケーション

調査

master thread確認

コードから？

mysqldumpの--master-data=2及び他のオプションについて

https://dev.mysql.com/doc/refman/5.6/ja/mysqldump.html#option_mysqldump_master-data

• default: 1
• 1: change master to ...ステートメントが追記され, インポートと同時にmasterへのchange master to が実行される
• 2: change master to ...ステートメントがコメントとして追記される
• このオプションは自動的に --lock-tables をオフにする
• さらに--single-transaction も指定されていない場合は、--lock-all-tables をオンにする(ダンプの最初のわずかな時間のみグローバル読み取りロックが取得される)

--single-transaction - データのダンプ前に、トランザクション分離モードを REPEATABLE READ に設定し、START TRANSACTION SQL ステートメントをサーバーに送信 - アプリケーションをブロックすることなく、START TRANSACTION が発行された時点のデータベースの一貫した状態をダンプできる

show slave statusと同等のpeformance_schemaテーブル

replication_applier_configuration

show create table replication_applier_configuration\G 1. row Table: replication_applier_configuration Create Table: CREATE TABLE replication_applier_configuration ( CHANNEL_NAME char(64) NOT NULL, DESIRED_DELAY int(11) NOT NULL ) ENGINE=PERFORMANCE_SCHEMA DEFAULT CHARSET=utf8

replication_applier_status

show create table replication_applier_status\G 1. row Table: replication_applier_status Create Table: CREATE TABLE replication_applier_status ( CHANNEL_NAME char(64) NOT NULL, SERVICE_STATE enum('ON','OFF') NOT NULL, REMAINING_DELAY int(10) unsigned DEFAULT NULL, COUNT_TRANSACTIONS_RETRIES bigint(20) unsigned NOT NULL ) ENGINE=PERFORMANCE_SCHEMA DEFAULT CHARSET=utf8

replication_applier_status_by_coordinator

show create table replication_applier_status_by_coordinator\G 1. row Table: replication_applier_status_by_coordinator Create Table: CREATE TABLE replication_applier_status_by_coordinator ( CHANNEL_NAME char(64) NOT NULL, THREAD_ID bigint(20) unsigned DEFAULT NULL, SERVICE_STATE enum('ON','OFF') NOT NULL, LAST_ERROR_NUMBER int(11) NOT NULL, LAST_ERROR_MESSAGE varchar(1024) NOT NULL, LAST_ERROR_TIMESTAMP timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINE=PERFORMANCE_SCHEMA DEFAULT CHARSET=utf8

replication_applier_status_by_worker

show create table replication_applier_status_by_worker\G 1. row Table: replication_applier_status_by_worker Create Table: CREATE TABLE replication_applier_status_by_worker ( CHANNEL_NAME char(64) NOT NULL, WORKER_ID bigint(20) unsigned NOT NULL, THREAD_ID bigint(20) unsigned DEFAULT NULL, SERVICE_STATE enum('ON','OFF') NOT NULL, LAST_SEEN_TRANSACTION char(57) NOT NULL, LAST_ERROR_NUMBER int(11) NOT NULL, LAST_ERROR_MESSAGE varchar(1024) NOT NULL, LAST_ERROR_TIMESTAMP timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINE=PERFORMANCE_SCHEMA DEFAULT CHARSET=utf8

replication_connection_configuration

show create table replication_connection_configuration\G 1. row Table: replication_connection_configuration Create Table: CREATE TABLE replication_connection_configuration ( CHANNEL_NAME char(64) NOT NULL, HOST char(60) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL, PORT int(11) NOT NULL, USER char(32) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL, NETWORK_INTERFACE char(60) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL, AUTO_POSITION enum('1','0') NOT NULL, SSL_ALLOWED enum('YES','NO','IGNORED') NOT NULL, SSL_CA_FILE varchar(512) NOT NULL, SSL_CA_PATH varchar(512) NOT NULL, SSL_CERTIFICATE varchar(512) NOT NULL, SSL_CIPHER varchar(512) NOT NULL, SSL_KEY varchar(512) NOT NULL, SSL_VERIFY_SERVER_CERTIFICATE enum('YES','NO') NOT NULL, SSL_CRL_FILE varchar(255) NOT NULL, SSL_CRL_PATH varchar(255) NOT NULL, CONNECTION_RETRY_INTERVAL int(11) NOT NULL, CONNECTION_RETRY_COUNT bigint(20) unsigned NOT NULL, HEARTBEAT_INTERVAL double(10,3) unsigned NOT NULL COMMENT 'Number of seconds after which a heartbeat will be sent .', TLS_VERSION varchar(255) NOT NULL ) ENGINE=PERFORMANCE_SCHEMA DEFAULT CHARSET=utf8

replication_connection_status

show create table replication_connection_status\G 1. row Table: replication_connection_status Create Table: CREATE TABLE replication_connection_status ( CHANNEL_NAME char(64) NOT NULL, GROUP_NAME char(36) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL, SOURCE_UUID char(36) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL, THREAD_ID bigint(20) unsigned DEFAULT NULL, SERVICE_STATE enum('ON','OFF','CONNECTING') NOT NULL, COUNT_RECEIVED_HEARTBEATS bigint(20) unsigned NOT NULL DEFAULT '0', LAST_HEARTBEAT_TIMESTAMP timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 'Shows when the most recent heartbeat signal was received.', RECEIVED_TRANSACTION_SET longtext NOT NULL, LAST_ERROR_NUMBER int(11) NOT NULL, LAST_ERROR_MESSAGE varchar(1024) NOT NULL, LAST_ERROR_TIMESTAMP timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' ) ENGINE=PERFORMANCE_SCHEMA DEFAULT CHARSET=utf8

replication_group_member_stats

show create table replication_group_member_stats\G 1. row Table: replication_group_member_stats Create Table: CREATE TABLE replication_group_member_stats ( CHANNEL_NAME char(64) NOT NULL, VIEW_ID char(60) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL, MEMBER_ID char(36) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL, COUNT_TRANSACTIONS_IN_QUEUE bigint(20) unsigned NOT NULL, COUNT_TRANSACTIONS_CHECKED bigint(20) unsigned NOT NULL, COUNT_CONFLICTS_DETECTED bigint(20) unsigned NOT NULL, COUNT_TRANSACTIONS_ROWS_VALIDATING bigint(20) unsigned NOT NULL, TRANSACTIONS_COMMITTED_ALL_MEMBERS longtext NOT NULL, LAST_CONFLICT_FREE_TRANSACTION text NOT NULL ) ENGINE=PERFORMANCE_SCHEMA DEFAULT CHARSET=utf8

replication_group_members

show create table replication_group_members\G 1. row Table: replication_group_members Create Table: CREATE TABLE replication_group_members ( CHANNEL_NAME char(64) NOT NULL, MEMBER_ID char(36) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL, MEMBER_HOST char(60) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL, MEMBER_PORT int(11) DEFAULT NULL, MEMBER_STATE char(64) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL ) ENGINE=PERFORMANCE_SCHEMA DEFAULT CHARSET=utf8

GTID

• GTIDのformat
• GTIDの範囲指定

• p27, 下から10行目くらい, 準動機レプリケーションを利用していれば、最も進んだスレーブはマスターがクラッシュした時点のデータと全く同じデータを持っているはずである。 <- ロスレスレプリケーションでも若干失う部分はあるのでは？

• GTIDで使えなくなるSQL文?

• gtid_executedとgtid_purgedシステム変数の意味と使われ方

  • binlog_gtid_simple_recoveryがtrue,falseでそれぞれどういうふうにbinlogの中身を精査しているのか?

メモ - 5.7以降ではchange masterでuser, passwordを指定しない。 - スレーブ上のmaster.infoファイルかmysql.slave_master_infoテーブルに平分で書かれてしまう - start slave user = '<user>' password = '<passwd>' で指定 - GTIDのonline有効化,無効化手順(p28~32) - GTIDが有効でbinlogが有効でないものはmysql.gtid_executed テーブルに書かれる

コマンド

• show binary logs
• show binlog events
• show relaylog events

config

• enforce_gtid_consistency
  • 実行されるSQL文がGTID互換であることを保証する
  • ON: GTID互換でないSQLを排除する, 排除した場合はエラー
  • WARN: errorにならずエラーログに出力(この設定にしてONにするまえに非互換のものを潰していく)
• gtid_mode
  • ON: GTIDモードのbinlogを生成、受け取り
  • OFF_PERMISSIVE: GTIDモードのものでもそうでないものでも受け取れる
• session_track_gtids
  • OFF: OKパケットに含まない
  • OWN_GTID: 自分自身が保有するRWトランザクションのみGTIDを返す
  • ALL_GTIDS: Read-Onlyなトランザクションであっても最新のGTID Setを返す

TODO

• GTID部分の疑問を調べる
• ロスレスレプリケーションでMaster復旧後に出るであろうslaveとの差分を実験で確認してみる
• peformance_schemaのreplication関連テーブルでshow slave status以上に何が見られるのか確認

.

Transactional Information Systems続き

3.4

この節での我々のゴールはscheduleの正しさの判断(correctness criteria)を考案することである。

すべてのschedule, Sに対して、そうした判断σを以下のように考える。

このとき0, 1はfalse, trueをそれぞれ意味している。

従って、正しいスケジュール(correct schedules)は以下のようにかける。

具体的な判断σは以下の要件を満たす

この章の目的はトランザクションの意味がわからないという前提でそれらを適切なものかを判断することである。 そして、構文的な意味(syntactical semantics)を導入することでこれらを判断できるようになった。 しかし、これらではスケジュールの有効な判断ができないので、さらに条件が必要である。

まずそれぞれの独立したトランザクションは一貫した操作である(maintain the integrity)とする。これはserial historiesが正しいと結論付けることに効果がある。

そして、パフォーマンス上の理由からserial historyに興味はないが、これと同等な関係(equivalence relation)を選択することで正確さの基準として利用する。

≈をすべてのschedule集合Sと同等な関係をあわらす記号と定義する。 これによりSと同等なクラス(equivalence classes)、[]が出てくる。

• [S]≈内のscheduleはすべてそれぞれが同等な関係である
• これらによりserial scheduleと同等なクラスの要素をserializableであるという。