cles::blog

MariaDB は yum/dnf で自動的にアップデートされるようにしていたのですが、いつの間にか以下のようなエラーが出るようになってしまっていました。

どうやら GPG のキーが新しくなった^*1ようで、エラーを解消するにはこれをインストールしてやる必要があります。
MariaDB の公式マニュアル通りに以下を実行することで大丈夫でした。

• ^*1: GPG - MariaDB Knowledge Base

今度は Redmine + MariaDB を Docker 化していきます。

Redmine も MariaDB もどちらも公式のイメージを使います。

• redmine
• mariadb

今回の Redmine は要件として

• バージョンは 3.x 系統であること
• パスは /redmine で参照できること

というのがあるので、この部分についてはカスタマイズを行っています。

ファイルを配置したら以下のコマンドで起動できます。

起動ができたら http://hostname:3000/redmine/ でアクセスができるはずです。

† マイグレーション

既存の環境からの DB のマイグレーションについては、docker-compose exec redmine-db bashで MariaDB のコンテナに入り、MariaDB にデータをインポートすれば良いと思います。ファイルについては ./data ディレクトリ以下に必要なファイルをコピーすれば OK です。

† ファイル構成

今日は朝から php + MariaDB の環境で以下のエラーが発生して困ってしまいました。

Malformed communication packet というエラーは初めて見たかもしれません。

† MariaDB をダウングレードして暫定対処

原因としては MariaDB のバージョンアップに起因するようなので、以下のように MariaDB をダウングレードして暫定対象しました。

† 同じ話題が Stack Overflow にも

以下の Stack Overflow のエントリににもあるように、意外と同じところでハマった人は多いようです。
これを見ると PHP 7.3 では発生しないという話も出ているので PHP 7.1 と最新版の Maria DB の問題みたいですね。

• mysql - SQLSTATE[HY000]: General error: 1835 Malformed communication packet on LARAVEL - Stack Overflow

昔書いた Ruby のプログラムを CentOS 7 上で動かそうとしたのですが、MariaDB が 10.4 と比較的新しいバージョンだったので gem で mysql がインストールできないので困ってしまいました。

mysqlを見ると、最終アップデート日が 2013 年になっていて、最近はメンテナンスされていないようです。このまま粘っても解決の見込みも立たないので、mysql2 に移行してしまうことにしました。

† ソースの書き換えは大きく3箇所

基本的には以下の3箇所を変更してやれば、基本的な動作はするようです。
Date などの部分を自動的に cast する機能がついたようですが、これは :cast => false でオフにしてあります。

CentOS 7 に MariaDB をインストールして、Ruby の gem mysql2 実行したらエラーになってしまって困ってしまいました。

エラーメッセージを読む限りリンカのエラーのようなので、もう一度良く MariaDB のインストールを確認したら MariaDB-shared が入っていないのが原因だったようで、以下のコマンド１行で解決でした。MariaDB-devel だけでいけると思っていたのが、勘違いでしたね。

† CentOS 7 への MariaDB のインストール

ハマらないように次回からは以下のような感じでインストールすることにしようと思います。

先日、CentOS 7 の MariaDB を 10.3 にアップデートした話を書きましたが、10.1 → 10.3 の場合は 「A manual upgrade is required. 」と言われてしまうことが分かりました。
ちょうど yum でアップデートしようとすると、以下のようなエラーが出ます。

† 仕方がないのでマニュアルでアップデート

マニュアルでアップデートと言っても、やることは一旦アンインストールしてから、再インストールするだけです。
とりあえずエラーメッセージに従って、非互換な部分について確認します。
やはり主な問題は sql_mode の部分でしょうか。

• Upgrading from MariaDB 10.2 to MariaDB 10.3 - MariaDB Knowledge BaseUpgrading from MariaDB 10.1 to MariaDB 10.2 - MariaDB Knowledge Base

ちなみに yum remove しても /var/lib/mysql の下のデータファイルは消えませんが、念のため全データのダンプは取っておきます。
.conf は .rpmsave にリネームされてしまうので、特別な設定を入れている場合にはファイルを復元しておきます。

具体的には以下のような感じでしょうか。

CentOS 7 に載っている MariaDB 5.5 を 10.3 にアップデート^*1してみたので、その手順をメモ。

† アップデート自体は yum で OK

単に MariaDB を更新するだけならば、以下の手順ですんなりアップグレードできます。

† 問題になるのは SQL_MODE の STRICT_TRANS_TABLES

MariaDB （MySQL）は当初はいろいといい加減な部分がありましたが、最近は機能も増えていろいろと厳密になってきています。

特にバージョンアップの際に問題になると思われるのは、最近のバージョン（10.2.4 以降）の SQL_MODE にデフォルトで設定されている STRICT_TRANS_TABLES という指定です。これにより INSERT 文の書き方がいい加減な場合、これまで通っていた INSERT 文が通らなくなるという不具合が発生します。

以下が MariaDB 10.3 系でのデフォルトの SQL_MODE です。

