はてなブックマーク

こちらを参照： interdb.hatenablog.com 2018年頃に華々しくデビューした EDBのプラガブルストレージエンジン:zheap。 当時は開発者たちがカンファレンスなどで大々的に宣伝したので、今でもzheapに期待している人も多いようである。 しかしzheapの現状は大方の想像とは全く異なる。 試しにzheapのmasterブランチのコミット履歴を見てみよう。最終コミットは2019年9月20日である。一年以上作業が行われていない。 以下、zheapのこれまでの経緯と現状について公開されている情報をまとめ、今後について私見を述べる。 zheap とは 簡単に言えば、zheapとは「トランザクション処理にundo logを使う」タイプの「プラガブルストレージエンジン」である。 長所としては以下の2つが挙げられている。 undo logを使うことで、従来のUPDATE処理による

書籍「PostgreSQL全機能バイブル https://www.amazon.co.jp/dp/4774153923」の(アップデート途中の)原稿を CC BY-SA 4.0 + ２条件*1の下でgithubで公開します。 https://github.com/s-hironobu/postgresqlref CC BY-SA 4.0 + ２条件の下なら、改変、再配布、販売は可能です。 *1:詳細はGitHub上に記載してあります

MySQLでslaveをクラッシュセーフ*1にするには、 MySQL 5.6以上 relay_log_recovery=ON relay_log_info_repository=TABLE というセッティングが必要。詳細は"こちら"、翻訳版は"こちら"。 ざっくり言えば、リレーログのreplayと同じトランザクションで、InnoDBテーブルにリレーログの情報を書き込みcommitするので、大丈夫だよというお話。 MariaDBがこの機能に追従しないので、どうしたんだろうと思っていたら、MariaDBはGTIDのreplay状態などをgtid_slave_posというInnoDBテーブルに書き込むという技術的選択をしていた。もちろん、書き込むタイミングはreplayとおなじトランザクション。 よって、MariaDB10.0以降は、GTIDを設定すればslaveがクラッシュセーフになる。Mar

このブログに限り完全に著作権を放棄します(あくまでこのブログだけ。他のブログ、および下の英語文書は範囲外)。勝手に使ってよし。2016.12.20 公開した文書のごく一部を、翻訳して公開。(BLOGにするにあたり、構成は変えた。) http://www.interdb.jp/pg 概要 checkpoint_segmentsが廃止され、WALファイル数の上限下限をmax_wal_sizeとmin_wal_sizeで指定できるようになった。 WALファイル数は(これらの制限内で)サーバの活動状況=WALファイルの消費量に合わせて変化する。あまり書き込みがなければWAL数は減少し、活発になればWAL数が増える。 保存するWAL数は基本的にリカバリに必要不可欠なものに限られ、無駄なWALファイルを溜め込む事は無くなった。 理解のための前提条件 CHECKPOINTの起動タイミング CHECKPO

よい機会なのでまとめておく。対象はMySQL5.6以下とMariaDB10.0以下。 (2014.12.3追記：以下の書籍にも記述した。) 要旨 MySQL/MariaDBのバックアップについて、相変わらず「InnoDBさえ使っていれば、FLUSH TABLES WITH READ LOCKは不要。よってバックアップ中に更新不可になることはない！」との主張が繰り返されているが、少なくとも5.6/10.0まではそんなことはない。 オンラインバックアップに関するロックの正確な記述 より正確に言えば「全データベース領域をバックアップする場合には、FLUSH TABLES WITH READ LOCKは必須。特定のInnoDBだけのデータベースやテーブルをバックアップする際は、この限りではない」。 なのだが、全領域のバックアップをしたい人に対してロック不要説を吹き込む人が未だにいる。 ロックの必要

