MySQL on ララジャパン

第２のデータベースにアクセス

Fri, 14 Nov 2025 12:04:49 +0900

たいていのプロジェクトで扱うデータベースは１つですが、これが２つあるいは３つのデータベースにアクセスするとなったら、どう対応するのでしょう？というのが今回のテーマです。

データベースのコネクション

まず、データベースのコネクションに関しての説明です。扱うデータベースが１つとすると、

.env

...
DB_CONNECTION=mysql
DB_HOST=localhost
DB_PORT=3306
DB_DATABASE=db1
DB_USERNAME=root
DB_PASSWORD=password
...

と設定します。これらの環境変数は、以下のconfig/database.phpにおいてのデータベース接続のための値となります。

config/database.php

return [

    'default' => env('DB_CONNECTION', 'mysql'),

    'connections' => [

        'mysql' => [
            'driver' => 'mysql',
            'url' => env('DB_URL'),
            'host' => env('DB_HOST', '127.0.0.1'),
            'port' => env('DB_PORT', '3306'),
            'database' => env('DB_DATABASE', 'laravel'),
            'username' => env('DB_USERNAME', 'root'),
            'password' => env('DB_PASSWORD', ''),
            'unix_socket' => env('DB_SOCKET', ''),
            'charset' => env('DB_CHARSET', 'utf8mb4'),
            'collation' => env('DB_COLLATION', 'utf8mb4_unicode_ci'),
            'prefix' => '',
            'prefix_indexes' => true,
            'strict' => true,
            'engine' => null,
            'options' => extension_loaded('pdo_mysql') ? array_filter([
                PDO::MYSQL_ATTR_SSL_CA => env('MYSQL_ATTR_SSL_CA'),
            ]) : [],
        ],
...

扱うデータベースが２つのとき

デフォルトのデータベースへのコネクションが、mysqlとすると、もう１つ扱うデータベースを mysql2 として、先のconfig/database.phpに追加することができます。

config/database.php

return [

    'default' => env('DB_CONNECTION', 'mysql'),

    'connections' => [
      　 // デフォルトのデータベース
        'mysql' => [
        ...
        ],

　　　　// 第２のデータベース
        'mysql2' => [
            'driver' => 'mysql',
            'url' => env('DB2_URL'),
            'host' => env('DB2_HOST', '127.0.0.1'),
            'port' => env('DB2_PORT', '3306'),
            'database' => env('DB2_DATABASE', 'laravel'),
            'username' => env('DB2_USERNAME', 'root'),
            'password' => env('DB2_PASSWORD', ''),
            'unix_socket' => env('DB2_SOCKET', ''),
            'charset' => env('DB2_CHARSET', 'utf8mb4'),
            'collation' => env('DB2_COLLATION', 'utf8mb4_unicode_ci'),
            'prefix' => '',
            'prefix_indexes' => true,
            'strict' => true,
            'engine' => null,
            'options' => extension_loaded('pdo_mysql') ? array_filter([
                PDO::MYSQL_ATTR_SSL_CA => env('MYSQL_ATTR_SSL_CA'),
            ]) : [],
        ],
...

mysql2では、環境関数名は皆DB2_のプレフィックスとなっていることに注意を。

.envでは、こんな感じに設定します。

.env

...
DB_CONNECTION=mysql
DB_HOST=localhost
DB_PORT=3306
DB_DATABASE=db1
DB_USERNAME=root
DB_PASSWORD=password

DB2_HOST=localhost
DB2_PORT=3307
DB2_DATABASE=db2
DB2_USERNAME=root2
DB2_PASSWORD=password2
...

第２のデータベースにアクセスするには

さて、第２のデータベースにアクセスしてみましょう。

クエリビルダーでは、以下のようにconnection()の引数に第２のデータベースのコネクション mysql2 を指定するだけです。

DB::connection('mysql2')->table('user')->get();

Eloquentではどうでしょう。

まず、第２のデータベースのモデルを作成します。

namespace App\Models;

use Illuminate\Database\Eloquent\Model;

class RemoteUser extends Model
{
    protected $table = 'users';

    protected $connection = 'mysql2'; // ここでコネクションを指定
}

ここでは、デフォルトのデータベースと同じように、第２のデータベースでも users というテーブルが存在すると仮定します。通常と違って、mysql2のコネクションが指定されていることも注意を。

この設定なら、クエリの実行はデフォルトのデータベースのEloquetとまったく変わりません。簡単ですね。

RemoteUser::all();

Eloquentで動的にコネクションを指定

先のEloquentはモデル内ですでに指定されている固定のコネクションでしたが、前もってわからないときはどうしましょう。つまりモデルの定義が以下のようなときのことです。

namespace App\Models;

use Illuminate\Database\Eloquent\Model;

class RemoteUser extends Model
{
    protected $table = 'users';
}

このようなときは、クエリ実行時において、以下のようにコネクションを指定します。

RemoteUser::on('mysql2')->get();

上では、RemoteUser::on(‘mysql2’)は、Illuminate\Database\Eloquent\Builderを返すので、RemoteUser::on(‘mysql2’)::all()とは出来ないことに注意を。

DB::beginTransactionとDB::transaction

Thu, 23 Oct 2025 09:15:17 +0900

アプリで使用しているデータベースの整合性を保つために、トランザクションのデータベース関数があります。Laravelでは、現時点で２通りの方法があります。Laravelのバージョン12.32.0において、DB::afterRollBackが登場して、どちらとも機能的に同等になりました。

トランザクション

トランザクションを簡単に説明すると、例えば以下のように複数のデータベース文を実行するとき、

DB::table('points')->insert(['member_id' => 1, 'point' => 1000]);
DB::table('points')->insert(['member_id' => 1, 'point' => 2000]);

最初のデータベース文が成功して、２番目のデータベース文が何等かの理由で失敗したときに、成功したものだけを残すのでなく、両方と何も起こらなかった状態に戻す機能です。

つまり、この２つデータベース文をあたかも１つのデータベース文のように扱い、両方が成功するならコミットとし、失敗が起こるならロールバックします。上の例では、成功なら3000ポイント追加され失敗したならたとえ１つが成功しても0ポイントの追加となります。

DB::beginTransaction

トランザクションをLaravelで実行するには、以下のようにDB::beginTransactionを使います。

DB::beginTransaction();

try {
    DB::table('points')->insert(['member_id' => 1, 'point' => 1000]);
    DB::table('points')->insert(['member_id' => 1, 'point' => 2000]);

    DB::commit();

    echo "ポイント追加成功しました。";
} catch (\Exception $event) {
    DB::rollBack();

    echo "ポイント追加に失敗しました。";
    echo $event->getMessage(); // エラーを表示
}

トランザクションと対象となるデータベース文は、try,catchに入れて、成功ならDB::commitで変更を保存し、エラーがあるなら（例外が発生）、DB::rollbackですべての変更を戻します。DB::endTransactionというものはないのでブロックで囲まれてなく変な感じですが、問題はありません。DB::beginTransactionをtryの中の最初の文としても変わりません。

DB::transaction

先の例では、いちいちコミットとロールバック、それぞれDB::commitとDB::rollbackを指定する必要がありますが、DB::transactionを使い対象のデータベース文を以下のようにクロージャのなかに入れるなら、結構すっきりします。

DB::transaction(function () {
    DB::table('points')->insert(['member_id' => 1, 'point' => 1000]);
    DB::table('points')->insert(['member_id' => 1, 'point' => 2000]);
})

以下のようにデータを変数で渡すことも可能です。

$data = [
    ['member_id' => 1, 'point' => 1000],
    ['member_id' => 1, 'point' => 2000]
];

DB::transaction(function () use($data) {
    DB::table('points')->insert($data[0]);
    DB::table('points')->insert($data[1]);
})

また、DB::beginTransactionのように、コミットとロールバックの後に必要なプログラム文を追加も以下のように可能です。

$data = [
    ['member_id' => 1, 'point' => 1000],
    ['member_id' => 1, 'point' => 2000]
];

DB::transaction(function () use($data) {
    DB::afterCommit(function() {
        echo "ポイント追加成功しました。";
    });

    DB::afterRollBack(function () {
        echo "ポイント追加に失敗しました。";
    });

    DB::table('points')->insert($data[0]);
    DB::table('points')->insert($data[1]);
})

注意する必要があるのは、対象のデータベース文は、DB::afterCommitとDB::afterRollBackの後に必ず置くことです。また、DB::afterRollBackは、Laravelのバージョン12.32.0においての登場なので、それより前のバージョンでは使えません。

最後に、DB::beginTransactionの例のようにエラーをキャッチしたいなら、同様にtry,catchを使います。

$data = [
    ['member_id' => 1, 'point' => 1000],
    ['member_id' => 1, 'point' => 2000]
];

try {
    DB::transaction(function () use($data) {
        DB::afterCommit(function() {
            echo "ポイント追加成功しました。";
        });

        DB::afterRollBack(function () {
            echo "ポイント追加に失敗しました。";
        });

        DB::table('points')->insert($data[0]);
        DB::table('points')->insert($data[1]);
    });
} catch (\Exception $event) {
    echo $event->getMessage();
}

GROUP_CONCATの上限

Tue, 14 Nov 2023 06:23:37 +0900

先日携わっているプロジェクトにおいてとある不具合に遭遇しました。DBから取得したデータが一部欠損していたのです。調査したところデータを取得する際のクエリにおいてGROUP_CONCATが使用されており、そちらの上限をオーバーした事が原因でした。今回は直接Laravelと関係する訳ではありませんが、LAMP環境を運用する上で遭遇するかもしれない事象という事で備忘録としてまとめます。

GROUP_CONCAT()

GROUP_CONCATはmysqlの関数です。GROUP BYでまとめたデータをカンマ区切りなどで取得する際に使います。例えば、以下のようなfoodテーブルがあったとします。

# テーブル作成クエリ
CREATE TABLE `food` (
    `id` int NOT NULL AUTO_INCREMENT,
    `name` varchar(255) NOT NULL DEFAULT '',
    `category` varchar(255) NOT NULL DEFAULT '',
    PRIMARY KEY (`id`)
);

そして、そのテーブルに以下のようなデータが挿入されていたとします。

# データ挿入クエリ
INSERT INTO `food` (name, category) VALUES
('みかん', '果物'),
('とまと', '野菜'),
('玉ねぎ', '野菜'),
('きゅうり', '野菜'),
('りんご', '果物'),
('ぶどう', '果物');

GROUP_CONCATを使うと、カテゴリ毎に食べ物の名前をカンマ区切りでまとめて取得できます。以下のように。

SELECT category, GROUP_CONCAT(name) FROM food GROUP BY category;
>>
+----------+----------------------+
| category | GROUP_CONCAT(name)   |
+----------+----------------------+
| 果物     | みかん,りんご,ぶどう       |
| 野菜     | とまと,玉ねぎ,きゅうり       |
+----------+----------------------+
2 rows in set (0.02 sec)

カンマ区切りの文字列なので、explode()などで配列に変換すれば使い勝手が良いですね。

GROUP_CONCATの上限

既にお気づきかと思いますがGROUP BYでまとめたデータが多ければ多いほどGROUP_CONCATの結果も長くなります。前項の例で言えば、例えばカテゴリーが果物のレコードが1000件あったなら、1000件分の果物の名前をカンマ区切りで結合して文字列として取得する訳です。とは言え、そんな長い文字列を取得する訳にも行かないので、mysql側でgroup_concat_max_lenというシステム変数によって取得できる最大の長さが制限されています。group_concat_max_lenのデフォルトの設定値は1024バイトです。

SHOW VARIABLES LIKE 'group_concat_max_len';
>>
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| group_concat_max_len | 1024  |
+----------------------+-------+
1 row in set (0.04 sec)

この制限値を超えた場合、超えた部分のデータは切り捨てられます。group_concat_max_lenの設定値を変えて、実際にこの挙動を確認してみましょう。

まず、GROUP_CONCATの上限を20バイトに設定してみます。

SET group_concat_max_len = 20;

そして、前項で実行したクエリをもう一度実行してみましょう。

SELECT category, GROUP_CONCAT(name) FROM food GROUP BY category;
>>
+----------+----------------------+
| category | GROUP_CONCAT(name)   |
+----------+----------------------+
| 果物     | みかん,りんご,       |
| 野菜     | とまと,玉ねぎ,       |
+----------+----------------------+
2 rows in set, 2 warnings (0.00 sec)

果物はぶどうが、野菜はきゅうりのデータが欠損しています。そしてwarningが発生しています。

SHOW WARNINGS;
>>
+---------+------+---------------------------------+
| Level   | Code | Message                         |
+---------+------+---------------------------------+
| Warning | 1260 | Row 3 was cut by GROUP_CONCAT() |
| Warning | 1260 | Row 6 was cut by GROUP_CONCAT() |
+---------+------+---------------------------------+
2 rows in set (0.00 sec)

3行目と６行目のデータがGROUP_CONCATによって省かれた旨の警告でした。ここでいう3行目、６行目とはGROUP BYで処理される前の結果セットであると推察します。

因みに文字列のバイト数を確認するにはLENGTH関数が使えます。

SELECT LENGTH('みかん,りんご,');
>>
+--------------------------------+
| LENGTH('みかん,りんご,')       |
+--------------------------------+
|                             20 |
+--------------------------------+
1 row in set (0.00 sec)

先ほど途中でカットされたデータのバイト数を確認すると丁度group_concat_max_lenに設定した値である20バイトとなっていますね。内訳は平仮名が１文字３バイト6文字、カンマが１バイト2文字で合計20バイトという訳です。この様にgroup_concat_max_lenで設定したバイト数以上の文字列を取得しようとした場合、制限を超えた分の文字列が欠損して取得されてしまうのです。そして、これがまさに今回私が遭遇した不具合の原因です。

GROUP_CONCATの設定を変更する

GROUP_CONCATの返却値の長さが決まっているなら、group_concat_max_lenを余裕を持たせた充分な値に設定する事で取得するデータの欠損を予防できます。アプリ内の特定の箇所にのみ設定値の引き上げが必要な場合はDB::statement()で一時的に設定すれば良さそうです。

// デフォルトの1024 byteから２倍に引き上げ
DB::statement('SET group_concat_max_len = 2048;')

あるいはアプリ全体で上限を引き上げたいのであればmysqlの設定ファイル、my.cnfに設定を追加してあげればOKです。

my.cnf

[mysqld]
group_concat_max_len=2048

設定を反映させるにはmysqlの再起動が必要なのでお忘れなく。

まとめ

原因が分かるとなんて事ない不具合ですが、直接的なエラーが発生しない為気付くのに少し時間が掛かりました。経験上GROUP_CONCATを使う頻度は多くありませんが、こういう事もあるということを頭の片隅においておきたいものです。

クエリの累計時間にタイムアウトを設定する（２）

Thu, 27 Jul 2023 11:10:26 +0900

前回の記事にてタイムアウトとなった場合に２種類の例外がスローされる事を説明しました。クエリ実行中にタイムオーバーとなった場合は、QueryException。クエリ実行外でタイムオーバーとなり、その後クエリを実行してエラーとなる場合は、自作したTimeoutExceptionです。今回はこれらのエラーをどうキャッチしてハンドリングするのか解説します。

検証用のページ

説明の為にテスト用のコントローラを用意しました。

app/Http/Controllers/TimeoutTestController.php

<?php

namespace App\Http\Controllers;

use App\Services\DbQueryTimeout;
use Illuminate\Support\Facades\DB;

class TimeoutTestController extends Controller
{
    public function index()
    {
        $timeout = (int) request('timeout');

        try {
            // 制限時間の指定があればセット
            if ($timeout) {
                DbQueryTimeout::set($timeout);
            }

            // 重いクエリ１
            DB::statement('select sleep(3) union select 1');

            // 重いクエリ２
            DB::statement('select sleep(5) union select 1');

        } catch (\Exception $e) {
            return 'error';
        }

        return 'success';
    }
}

ルーティングは以下の通りです。

routes/web.php

<?php

use Illuminate\Support\Facades\Route;
use App\Http\Controllers\TimeoutTestController;

Route::get('/timeout_test', [TimeoutTestController::class, 'index']);

indexアクションでは重いクエリが２つ実行されます。それらが正常に処理できた場合はsuccess、何かしらのエラーが発生した場合はerrorを返します。尚、GETパラメタでtimeoutの指定がある場合は、DbQueryTimeoutを使用して制限時間が設定されます。ビルドインサーバーを起動して挙動を確認してみましょう。

php artisan serv

まず、パラメタ無しで /timeout_test へアクセスしてみてください。約8秒後にsuccessと表示されるはずです。次に、timeoutパラメタを指定して制限時間を設定してみましょう。/timeout_test?timeout=5 として制限時間を5秒にしてアクセスしてみて下さい。すると、約５秒後に処理が中断されerrorと表示されるはずです。

Tips: 重いクエリをシミュレートする方法

重いクエリ = 時間が掛かるクエリ、という事でDB側でsleep()を実行してシミュレートできます。mysqlではsleep()は正常にスリープできた場合は0、途中で中断された場合は1が返却されます。しかし、実際の環境ではmax_execution_timeで指定した時間をオーバーして処理が中断された場合は１ではなくエラーが発生します。sleep()においてもタイムオーバーした場合にエラーを返させるには、unionで追加の処理を実行すればOKです。追加の処理はなんでも良いので今回は適当にselect 1としました。実際にmysql clientにて以下を実行して試してみると理解しやすいと思います。

# 制限時間を5秒に設定
mysql> set max_execution_time = 5000;
Query OK, 0 rows affected (0.01 sec)

# 制限時間内に終わるsleepなら0が返却される
mysql> select sleep(4);
+----------+
| sleep(4) |
+----------+
|        0 |
+----------+
1 row in set (4.05 sec)

# 制限時間内に終わらずsleepが中断されたら1が返却される
mysql> select sleep(5);
+----------+
| sleep(5) |
+----------+
|        1 |
+----------+
1 row in set (5.06 sec)

# unionで追加の処理を含めるとエラーが返却される
mysql> select sleep(6) union select 1;
ERROR 3024 (HY000): Query execution was interrupted, maximum statement execution time exceeded

エラーのハンドリング

冒頭で述べた通り制限時間をオーバーした場合は２種類のタイムアウトエラーが発生します。しかし、アプリにおいては当然それ以外のエラーも発生し得るので、タイムアウトエラーとそうでないエラーの場合で判別してエラーを出し分ける必要があります。それぞれどの様に判別すれば良いでしょうか。

TimeoutExceptionをキャッチ

先に簡単な方から、TimeoutExceptionを判別する場合です。こちらはシンプルにスローされたExceptionのインスタンスをチェックすれば判別できます。TimeoutTestController.php のindexアクションを以下の様に書き換えてみましょう。

app/Http/Controllers/TimeoutTestController.php

...
    public function index()
    {
        $timeout = (int) request('timeout');

        try {
            // 制限時間の指定があればセット
            if ($timeout) {
                DbQueryTimeout::set($timeout);
            }

            // 重いクエリ１
            DB::statement('select sleep(3) union select 1');

            // クエリ以外の処理で3秒掛かった
            sleep(3);

            // 重いクエリ２
            DB::statement('select sleep(5) union select 1');

        } catch (\Exception $e) {
            // TimeoutExceptionの場合のエラー文言
            if ($e instanceof TimeoutException) {
                return 'timeout error';
            }

            return 'error';
        }

        return 'success';
    }

TimeoutExceptionは、クエリ実行外でタイムオーバーし、次のクエリが実行されるタイミングでスローされます。そちらを再現する為に、クエリ１とクエリ２の間にPHP側のスリープを3秒挟みました。これにより制限時間が5秒の場合はTimeoutExceptionがスローされるはずです。再度、ビルドインサーバにて/timeout_test?timeout=5へアクセスしてみて下さい。今度はtimeout errorと表示されたはずです。

クエリ実行中にタイムアウトした場合のエラー

クエリ実行中にタイムアウトした場合はQueryExceptionがスローされます。QueryExceptionはタイムアウト以外でもスローされる例外ですので、前項のTimeoutExceptionの様にインスタンスだけではタイムアウトエラーを判別できません。判別には一歩踏み込んで、$e->errorInfoのチェックが必要です。errorInfoはQueryExceptionの親クラスであるPDOExceptionにセットされていた値で、PHPマニュアルによると、データベースハンドラにおける直近の操作に関連する拡張エラー情報が配列で格納されています。タイムアウトエラーとしてQueryExceptionがスローされた際の$e->errorInfoは以下の様になります。

[
  0 => "HY000"
  1 => 3024
  2 => "Query execution was interrupted, maximum statement execution time exceeded"
]

0はSQLSTATEエラーコード、1はドライバ固有のエラーコード、2はそのエラーメッセージです。判別には1のドライバ固有のエラーコードを使用します。こちらの記事によると、max_execution_timeの設定をオーバーした場合のエラーコードは MySQL 8.0.19 以前は3024か1028で、以降は3024に統一されたとの事です。私の環境はまだMySQL5.7なので、1028のエラーコードも補足する必要があります。これらを考慮して、TimeoutTestControllerの例外処理部分を次の様に修正しました。

app/Http/Controllers/TimeoutTestController.php

...
        } catch (\Exception $e) {
            $timeoutError = false;

            switch (get_class($e)) {
                case TimeoutException::class:
                    $timeoutError = true;
                    break;

                case QueryException::class:
                    if (in_array($e->errorInfo[1], [3024, 1028])) {
                        $timeoutError = true;
                    }
                    break;
            }

            if ($timeoutError) {
                return 'timeout error';
            }

            return 'error';
        }

        return 'success';
    }
}

インスタンスのチェックはswitch文でget_class($e)でクラス名を取得して分岐する様に変更しました。QueryExceptionの場合はerrorInfoでエラーコードもチェックします。クエリ実行中にタイムオーバーとなるように/timeout_test?timeout=7へアクセスしてみて下さい。再度、timeout errorが表示されるはずです。

リファクタリング

これまで説明の為にコントローラ側にタイムアウトエラーのエラー処理のコードを記述してきましたが、DbQueryTimeoutと一緒に色々な箇所で使い回すのでまとめておいた方が良さそうです。という事で、DbQueryTimeout::isTimeoutError()にコードを移しました。

app/Services/DbQueryTimeout.php

...
    // タイムアウトエラー発生？
    public static function isTimeoutError(\Exception $e): bool
    {
        $timeoutError = false;

        switch (get_class($e)) {
            case TimeoutException::class:
                $timeoutError = true;
                break;

            case \Illuminate\Database\QueryException::class:
                if (in_array($e->errorInfo[1], [3024, 1028])) {
                    $timeoutError = true;
                }
                break;
        }

        return $timeoutError;
    }
...

isTimeoutError()はシンプルにタイムアウトエラーか否かを判別するメソッドです。このメソッドを使う事でTimeoutTestController側は次の様にシンプルになりました。

app/Http/Controllers/TimeoutTestController.php

<?php

namespace App\Http\Controllers;

use App\Services\DbQueryTimeout;
use Illuminate\Support\Facades\DB;

class TimeoutTestController extends Controller
{
    public function index()
    {
        $timeout = (int) request('timeout');

        try {
            // 制限時間の指定があればセット
            if ($timeout) {
                DbQueryTimeout::set($timeout);
            }

            // 重いクエリ１
            DB::statement('select sleep(3) union select 1');

            // クエリ以外の処理で3秒掛かった
            sleep(3);

            // 重いクエリ２
            DB::statement('select sleep(5) union select 1');

        } catch (\Exception $e) {
            if (DbQueryTimeout::isTimeoutError($e)) {
                return 'timeout error';
            }

            return 'error';
        }

        return 'success';
    }
}

クエリの累計時間にタイムアウトを設定する（１）

Thu, 27 Jul 2023 11:06:11 +0900

先日、管理サイトにてアラートが発生しました。調査すると、ある検索画面で利用者が重いクエリを連続で発行した事が原因でした。待ち時間が長かった為、不安になり検索ボタンを連打してしまったようです。サーバに負荷を掛ける操作については注意喚起するとして、待ち時間に制限が無いのはよくありません。そこで、検索処理に制限時間を設ける事にしました。今回はそちらの実装にあたって色々学んだことがあるので紹介します。

クエリの実行時間を制限する

今回実装した内容を簡単に説明すると、検索処理に対して実行可能時間を設定し、時間切れとなった場合にエラーを返すというものです、要はタイムアウトの設定です。検索処理においてボトルネックとなっていたのはDBへのクエリ部分で、それ以外の処理時間は無視して良いレベルでした。従って、クエリの実行時間に制限を設ける事にしました。

クエリにタイムアウトを設定する方法については過去の記事の「クエリーの実行所有時間の制限」の項目で紹介されており、今回もこちらを使います。簡単におさらいすると、DB::statement()を使用して、MySQLのmax_execution_timeを設定する方法です。例えば、以下は5秒に制限する場合のコードです。

DB::statement('SET SESSION MAX_EXECUTION_TIME = 5000');

こちらを実行すると、以降クエリで5秒以上掛かった場合にQueryExceptionがスローされます。

クエリの累計時間を制限する

ボトルネックとなるクエリが１つの場合は前項の方法で制限時間を設ければOKですが、今回の実装先には重いクエリが複数実行されており、それらの累計時間を制限する必要がありました。例えば、以下のように制限時間を５秒に設定した場合、クエリ１とクエリ２で合わせて５秒を超えたらタイムアウトエラーとします。

クエリの累計時間に制限を設けるには、クエリを実行する毎に都度残り時間を計算し、それを前項で紹介した方法で設定していけば良さそうです。つまり、以下の様に

クエリ１の時点では残り時間を５秒として制限時間を設定しますが、クエリ２の時点ではクエリ１で３秒掛かったので、残りの実行可能時間２秒を制限時間として再設定します。

DbQueryTimeout.php

ロジックについて理解が深まったところで、実際のコードを紹介します。クエリの制限時間を管理するクラスとして app/Services 配下に DbQueryTimeout.php を追加しました。

app/Services/DbQueryTimeout.php

<?php

namespace App\Services;

use App\Exceptions\TimeoutException;
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Str;

class DbQueryTimeout
{
    const TIMEOUT_QUERY = 'SET SESSION MAX_EXECUTION_TIME';

    public static $maxExecutionTime;  // 最大実行可能時間（ミリ秒）

    public static $processStartTime;  // プロセス開始時刻（マイクロ秒）

    // タイムアウト設定初期化
    public static function set(int $seconds): void
    {
        self::$maxExecutionTime = $seconds * 1000;
        self::$processStartTime = microtime(true);

        DB::beforeExecuting(function ($query) {
            // タイムアウト設定のクエリなら何もしない
            if (Str::startsWith($query, self::TIMEOUT_QUERY)) {
                return;
            }

            // 残りの実行可能時間を計算
            $timeRemaining = self::timeRemaining();

            // 実行可能時間が残っていないなら例外スロー
            if ($timeRemaining <= 0) {
                throw new TimeoutException;
            }

            self::setTimeout($timeRemaining);
        });
    }

    // タイムアウト設定
    public static function setTimeout(int $time): void
    {
        DB::statement(self::TIMEOUT_QUERY.' = '.$time.';');
    }

    // 残りの実行可能時間をミリ秒で返す
    public static function timeRemaining(): int
    {
        return self::$maxExecutionTime - self::elapsedTime();
    }

    // 経過時間をミリ秒で返す
    public static function elapsedTime(): int
    {
        return (int) ((microtime(true) - self::$processStartTime) * 1000);
    }
}

後で説明しますが、このクラス内で使用されている TimeoutException は自作の例外クラスになります。app/Exceptions 配下に TimeoutException.php を追加してください。

app/Exceptions/TimeoutException.php

<?php

namespace App\Exceptions;

use Exception;

class TimeoutException extends Exception
{
}

DbQueryTimeout の使い方はとてもシンプルで、実行時間を制限したい箇所の最初にset()を実行するだけです。set()の引数には制限時間を秒で指定します。例えば、制限時間を５秒としたいなら以下の様に。

DbQueryTimeout::set(5);

すると、set()が実行された時点からカウントダウンが始まり、タイムオーバーとなった場合は以下の２パターンでエラーが発生します。

クエリ実行中
クエリ実行外で、それ以後にクエリを実行しようとした

前者の場合はQueryExceptionがスローされ、後者の場合はTimeoutExceptionがスローされます。

参考までに実装例を掲載します。以下は注文データを検索するページです。

app/Http/Controllers/InvoiceController.php

<?php

namespace App\Http\Controllers;

use App\Models\Invoice;
use App\Models\InvoiceShip;
use Illuminate\Http\Request;
use App\Services\DbQueryTimeout;
use Illuminate\Contracts\View\View;

class InvoiceSearchController extends Controller
{

    /**
     * 検索画面
     */
    public function index(Request $request): View
    {
        $input = $request->all();

        // 制限時間を5秒に設定
        DbQueryTimeout::set(5);

        // 注文データ
        $invoices = Invoice::query()
            ->whereBetween('invoice_date', [$input['date_start'], $input['date_end']])
            ->where('invoice_status', '=', $input['invoice_status'])
            ->orderBy('invoice_date', 'desc')
            ->paginate(config('local.items_per_page'))
            ->withQueryString();

        // 注文配送データ
        $invoice_ships = InvoiceShip::query()
            ->whereIn('invoice_id', $invoices->pluck('invoice_id'))
            ->where('invoice_ship_status', '=', $input['invoice_ship_status'])
            ->get();

        return view('admin.invoice_index')
            ->with(compact('input', 'invoices', 'invoice_ships'));
    }

}

上記のコントローラのindexアクションでは以下の３つのクエリが実行されています。

１ページに表示する注文データ
注文データの件数
注文データに紐づく注文配送データ

これら３つのクエリの累計実行時間が５秒を超える場合はエラーが発生します。エラーが発生した場合の処理については次の投稿で紹介します。

コードのポイント

コア部分であるset()で行われている処理について補足です。set()ではクエリ毎に実行されるbefore処理を登録しています。before処理では以下の処理が実行されます。

実行されるクエリが制限時間の設定クエリなら何もせず、そのまま実行
それ以外のクエリなら残りの実行可能時間を計算
残り時間なし（既にタイムオーバー）ならTimeoutExceptionをスロー
残り時間があるならそれを制限時間として設定

before処理の登録にDB::beforeExecuting()を使用している点がポイントです。こちらはドキュメントには載っていませんが、イベントリスナーの様にEloquentやクエリビルダにてクエリが実行される毎に直前に呼び出すコールバックを登録できます。余談ですが、after処理の登録にはDB::listen()というメソッドがあります。（こちらはドキュメントにも載っている。）

DB::beforeExecuting()のクロージャの引数$queryはSQLが文字列で渡されます。1. 実行されるクエリが制限時間の設定クエリなら何もせず、そのまま実行ではそちらが、SET SESSION MAX_EXECUTION_TIMEから始まるクエリかチェックして、そうならbefore処理を終了しそのままクエリの実行に移ります。そうしなければ、この制限時間を設定するクエリに対しても更にbefore処理をして、、、と無限ループとなってしまうからです。

長くなってしまったので、一旦ここで切ります。次回はエラー処理について解説します。

【Eloquent】has() vs joinSub()

Mon, 24 Oct 2022 12:54:19 +0900

過去の記事でも紹介されていますが、親子（or 1対多）関係にあるModelにおいて、「１つ以上子を持つ親」などの条件で絞り込む際にhas()は便利です。

しかし、has()を使わずともjoinSub()でサブクエリを指定して同じ条件で絞り込む事もできそうです。どちらを使うのがベターなのか？気になったので調べてみました。

has()とjoinSub()の違い

例えば、店(Shop)と商品(Product)というModelが有った場合、「１つ以上商品を持つ店」はそれぞれ以下で絞り込むことができます。

// has()で絞り込み
$shops = Shop::has('product')->get();

// joinSub()で絞り込み
$sub = Product::distinct()->select('shop_id');

$shops = Shop::joinSub($sub, 'sub', function ($join) {
        $join->on('sub.shop_id', '=', 'shop.shop_id');
    })->get();

見ての通り、joinSub()の方が冗長ですね。

発行されたsqlはそれぞれ以下になります。

# has()のsql
select * from `shop` where exists (select * from `product` where `shop`.`shop_id` = `product`.`shop_id`);

# joinSub()のsql
select * from `shop` inner join (select distinct `shop_id` from `product`) as `sub` on `sub`.`shop_id` = `shop`.`shop_id`;

has()ではEXISTS句で相関サブクエリを使用して絞り込んでいます。

相関サブクエリとは

mysqlの公式ドキュメントからの引用です。

相関サブクエリは、外部クエリにも現れるテーブルへの参照を含むサブクエリです。

前述のhas()のsqlでは、外部クエリのFROMに指定しているshopをサブクエリ内で参照している為、相関サブクエリと言えます。

相関サブクエリの注意点

レコード数が多いテーブルに紐づいたModelにてhas()使う際は注意が必要です。

相関サブクエリでは外部クエリの結果行数分、比較処理が行われる可能性があり、結果行数が多ければ遅くなる為です。

例えば前述のhas()のsqlでは、shopのレコード数 x productのレコード数分の比較処理が走ることになります。（EXISTS句では条件にヒットする行が見つかればその時点でtrueを返し、次のレコードの比較処理に移るため、あくまでも全件ヒットしなかった場合）

とはいえ、それをjoinSub()に置き換えた場合もGROUP BYやDISTINCTで重複を削除する処理のコストが有るため、一概にどちらが速いと言い切れません。

実際に実装する環境でテストしてみるのが良いでしょう。

今回の実装環境ではhas()でもjoinSub()でも速度に大きな違いはありませんでした。であればよりシンプルに記述できるhas()がベターと考えてそちらを採用することにしました。

SQLのCOUNT()関数と条件

Mon, 22 Aug 2022 05:40:59 +0900

前回に複数のSQL文の結果をうまく１つのSQL文にまとめる話をしました。今回もその続きです。

有効と無効のそれぞれの商品数

実行して知りたい結果は、有効な商品と無効な商品のそれぞれの商品数です。

SQL文のwhereで条件を指定すれば、

mysql> select count(*) from product where active_flag = 'Y';
+----------+
| count(*) |
+----------+
|     9492 |
+----------+
1 row in set (0.01 sec)

mysql> select count(*) from product where active_flag = 'N';
+----------+
| count(*) |
+----------+
|     4065 |
+----------+
1 row in set (0.01 sec)

と２つのSQL文を実行します。

しかし、これを１つのSQL文にすると、

mysql> select count(active_flag = 'Y') as 有効な商品数, count(active_flag = 'N') as 無効な商品数 from product;
+--------------------+--------------------+
| 有効な商品数       | 無効な商品数       |
+--------------------+--------------------+
|              13557 |              13557 |
+--------------------+--------------------+
1 row in set (0.02 sec)

結果おかしいですね。有効も無効も同じ商品数となってしまいました。しかも両方ともすべての商品数です。

COUNT()関数の引数

SQL文のCOUNT()関数では、その引数の値がNULLでないときにカウントします。

例えば、Laravelのデフォルトのプロジェクトで作成されるDBテーブルのusersに対して、以下のようにクエリーすると、

select count(remember_token) from users

ログインで「次回から自動ログインする」(Remember Me?)のチェックボックスをオンにしてログインしたユーザーのみのレコード数を得られます。なぜなら、remember_tokenはレコード作成時にはNULLの値であり、先のようにログインしたときのみにremember_tokenにランダムの文字列が入ります。

先の、有効も無効も結果が同じ商品数となったケースは、以下のように、引数に指定するExpressionは０あるいは１の値となり、NULLの値とはなりません。それゆえに、それらの引数でCOUNT()すると全レコードが対象となります。

mysql> select (active_flag = 'Y'), (active_flag = 'N') from product where active_flag = 'Y' limit 1;
+---------------------+---------------------+
| (active_flag = 'Y') | (active_flag = 'N') |
+---------------------+---------------------+
|                   1 |                   0 |
+---------------------+---------------------+
1 row in set (0.00 sec)

ちなみに、引数にを指定するとき、つまりの馴染みのCOUNT()では、レコードにNULLの値が含まれても全レコードを返します。

条件付きでレコードをカウントするには

さて、それではどう条件付きをカウントしたらよいでしょうか？

１つは先のExpressionが返す値を利用して、合計を計算するSUM()の関数を利用できます。

mysql> select sum(active_flag = 'Y') as 有効な商品数, sum(active_flag = 'N') as 無効な商品数 from product;
+--------------------+--------------------+
| 有効な商品数       | 無効な商品数       |
+--------------------+--------------------+
|               9492 |               4065 |
+--------------------+--------------------+
1 row in set (0.02 sec)

あるいは、IF()の関数で返す値を非NULLあるいはNULLとしてからカウントします。

mysql> select count(if(active_flag = 'Y', 1, null)) as 有効な商品数, count(if(active_flag = 'N', 1, null)) as 無効な商品数 from product;
+--------------------+--------------------+
| 有効な商品数       | 無効な商品数       |
+--------------------+--------------------+
|               9492 |               4065 |
+--------------------+--------------------+
1 row in set (0.01 sec)

ごちゃごちゃしているなら、以下のようにシンプルにもできます。

mysql> select count(active_flag = 'Y' or null) as 有効な商品数, count(active_flag = 'N' or null) as 無効な商品数 from product;
+--------------------+--------------------+
| 有効な商品数       | 無効な商品数       |
+--------------------+--------------------+
|               9492 |               4065 |
+--------------------+--------------------+
1 row in set (0.01 sec)

複数のテーブルのレコード数を１つのSQL文で実行

Sun, 14 Aug 2022 03:26:09 +0900

以前に「調査クエリー」と称して、ウェブ画面でSQL文を入力して実行できるツールを作成しました。それ以来いろいろなSQL文を作成することになったのですが、これはできないだろうというのが最近可能と判って、大喜びです。

DBテーブルのレコード数取得のSQL文は、例えば、

mysql> select count(*) as '商品数' from product;
+-----------+
| 商品数    |
+-----------+
|     31228 |
+-----------+
1 row in set (0.01 sec)

というように、fromでテーブルを指定して、count(*)です。

１つ以上のテーブルのレコード数を取得するには、もう１つのSQL文を連続して実行します。

mysql> select count(*) as '商品数' from product;select count(*) as '店舗数' from shop;
+-----------+
| 商品数    |
+-----------+
|     31228 |
+-----------+
1 row in set (0.01 sec)

+-----------+
| 店舗数    |
+-----------+
|       947 |
+-----------+
1 row in set (0.00 sec)

しかし、先の私の「調査クエリー」ツールでは、１つのSQL文しか１回に実行できないので、使えませんね。私が欲しいのは、１つのSQL文で両方取得です。

なんと、これができるんだなあ。

mysql> select (select count(*) from product) as 商品数, (select count(*) from shop) as 店舗数;
+-----------+-----------+
| 商品数    | 店舗数    |
+-----------+-----------+
|     31228 |       947 |
+-----------+-----------+
1 row in set (0.01 sec)

SQL文を見やすくすると、

select
  (
    select
      count(*)
    from
      product
  ) as 商品数,
  (
    select
      count(*)
    from
      shop
  ) as 店舗数;

SELECT文の項目がそれぞれExpressionなので、項目がSELECT文でもいいのですね。

SQL文をフォーマット

Mon, 07 Feb 2022 03:20:25 +0900

先日に作成した生SQL文の実行クエリの機能を使用しています。重宝していますが、SQL文が複雑になってくると括弧が多くなってきたりして、わかりづらくなってきます。PHPのコードやHTMLソースと同じようなもので、SQL文の整形の機能が必要です。探したらまさにそのパッケージありました。

まず、私が使用している機能とはこちらのことです。 SQL文を画面で入力して安全に実行して結果を返す

そこで掲載されているSQL文の例はごく簡単なのですが、例えばこんなのは、どうでしょう。

サブクエリーがあるし少々複雑。このSQL文にあるパッケージを適用すると、このようになります。

とても見やすい！

そのパッケージとは、以下のSQLフォーマッターです。

https://github.com/doctrine/sql-formatter

インストールはとても簡単。

$ composer require doctrine/sql-formatter

使用もとても簡単です。

...
use Doctrine\SqlFormatter\SqlFormatter;
...
class QueryController extends Controller
{
    /**
     * 表示
     *
     * @param  \App\Models\Query $query
     * @return \Illuminate\Contracts\View\View
     */
    public function show(Query $query)
    {
        $query->sql = (new SqlFormatter)->format($query->sql); // ここで整形

        return view('admin.query_show')
            ->with(compact('page', 'query'));
    }
...
}

表示では、先に掲載したようにSQL文の整形だけでなく、selectやfromなどのSQLのリザーブワードを太文字にするなどのシンタックスハイライトもしてくれます。また、SQL文が間違っているなら、赤文字で表示もしてくれます。以下は最後の閉める括弧が足りないときです。

HTMLタグを伴う出力が要らずに、SQL文の整形のみが必要なら（保存のときに便利）、

...
use Doctrine\SqlFormatter\NullHighlighter;
use Doctrine\SqlFormatter\SqlFormatter;
...
 echo (new SqlFormatter(new NullHighlighter()))->format($query->sql);
...

とコードします。その出力は以下のようになります。

select
  invoice_id,
  invoice_status,
  invoice_date
from
  invoice
where
  invoice_status = 5
  and invoice_date between '2019-01-01'
  and '2022-02-01'
  and invoice_id not in (
    select
      invoice.invoice_id
    from
      invoice_member
      inner join invoice on invoice_member.invoice_id = invoice.invoice_id
    where
      invoice_status = 5
      and invoice_date between '2019-01-01'
      and '2022-02-01'
  )

SQL文を画面で入力して安全に実行して結果を返す

Tue, 14 Dec 2021 07:46:54 +0900

Laravelのようなフレームワークが登場する以前は、誰しもSQL文を作成してmysqli_query()のような関数に引数として渡して実行していたものです。QueryBuilderやEloquentのORMなぞ聞いたこともない時代でした。その過去に戻るわけではないですが、それと同じこと、つまりSQL文を管理画面に直接入力して実行できないかと考えた次第です。

こんなものが欲しい

以下の画面のように、SQL文を入力してその実行ボタンを押すと結果を画面で表示してくれるものが欲しいのです。この画面では、テスト１とテスト２の２つサイトがあり、それぞれのサイトで使用されているDBに対してSQL文を実行しています。

なぜこのような機能が欲しいかというと、お客さんのビジネスでは今月の売り上げなどの定型のレポートだけでなく、例えば、ある時期にこの商品を購入したお客さんの中で何人が違う時期（最初の時期以降）で同じ商品を買ったのか、とかアドホックのリクエストが結構あるからです。

また、お客さんだけでなくシステム管理者は特定のDBテーブルのidの最大値が使用DBタイプの最大値に近づいていないか、など定期的に実行するクエリーも必要です。

しかし、これらのためにいちいち画面を伴うコントローラを作成するのは面倒であるし、そのときだけに必要で後には要らなくなることも多々です。それらのときに、上のようにカスタムのSQLを入力するだけで実行でき結果を見れる、さらにクエリと結果を保存し後に必要なときにも実行できる、としたら素晴らしいと思いませんか！

管理画面でSQL文を直接入力して実行するホラー

さて、欲しい機能は素晴らしいのだけれど、直接のSQL文入力・実行でホラーとなる状況はいくつかあります。特に以下の２点。

私の目的はあくまでもクエリーでありSELECTのSQL文だけの実行です。しかし、INSERTやUPDATEさらにDELETEもSQL文なので入力されて実行されたら、完全なホラーです。これらのSQL文が入力させないようにするか、入力しても実行を避ける方法が必要です。

次は、クエリーの実行時間がやたらに長くなりシステムの負荷となることです。入力するクエリーの実行に要する時間は、クエリーが複雑となると実行する前にわかるものではありません。もし、クエリーの実行時間が指定した実行所要時間以上となったら実行を自動的に打ち切りにしたいです。

ということで、これらを避ける対策を前もって考えます。

LaravelでどうSQL文を実行する？

ホラーの対策を考える前に、まず、LaravelでSQL文を実行してみましょう。tinkerで試してみます。

>>> DB::select("select count(*) as '会員数' from users");
=> [
     {#3514
       +"会員数": 2,
     },
   ]

簡単ですね。項目名にもUTF8なら日本語でエイリアスとできます。

しかし、恐ろしいのは先に述べたように、こういうこともできてしまいます。

>>> DB::select("delete from users");
=> []

>>> User::all();
=> Illuminate\Database\Eloquent\Collection {#3529
     all: [],
   }

DBテーブルは空になってしまいました。

DB更新のSQL文の実行を防ぐ

SQL文を簡単に実行できることがわかったところで、ホラーの対策を考えてみます。いくつかあります。

その１

簡単なのはSQL文にinsert, update, deleteなどが含まれていたら、プログラムで実行させない。preg_matchとか使用してバリデーションです。しかし、updated_atとかの項目がSQL文にあったら、それもマッチしてしまうので、updateの前後にスペースがあるかなどのマッチのパターンの調整が必要です。

その２

DBのユーザーを読み込み専用とする。これがベストですがいちいちそのために読み込み専用のDBユーザー作成する必要があります。ホストするプロバイダーによっては読み込み専用と読み書きのユーザーを分けて提供してくれるところもあります。.envあるいはconf/database.phpでの設定に工夫も必要となります。

その３

DBの読み込みセッションを使う。私が使用しているMySQL5.7では以下のようにたとえDBユーザーの権限に書き込みがあっても、以下のような読み込みセッションでDB更新の句クエリーを実行不可とできます。以下のDB::statement('SET SESSION TRANSACTION READ ONLY')の実行後は、レコード削除のSQL文のはエラーとなります。

>>> DB::select('select count(*) from users')
=> [
     {#3436
       +"count(*)": 1,
     },
   ]

>>> DB::statement('SET SESSION TRANSACTION READ ONLY')
=> true

>>> DB::select('delete from users')
Illuminate\Database\QueryException with message 'SQLSTATE[25006]: Read only sql transaction: 1792 Cannot execute statement in a READ ONLY transaction. (SQL: delete from users)'

>>> DB::select('select count(*) from users')
=> [
     {#3441
       +"count(*)": 1,
     },
   ]

クエリーの実行所有時間の制限

こちらは、DBセッションにおける最大実行時間を設定することで、制限をかけることが可能です。以下は、最大実行時間を1000ミリ秒、つまり１秒としました。２秒のスリープの実行では１秒を超えたときにエラーとなります。

>>> DB::statement('SET SESSION MAX_EXECUTION_TIME=1000')
=> true

>>> DB::select('select sleep(1) from users')
=> [
     {#3438
       +"sleep(1)": 0,
     },
   ]

>>> DB::select('select sleep(2) from users')
Illuminate\Database\QueryException with message 'SQLSTATE[HY000]: General error: 3024 Query execution was interrupted, maximum statement execution time exceeded (SQL: select sleep(2) from users)'

最後に

安全にクエリのSQL文の実行の仕方が解ったところで、実行したときにクエリーの実際の所有時間も知りたいですね。それは以下のように、前もってDB::listen()を実行すれば、実行後に取得できます。ここでも時間単位はミリ秒です。

>>> $time = 0
=> 0

>>> DB::listen(function($query) use (&$time) { $time = $query->time; })
=> null

>>> DB::select('select count(*) from users')
=> [
     {#3438
       +"count(*)": 1,
     },
   ]

>>> $time
=> 0.48

レプリカで気づいたタイムゾーンの問題

Sun, 30 Dec 2018 05:11:06 +0900

またまた、前回に引き続きMySQLのレプリカの話です。しかし、今回はLaravelの設定も関係してきます。

timestampのデータが非同期している

MySQLのデータタイプの１つに、timestampがあります。通常はレコードの作成や更新の日時の記録に使います。Laravelでは、Modelのクラスにおいて、デフォルトでcreated_atとupdated_atの項目がtimestampのデータタイプです。それらの項目が対応するDBテーブルにあるなら、

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Model;

class User extends Model
{
    public $timestamps = true; //デフォルト設定なので、この行は要らなくともよい
...

と設定しておけば、保存時にいちいち値をセットしなくとも自動にLaravelが面倒見てくれます。

しかし、レプリカの複製を使い始めて気づいたのは、timestampの項目のデータがマスターとレプリカが同期していないことです。

まず、マスターでtinkerを使用してレコードを更新します。

Psy Shell v0.9.3 (PHP 7.1.23 — cli) by Justin Hileman
>>> $user = User::find(1);
[!] Aliasing 'User' to 'App\User' for this Tinker session.
=> App\User {#2309
     id: 1,
     name: "山田太郎",
     email: "test@lotsofbytes.com",
     created_at: "2017-01-19 04:57:48",
     updated_at: "2018-11-08 05:05:24",
   }
>>> $user->update(['name' => 'John Doe']);
=> true
>>> $user = User::find(1);
=> App\User {#2314
     id: 1,
     name: "John Doe",
     email: "test@lotsofbytes.com",
     created_at: "2017-01-19 04:57:48",
     updated_at: "2018-12-30 03:28:42",
   }

nameとupdated_atが変更されていますね。ここで、pt-table-checksumを実行すると、usersのテーブルでマスターとレプリカで値が異なることが報告されるのです。

Checking if all tables can be checksummed ...
Starting checksum ...
            TS ERRORS  DIFFS     ROWS  DIFF_ROWS  CHUNKS SKIPPED    TIME TABLE
12-30T03:30:31      0      0        2          0       1       0   1.020 larajapan.migrations
12-30T03:30:31      0      0        1          0       1       0   0.021 larajapan.password_resets
12-30T03:30:31      0      1        5          0       1       0   0.017 larajapan.users

謎です。

謎をひも解く

いろいろと探ってみると、知っておくべきなのに知らなかったことがぽろぽろと出てきました。

まず、知らなかったこと、その１として、

timestampのデータタイプの項目では、値が入るとUTCの時間に変更されて保存される。

例えば、MySQLのセッションが日本のタイムゾーンなら、

created_atの項目に、2018-12-30 03:00:00と入れれば、2018-12-29 18:00:00とＤＢに保存されます。日本のタイムゾーンは、UTCより9時間先です（この時間差を理解するには、このサイト https://www.worldtimebuddy.com/japan-tokyo-to-utcチェックしてみてください）。

そして、SELECTでこの値を引き出すときは、そのときのセッションのタイムゾーンに変換してMySQLは出力します。つまり、同じ時間を世界のどのタイムゾーンに合わせて表示が可能なわけです。

次に、知らなかったこと、その2は、

MySQLのセッションのタイムゾーンは、DBを使用するアプリで指定していないなら、アプリをホストするサーバーの設定となる。

使用しているサーバーはAWSのEC2で、そこでインストールしたMySQLのサーバーでは、特別に設定しない限り、SYSTEMつまりサーバーのシステムのタイムゾーンの設定となります。

マスターのタイムゾーンをチェックしてみると、

mysql>  SELECT @@SESSION.time_zone, @@GLOBAL.system_time_zone;
+---------------------+---------------------------+
| @@SESSION.time_zone | @@GLOBAL.system_time_zone |
+---------------------+---------------------------+
| SYSTEM              | JST                       |
+---------------------+---------------------------+

で、このSYSTEMはマシンのOSが設定するタイムゾーンJST(Japan Standard Time)になります。

さて、AWS RDSのレプリカの方は、

mysql>  SELECT @@SESSION.time_zone, @@GLOBAL.system_time_zone;
+---------------------+---------------------------+
| @@SESSION.time_zone | @@GLOBAL.system_time_zone |
+---------------------+---------------------------+
| UTC                 | UTC                       |
+---------------------+---------------------------+

もしかして、この違いが問題？

実際どんなログがレプリカで受け取られているのでしょう。MySQLが作成しているログファイルを読んでみましょう。

ログを読むには、mysqlbinlogを使用します。

$ mysqlbinlog --no-defaults -v mysql-bin.000004

この出力から、先ほどのtinkerで実行したSQLを探します。

...
# at 35339
#181230  3:28:42 server id 1  end_log_pos 35420     Query   thread_id=492197    exec_time=0 error_code=0
SET TIMESTAMP=1546108122/*!*/;
SET @@session.sql_mode=1436549152/*!*/;
/*!\C utf8mb4 *//*!*/;
SET @@session.character_set_client=224,@@session.collation_connection=224,@@session.collation_server=8/*!*/;
SET @@session.time_zone='SYSTEM'/*!*/;
BEGIN
/*!*/;
# at 35420
#181230  3:28:42 server id 1  end_log_pos 35587     Query   thread_id=492197    exec_time=0 error_code=0
SET TIMESTAMP=1546108122/*!*/;
update `users` set `name` = 'John Doe', `updated_at` = '2018-12-30 03:28:42' where `id` = 1
/*!*/;
...

updateのSQL文ありましたね！そして、その前に実行されている、SET @@session.time_zone=‘SYSTEM’は、タイムゾーンをSYSTEMと設定しています。つまり、レプリカがこのログを受け取り実行するときに、タイムゾーンをSYSTEMとセットしてからレプリカのレコードを更新します。しかし、レプリカにとってはSYSTEMはマスターと違って、JSTではなくUTCです。日本時間をUTCに変更することなく更新しているのです。それゆえに、pt-table-checksumの実行では非同期となるわけです。

非同期の解決方法

非同期の理由がわかったら、この非同期を解決するのは簡単です。マスターにおいて、タイムゾーンをSYSTEMではなく、Asia/Tokyoを使うようにすればよいだけです（私の環境では、MySQLではJSTの設定ではエラーとなりました。多分にJSTはOSが返す値？）。

サーバーでのアプリがすべて日本時間帯なら、/etc/my.cnfで設定可能です。しかし、my.cnfが編集できない共有ホストの環境、あるいは同じサーバーに違うタイムゾーン向けのアプリがあるなら、使用するアプリでの設定がベストです。

Laravelのプロジェクトでの設定は簡単で、config/database.phpで以下のようにtimezoneの行を追加します。

config/database.php

...
    'connections' => [
        'mysql' => [
            'driver' => 'mysql',
            'host' => env('DB_HOST', '127.0.0.1'),
            'port' => env('DB_PORT', '3306'),
            'database' => env('DB_DATABASE', 'forge'),
            'username' => env('DB_USERNAME', 'forge'),
            'password' => env('DB_PASSWORD', ''),
            'unix_socket' => env('DB_SOCKET', ''),
            'charset' => 'utf8mb4',
            'collation' => 'utf8mb4_unicode_ci',
            'prefix' => '',
            'strict' => true,
            'engine' => null,
            'timezone' => 'Asia/Tokyo'
        ],
...

tinkerで確認して、前回非同期となったレコードを再度更新します。

Psy Shell v0.9.3 (PHP 7.1.23 — cli) by Justin Hileman
>>> DB::select(DB::raw("SELECT @@SESSION.time_zone, @@GLOBAL.system_time_zone"));
=> [
     {#2316
       +"@@SESSION.time_zone": "Asia/Tokyo",
       +"@@GLOBAL.system_time_zone": "JST",
     },
   ]
>>> $user = User::find(1);
[!] Aliasing 'User' to 'App\User' for this Tinker session.
=> App\User {#2307
     id: 1,
     name: "John Doe",
     email: "test@lotsofbytes.com",
     created_at: "2017-01-19 04:57:48",
     updated_at: "2018-12-30 03:28:42",
   }
>>> $user->update(['name' => 'Tarou Yamada']);
=> true
>>> $user = User::find(1);
=> App\User {#2309
     id: 1,
     name: "Tarou Yamada",
     email: "test@lotsofbytes.com",
     created_at: "2017-01-19 04:57:48",
     updated_at: "2018-12-30 04:50:48",
   }

pt-table-checksumを実行すると、結果は、差分なし！

Checking if all tables can be checksummed ...
Starting checksum ...
            TS ERRORS  DIFFS     ROWS  DIFF_ROWS  CHUNKS SKIPPED    TIME TABLE
12-30T04:51:09      0      0        2          0       1       0   0.019 larajapan.migrations
12-30T04:51:09      0      0        1          0       1       0   0.017 larajapan.password_resets
12-30T04:51:09      0      0        5          0       1       0   0.017 larajapan.users

最後に、MySQLのログを見てみます。タイムゾーンは、正しくAsia/Tokyoの設定となっていますね。

# at 38550
#181230  4:50:48 server id 1  end_log_pos 38635     Query   thread_id=492757    exec_time=0 error_code=0
SET TIMESTAMP=1546113048/*!*/;
SET @@session.sql_mode=1436549152/*!*/;
/*!\C utf8mb4 *//*!*/;
SET @@session.character_set_client=224,@@session.collation_connection=224,@@session.collation_server=8/*!*/;
SET @@session.time_zone='Asia/Tokyo'/*!*/;
BEGIN
/*!*/;
# at 38635
#181230  4:50:48 server id 1  end_log_pos 38810     Query   thread_id=492757    exec_time=0 error_code=0
SET TIMESTAMP=1546113048/*!*/;
update `users` set `name` = 'Tarou Yamada', `updated_at` = '2018-12-30 04:50:48' where `id` = 1
/*!*/;

MySQLレプリカの同期チェック

Sat, 10 Nov 2018 01:56:48 +0900

今回は以前話した、MySQLデータベースのレプリカの話の続きです。

前回はデータベースのレプリカの説明をしましたが、本当にマスターのデータベースと同期しているの？とすぐに疑います。チェックしてみましょう！

調べると、checksum tableというMySQLコマンドが使えるらしい。チェックサムはある計算式をデータに適用してユニークな数を出力するものです。

mysql> use larajapan;
Database changed
mysql> checksum table migrations, password_resets, users;
+---------------------------+------------+
| Table                     | Checksum   |
+---------------------------+------------+
| larajapan.migrations      |  269719583 |
| larajapan.password_resets | 3233767743 |
| larajapan.users           |  669472749 |
+---------------------------+------------+
3 rows in set (0.00 sec)

実行してみるとかなりな速さで結果を出してくれます。私のテストでは500万レコード数もあるテーブルでたったの16秒！

これを、マスターとそのレプリカで、すべてのテーブルに対して実行して比較すれば良いですね。しかし、実際に使用されているDBでは、常に新しいレコードは追加される、更新はある。。。と考えると、ある1時点で両者のデータを比較するのは複雑な作業に見えてきます。

そこで見つけたのが、perconaのツール。perconaはかなり昔からMySQLなどのオープンソースのデータベースの管理をサービスとしている会社です。

準備

AWS EC2では、以下でインストールできます。

$ sudo yum install http://www.percona.com/downloads/percona-release/redhat/0.1-6/percona-release-0.1-6.noarch.rpm

たくさんのツール（perlで書かれている）がインストールされますが、今回必要なツールはマスターとレプリカのデータの同期をチェックする以下のコマンドです。

pt-table-checksum

しかし、このツール、オプションがたくさんあり、ある程度の準備も要る複雑なツールです。私も理解まで何回も何回も試行しました。特に、マスターのDBとレプリカのDBで、MySQLのユーザー名やパスワードが違うとその指定のためにコマンドラインが長くなり、実行にはスクリプトの作成をした方が良いです。

ちなみに、今回は、以前と同様に、マスターはEC2でのMySQL、レプリカは、AWSのRDSのMySQLという仮定です。もちろんレプリカのサーバーにはsshできないので、マスターで実行します。

準備として、以下のMySQLの情報を用意してください。

マスターのユーザー名マスターのパスワードレプリカのユーザー名レプリカのパスワード

マスターやレプリカのMySQLユーザーは以下の権限が必要ですが、以下のように特別に作成しなくとも、通常はrootのような管理権限のあるユーザーで足ります。

mysql> GRANT SELECT ON larajapan.* TO 'checksum_user'@'%' IDENTIFIED BY 'checksum_password';
mysql> GRANT REPLICATION SLAVE,PROCESS,SUPER ON *.* TO `checksum_user`@'%';
mysql> GRANT ALL PRIVILEGES ON percona.* TO `checksum_user`@'%';

次に、ツールが出力するデータを保存するためのデータベース（percona）とテーブル（checksums）を作成します。

mysql> create databaser percona;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'databaser percona' at line 1
mysql> create database percona;
Query OK, 1 row affected (0.00 sec)

mysql> use percona
Database changed
mysql> CREATE TABLE checksums ( db CHAR(64) NOT NULL, tbl CHAR(64) NOT NULL, chunk INT NOT NULL, chunk_time FLOAT NULL, chunk_index VARCHAR(200) NULL, lower_boundary TEXT NULL, upper_boundary TEXT NULL, this_crc CHAR(40) NOT NULL, this_cnt INT NOT NULL, master_crc CHAR(40) NULL, master_cnt INT NULL, ts TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (db, tbl, chunk), INDEX ts_db_tbl (ts, db, tbl) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Query OK, 0 rows affected (0.01 sec)

マスターとレプリカの両方で作成が必要ですが、ツールの最初の実行でマスターでは自動的に作成されます。

実行

ここで、まず実行してみましょう。運が良ければここで以下のような出力となります。

$ pt-table-checksum -d larajapan -u checksum_user -p checksum_password --recursion-method processlist --no-check-binlog-format --no-check-replication-filters
Checking if all tables can be checksummed ...
Starting checksum ...
            TS ERRORS  DIFFS     ROWS  DIFF_ROWS  CHUNKS SKIPPED    TIME TABLE
11-09T07:54:37      0      0        2          0       1       0   1.019 larajapan.migrations
11-09T07:54:37      0      0        1          0       1       0   0.017 larajapan.password_resets
11-09T07:54:37      0      0        5          0       1       0   0.014 larajapan.users

ERRORSとDIFFSの列、これが皆ゼロならマスターとレプリカは同期しています。心配なしです。

さて、どうしてレプリカのホスト情報をコマンドラインに入れていないのにレプリカのチェックが可能なのでしょう？

それは、–recursion-method processlistの部分です（デフォルトでは、ここはprocesslist, hostsとなるのですが、私のトライではhostsの部分でエラーになりました)。

MySQLのshow processlistコマンドを実行すると、

mysql> show processlist;
+-----+------------+-----------------------------------------------+--------------+-------------+-------+-----------------------------------------------------------------------+------------------+
| Id  | User       | Host                                          | db           | Command     | Time  | State                                                                 | Info             |
+-----+------------+-----------------------------------------------+--------------+-------------+-------+-----------------------------------------------------------------------+------------------+
|   2 | slave_user | ip-10-0-1-32.us-west-2.compute.internal:64617 | NULL         | Binlog Dump | 14651 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL             |
| 918 | root       | localhost                                     | NULL         | Query       |     0 | NULL                                                                  | show processlist |
| 919 | root       | localhost                                     | larajapan_wp | Sleep       |     0 |                                                                       | NULL             |
+-----+------------+-----------------------------------------------+--------------+-------------+-------+-----------------------------------------------------------------------+------------------+
3 rows in set (0.00 sec)

レプリカのホスト情報が出て来るのでそれを利用しているのです。

また、ここでは、レプリカでのMySQLのユーザー名とパスワードは、マスターと同じと仮定しています。これが違うなら、

–slave-user admin –slave-password pass

の指定がコマンドラインで必要となります。

本当にチェックしている？

ひとまず成功したところで、本当に差分を出してくれるか興味あるところです。レプリカにおいて、情報変えてみましょう。

mysql> delete from users where id = 6;
Query OK, 1 row affected (0.01 sec)

レプリカのusersのテーブルのレコードを１つ削除しました。

そして再度実行です。

$ pt-table-checksum -d larajapan -u checksum_user -p checksum_password --recursion-method processlist --no-check-binlog-format --no-check-replication-filters
Checking if all tables can be checksummed ...
Starting checksum ...
            TS ERRORS  DIFFS     ROWS  DIFF_ROWS  CHUNKS SKIPPED    TIME TABLE
11-09T08:18:43      0      0        2          0       1       0   0.021 larajapan.migrations
11-09T08:18:43      0      0        1          0       1       0   0.017 larajapan.password_resets
11-09T08:18:43      0      1        5          0       1       0   0.019 larajapan.users

チェックしてくれましたね。DIFFSに1が表示されているのがそうです。

デバッグ

このコマンドラインでは、本当にたくさんのオプションがあるのでいろいろなチェックが可能なのですが、エラーが理解不可能なときは、以下のようにデバッグモードを使ってみるのが良いです。stderrに情報がたくさん出力されるので以下のようにファイルにキャプチャする必要あります。

$ PTDEBUG=1pt-table-checksum > FILE 2>&1

また、オプションのデフォルトも把握することも大事です。

$ pt-table-checksum --help

の実行でデフォルトの情報が得られます。