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 です。

† ファイル構成

しばらくウォッチしていないうちに Ruby 3.0.0 がリリースされていました。
Ruby 2.7 からの変更がいろいろとある^*1ので、時間をとって確認する必要がありそうです。

Ruby 3.0.0 リリース

Ruby 3.0系初のリリースである、Ruby 3.0.0 が公開されました。

• ^*1: ruby/NEWS.md at v3_0_0 · ruby/ruby · GitHub

今日は朝から 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

gem mysql2 をマルチスレッドで使っていたら、以下のようなエラーがでて困ってしまいました。

どうやら mysql2 はスレッドセーフではないことが原因の模様。

いろいろと調べてみたら、MutexLockedQuerying^*1というモジュールを書いている人を見つけたので、ちょっと改造して取り込んでみました。元の実装だとクラス変数を使っているのでロックがインスタンス単位ではなく、グローバルにかかってしまうので、インスタンス変数に変更してあります。ロックの粒度的にはこちらの方が望ましいはずです。

• ^*1: shared_connection.rb

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