(2014.12.3追記：以下の書籍にも記述した。) (2014.4.16)微妙に反応があるので、PostgreSQLネタ追記。 PostgreSQLには古くから配列型や複合型というのがあって、似たようなことができる。 あと、MariaDBのダイナミックカラムをJSONで取り出すcolumn_jsonなんてのもあるが、PostgreSQLはネイティブなデータ型としてJSON型があるので、わざわざBLOBを使わずとも、最初からJSON型でデータ処理できる。 そもそも、こんな感じで自由にデータ型も追加できたりと、中の作りはPostgreSQLのほうが圧倒的に出来が良い。 以下、本文。 MariaDB 5.3で導入されたダイナミックカラムという機能が、MariaDB 10.0でかなり使いやすくなった*1。 これは、BLOB型のカラムの内部を独自フォーマットで分割し、一つのカラムに複数のデータを格

2014年3月末にMariaDB 10.0.10 GAがリリースされて、並列レプリケーション(Parallel replication)が目玉の１つっぽく書かれているので、簡単に解説。(2014.12.3追記：以下の書籍にも記述した。) 並列レプリケーションとはスレーブ側の機能で、従来はSQLスレッド１つで処理していたrelayログの再生を、複数のスレッドで並列に処理しようというもの。 MySQLにもパラレルworkerという機能があるが、MariaDBのそれとは並列化の粒度が全く異なる。(注：MySQL5.7でMariaDBと同レベルの機能が実装された。) MariaDBのマスタがコミットしてバイナリログを書く際に、並列実行できるかどうかをバイナリログに書き込んでいる。スレーブはそれに応じて、並列に実行できるSQLは並列に実行する。 具体例をみてみよう。 マスタでbinlog_commi