ちなみに、この SQL_MODE は

• 10.1.7 以前は指定なし
• 10.1.7 は NO_ENGINE_SUBSTITUTION, NO_AUTO_CREATE_USER
• 10.2.4 以降は STRICT_TRANS_TABLES, ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER, NO_ENGINE_SUBSTITUTION

という設定になっているようです。

とりあえず、デフォルトから STRICT_TRANS_TABLES を除くためには /etc/my.cnf.d/server.cnf の [mariadb] のセクションに以下を追加する必要があります。

変更後に MariaDB のデーモンを再起動させると、SQL_MODE が以下のようになっていることが確認できるはずです。

• ^*1: DB をアップデートするといろいろ動かなくなったりするのであまりやりたくなかったのですが、あるテーブルで Row size too large (> 8126) というエラーを吐くようになってしまったので、ROW_FORMAT=DYNAMIC に変換するための苦肉の策です。

Windows 10 のコンソール上から MySQL (MariaDB) にログインすると、文字コードをきちんと CP932 や SJIS にしていても日本語が文字化けすることがあるようです。

「することがある」とちょっとぼやかした書き方なのは、同じバージョンの Windows 10 と MySQL (MariaDB) の組み合わせで導入しても文字化けする端末とそうでない端末があり、僕が調べた限りでは再現条件が不明です。確認方法は簡単で、以下のようなテーブルを使わない SQL を打ち込んでみるだけです。嘘のような話ですが、こんな単純なSQLですら文字化けします。

いろいろ調べてみると Windows 10 1809 のコンソールには以下のバグがあり、今のところ Fix されていないようです。この指示に従って文字化けしているマシンの cmd.exe の設定をレガシーコンソールモードにしてみると、文字化けが解消することが確認できました。こういうのが OS のバグというのは困ったものです。

バージョン 1809 の OS 上でコンソール出力が正しく表示されない問題について

本問題は対象のバージョンの OS で導入された新しいコンソールの不具合に起因して発生しています。
出力ストリームに紐づけられた内部的なコードページ テーブルの初期化処理に不足があり、内部処理でマルチバイト文字を正しく認識することができず、正しくコンソール出力を行えない問題が発生します。

MariaDB に UTF-8 の絵文字を格納したい場合には、歴史的経緯から charset を utf8mb4 にしておく必要があります。

このブログも含めて、既存のテーブルが utf8 の場合にに utf8mb4 に切り替えようとするといろいろ面倒なことがあるので、最小限の変更でなんとか誤魔化す方法がないかと思って調べてみると、数値文字参照でエスケープするという方法を見つけたのでメモ。

• UTF-8 の4バイト文字を HTML 数値文字参照に変換する - Qiita

例えば 🦊 を 🦊 にしてしまえば 1 バイト文字だけになるので、テーブル定義を変更しなくても DB に格納できることになります。
ただ、この逃げ方は内容の検索とかを行う場合に問題になりますが、4バイトの文字はほぼ絵文字なので、今回は目を瞑ることにしました。

ちょうど以下のルーチンを使わせていただきました。

EcmaScript 6 の String.prototype.codePointAt および String.fromCodePoint を使えば、次のように書けます。

function utf8mb4_encode_numericentity(str) { var re = /[\uD800-\uDBFF][\uDC00-\uDFFF]/g; return str.replace(re, function(match) { return '&#x' + match.codePointAt(0).toString(16).toUpperCase() + ';'; }); }

あるプロジェクトで使っている MySQL（というか MariaDB）が遅いので、mysqldumpslow を使ってチューニングしてみました。

mysqldumpslow^*1 というのは slow ログファイルを解析して、要約を表示してくれるユーティリティで、これを使うと slow ログの中でもよりボトルネックになっているクエリを探し出すことができます。

† まずは slow ログを MariaDB/MySQL に吐かせる

mysqldumpslow を使うためには、対象となる slow ログ（時間がかかる SQL のログ）を手に入れる必要があります。
通常の MariaDB/MySQL では、slow ログは以下のように無効になっているはずです

これを以下のクエリによって書き換えてやります。
設定は即時有効になりますが、再起動時には元に戻ります。常に出力する場合には my.cnf に定義を書込んでください。
また、ここでは slow ログの閾値を 0.5 秒としていますが、場合によってはもっと小さくした方が良いかもしれません。

† slow ログを mysqldumpslow に喰わせる

あとは出力された slow ログを以下のような感じで mysqldumpslow に喰わせると結果を得ることができます。

クエリ内の数値や文字列は 'S' や 'N' に置換されて纏められるので、slow ログの量が多くても出力結果はかなり少なくなっているはずです。あとはこの出力結果を EXPLAIN して、クエリの実行計画を見ながらインデックスなどを調整してやれば OK です。

• ^*1: MySQL :: MySQL 5.6 リファレンスマニュアル :: 4.6.9 mysqldumpslow — スロークエリーログファイルの要約