備忘録として、DSRによるLVSとkeepalivedの設定を段階的に書く。 前提は以下とする。 LVSの転送方式はDSR ネットワークは単一セグメントで超簡単なもの OSはCentOS6.5 今回はMySQLスレーブの死活監視＋管理について。システム構成はLVS+keepalivedの設定 3を参照。 TCPポートの監視：TCP_CHECK もっとも簡単な方法。LVS+keepalivedの設定 2で使った。 keepalived.confの一部を示す。 … 略 … real_server 192.168.1.201 3306 { weight 1 inhibit_on_failure #　サーバ監視: TCPポートにアクセスするだけの超簡易的方法 TCP_CHECK { connect_port 3306 connect_timeout 30 nb_get_retry 3 delay_

備忘録として、DSRによるLVSとkeepalivedの設定を段階的に書く。 前提は以下のとおり： LVSの転送方式はDSR ネットワークは単一セグメントで超簡単なもの OSはCentOS6.5 今回はDSRのLVSでMySQL:Slaveの負荷分散の練習。 以降の予定は： keepalived導入 LVS+keepalivedの２重化 keepalivedによる厳格なMySQL:Slave死活監視＋死活管理 ネットワーク構成 今回は以下の構成。 LVSはeth0 = 192.168.1.100。さらに後々を考えてVirtualIPとしてeth0:0 = 192.168.1.10を設定。クライアントはこのアドレス(VIP)にアクセスする。 MySQL:Masterはeth0 = 192.168.1.200、ただしLVSとは関係ない。 MySQL:Slave1はeth0 = 192.168.

https://mariadb.com/kb/en/optimizer-switch/にあるように、MariaDBのオプティマイザはかなり改良されている。 では、MariaDBのオプティマイザ/エクゼキュータはどの程度優秀か、４つのSELECT文の実行を通してMySQLと(ついでにPostgreSQLと)比較してみる。 (2014.12.3追記：オプティマイザについては省略してますが、こんな本がでます。) 結論を先にいえば「MySQLは検索が速い」というのは都市伝説。MariaDBはがんばってるけどPostgreSQLにはまだまだ及ばず。 ＊念のため。これはベンチマークじゃないよ、オプティマイザ/エクゼキュータの機能比較です。 自分で再確認したい場合はこちらにスクリプト群と実験のやり方を簡単に書いたので参照のこと。 調査環境 同一マシンにMySQL5.6.14、MariaDB10.0.4、

バージョン5.6で"innodb_flush_log_at_trx_commit=1"の挙動が変わった的な話があったので、こっちで軽く調べ、さらに追加調査したので結果を書く。 目的と結論 目的 簡単に書くと、5.6でバイナリログのグループコミットが入ってREDOログとバイナリログの書込みに依存関係っぽいものがでてきたこと、およびfsyncの回数を減らした的なアナウンスや解説がポツポツあるので、具体的にどうなっているのか調べるのが目的。 結論 結論を先に書くと： innodb_flush_log_at_trx_commit=1での基本的な挙動は変わらない。 COMMIT毎にREDOログのwrite+fsync、バイナリログのwrite+fsyncがある。 変わったのは バイナリログの書込みがグループコミットになった REDOログとバイナリログの処理の後にtrx_commit_complate

『MySQL 5.6 ではinnodb_flush_log_at_trx_commitの意味が MySQL 5.5 と違う』で、論理飛躍*1や間違い*2があったので、結論が正しいかどうかチェックしてみた。 なお、flushというかfsync()の呼び出しについて、および上記の記事に対する結論はこちらに書いたので参照。 ソースコードのトレース MYSQL_BIN_LOG::ordered_commit()からtrx_commit_in_memory()まで辿ってみる。 (1) MYSQL_BIN_LOG::ordered_commit() ここのStage 3で　finish_commit()を呼ぶ。 /* Stage #3: Commit all transactions in order. */ ... 略 .... (void) finish_commit(thd); ... 略 ..

(2014.12.3追記：このblogの内容は、以下の書籍にも反映させた。) SQLレベルの差異 MariaDB5.5とMySQL5.5ではSQLレベルでの違いはほとんどなかった。autoincrementの最大値の扱いくらい。 ただし、MariaDB10.0でREGEXPがマルチバイト対応になったので、アプリ側は注意。 項目 MySQL MariaDB Autoincrement 最大値に達すると、以降は最大値を繰り返す。Warningのみ。エラーにならない。tinyintなら…,125,126,127,127,127… 最大値-1まで。以降はエラーを返す。tinyintなら…,125,126,ERROR,ERROR,… EXPLAIN文 JSON形式 バージョン5.6から 未対応 Optimizer Trace バージョン5.6から 未対応（ただし、MariaDBのほうがオプティマイザ

2013年9月9日、いきなりPostgreSQL9.3がリリースされた。 それを記念してFDWを使って本当のデッドロック状態をつくって遊んでみようと思う。 準備 サーバを２台準備する。サーバはtest1とtest2とする。 test1 PostgreSQLとpostgres_fdwをインストールし、データベースtestdbを作る。 $ cd contrib/postgres_fdw $ make && make install $ cd /usr/local/pgsql $ ./bin/createdb testdb 次に、CREATE EXTENSIONでpostgres_fdwを呼び込み、テスト用のテーブルaとbを作る。 testdb=# CREATE EXTENSION postgres_fdw; CREATE EXTENSION testdb=# CREATE TABLE a (i

PostgreSQLとMySQLのバッファについて。 PostgreSQLのバッファマネージャ 詳細はこちらをみて頂くとして、PostgreSQLのバッファマネージャは、２００５年リリースのバージョン8.1で大幅に変わった。 以下の表をみて頂くとわかるようにページ置換アルゴリズムは、8.0まではリストで実装したLRUとそのバリエーションであったが、8.1から配列で実装したClockSweep方式になった。 ページ置換アルゴリズムとロックの変遷 バージョン ページ置換アルゴリズム バッファマネージャのロック 方式 説明 PostgreSQL での呼称 説明 7.4まで [〜2004] LRU "Least Recently Used"の略称。最もオーソドックスなアルゴリズム。 BufMgrLock 排他ロックのみ。ページの入れ替えだけでなく、読み取りでも排他ロックをかける*1。 8.0.0〜

llama.cppだけでなくollamaもLLMアプリケーションのProxyにできる。 ollama.com 例えば以下のモデルがダウンロード済みとする。 (.venv) $ ollama list NAME ID SIZE MODIFIED phi3.5:latest 61819fb370a3 2.2 GB 2 weeks ago llama3.1:latest 62757c860e01 4.7 GB 7 weeks ago llava:13b 0d0eb4d7f485 8.0 GB 3 months ago solar:latest 059fdabbe6e6 6.1 GB 3 months ago mistral:latest 2ae6f6dd7a3d 4.1 GB 3 months ago phi3:medium 1e67dff39209 7.9 GB 3 months ago ge

引き続きLock-Freeアルゴリズム。Lock-Free Queueの2実装。 CAS based Lock-Free Queue 一つ目はCASを使ったLock-Free Queueの論文で提案されたアルゴリズムの実装。 特徴としては: 1. 非常にシンプル 2. スレッド数に制限がないこと(予めスレッド数の上限を設定しなくてよい) 3. 使われるメモリ領域はqueueの要素数に比例し、スレッド数に依存しない(スレッドはメモリ領域を要求しない) これはかなり良い性質である。なぜならLock-Freeなアルゴリズムは複雑怪奇なものが多く、予めスレッド数の上限を指定しなければならないものや、スレッド毎にかなりのメモリ領域を要求するものも多いからだ*1。 LL/SC based Lock-Free Queue] 二つ目はLL/SCを利用したLock-Free Queueの論文の実装。 このア

以下、DBマガジン2010年7月号の草稿から innotop innotopを使えば、現在どんなSQLが実行されているかをリアルタイムで知ることができる。 ここでは簡単な使い方と応用編としてSQLのサンプリング、および解析スクリプトを紹介する。 ダウンロードは以下のURLから行う。 innotopはperlスクリプトなので、MySQLに接続するためのモジュール(DBIやDBD)を予めインストールしておくこと。 http://sourceforge.net/projects/innotop/ ダウンロードしたアーカイブを展開したら、以下の手順を実行する。デフォルトでは/usr/bin以下にインストールされる。 $ tar xvfz innotop-1.6.0.tar.gz $ cd innotop-1.6.0 $ perl Makefile.PL $ make $ make install初

Streaming Replication搭載のPostgreSQL9.0リリースが近づき、 MySQLとのレプリケーション比較が今後ますます盛んになると思われるので、 MySQLユーザ向けにPostgreSQLの説明をしてみようと思う。 参考->PostgreSQLユーザのためのMySQLバイナリログ・レプリケーション講座 (2012.10.30追記)PostgreSQLのレプリケーションについては書籍にまとめたので参照のこと。 原稿のサンプル：仕組みと設定を公開したので参照。 [レベル:1] PostgreSQLのWALログ PostgreSQLには「WALログ」と呼ばれるREDOログ(トランザクションログ)がある。MySQLでいうところのInnoDBのinnodbログのことである*1。 なぜレプリケーションの説明に"WALログ"がでてくるかといえば、PostgreSQL9.0のレプリ

Original Streaming Replication搭載のPostgreSQL9.0リリースが近づき、MySQLとのレプリケーション比較が今後ますます盛んになると思われるので、PostgreSQLユーザ向けにMySQLの説明を行う。 参考->MySQLユーザのためのPostgreSQL:WALログとレプリケーション講座 なお、なぜ最初に延々とバイナリログを説明するかといえば、MySQLのレプリケーションでマスタからスレーブに送るのは、バイナリログのデータだからである。 [レベル:1] MySQLのバイナリログ MySQLにはWALログに直接対応するものはない。理由はMySQLがマルチストレージエンジンだからである。 マルチストレージエンジンについては後述するのでここでは簡単に説明すると、 MySQLはトランザクション機能ありのInnoDB型というテーブルや、トランザクション機能なし

無理矢理"concurrent"ネタの流れでpg_rmanの紹介。 concurrent pg_restore バージョン8.4のpg_restoreから、リストアを並行して行う"-j"オプションが追加された。 百聞は一見にしかず、実際に従来の1プロセスでのリストアと、2プロセスでの並行リストアを行ってみる。 $ pg_dump testdb -F c -f /usr/develop2/testdb.backup $ dropdb testdb; createdb testdb; \ > time pg_restore -d testdb /usr/develop2/testdb.backup real 33m3.100s user 0m26.898s sys 0m3.292s $ dropdb testdb; createdb testdb; \ > time pg_restore -d