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()とは出来ないことに注意を。

ユニットテストの超高速化

Wed, 17 Jul 2024 11:26:20 +0900

長年管理しているお客さんのプロジェクトのユニットテスの数が増えてきました。Featureテストも含めてテストケースの数は2,400以上あります。私の古めのWindowsのマシン（i7-9700CPU @ 3.00GHz）のWSL2環境では、7分51秒かかります。今回はこのテスト実行所有時間をほぼ1/10の50秒以下に縮めた話です。

mysqlをメモリー内で実行

DBを使用するテストが多いので最初に考えたのは、使用しているmysqlサーバーのエンジンをInnoDBからMemoryとすることです。しかしこれはすぐに不可能とわかりました。MemoryのエンジンではTEXTのデータタイプを対応していないからです。

どうしたらよいかといろいろ調査すると、mysqlのDBを保存しているボリュームをハードディスクのストレージからtmpfsに変えれば良いらしい。tmpfsは以下に説明されるようにメモリに存在するファイルシステムです。 tmpfsとは

しかし、ローカル環境（WSL2）で実行されているmysqlサーバーをtmpfsで走らせるとなると、mysqlサーバーがいろいろなプロジェクトで共有されているためにとても不都合であるし、マシンを落としたらそれでDB内のデータは消えてしまうとなるともっと困ります。

ということで、sailを使用してdocker内でmysqlサーバーをtmpfsで実行するのが理想となりました。

sailのセットアップに関してはここでは説明しませんが、セットアップの産物としてdocker-compose.ymlが作成されます。

このdocker-compose.ymlのmysqlサーバーの定義において、以下のようにvolumesのsail-mysqlをコメントアウトして、tmpfsを追加します。

...
    mysql:
        image: 'mysql/mysql-server:8.0'
        ports:
            - '${FORWARD_DB_PORT:-3306}:3306'
        environment:
            MYSQL_ROOT_PASSWORD: '${DB_PASSWORD}'
            MYSQL_ROOT_HOST: '%'
            MYSQL_DATABASE: '${DB_DATABASE}'
            MYSQL_USER: '${DB_USERNAME}'
            MYSQL_PASSWORD: '${DB_PASSWORD}'
            MYSQL_ALLOW_EMPTY_PASSWORD: 1
        volumes:
            # - 'sail-mysql:/var/lib/mysql' # コメントアウト！
            - './vendor/laravel/sail/database/mysql/create-testing-database.sh:/docker-entrypoint-initdb.d/10-create-testing-database.sh'
        tmpfs: # ここを追加！
            - /var/lib/mysql
        networks:
            - sail
        healthcheck:
            test:
                - CMD
                - mysqladmin
                - ping
                - '-p${DB_PASSWORD}'
            retries: 3
            timeout: 5s
...

以下を実行して、

$ sail up

dockerを立ち上げて、docker内のmysqlサーバーのファイルシステムを見ると、

sh-4.4# df -h
Filesystem      Size  Used Avail Use% Mounted on
overlay         251G   26G  213G  11% /
tmpfs            64M     0   64M   0% /dev
tmpfs           7.8G     0  7.8G   0% /sys/fs/cgroup
shm              64M     0   64M   0% /dev/shm
/dev/sdd        251G   25G  214G  11% /docker-entrypoint-initdb.d/10-create-testing-database.sh
/dev/sde        251G   26G  213G  11% /etc/hosts
tmpfs           7.8G  199M  7.6G   3% /var/lib/mysql
tmpfs           7.8G     0  7.8G   0% /proc/acpi
tmpfs           7.8G     0  7.8G   0% /sys/firmware

/var/lib/mysqlがtmpfsとなっていますね。

テストを実行してみましょう。

$ sail artisan test

テスト実行の所有時間は、7分51秒から219秒から3分39秒と一気に半分以下となりました。

並行処理でテストを実行

今度は、パラレルテストを利用してもっと高速化してみましょう。

まず、必要なライブラリをインストールします。

$ sail composer require brianium/paratest --dev

その後、パラレルテストを実行します。

$ sail artisan test --parallel

tmpfsとパラレルを組み合わせたテスト実行となり、その結果、所有時間は驚異の49秒となりました。ほぼ1/10の時間です。

Docker内のmysqlサーバーでデータベースを閲覧すると、以下のように、testingのデータベース７個新たに作成ｓれて、計８個となっています。これは私のマシンが８コアのためです。パラレルテストは使用のマシンのコア数でデータベースの数が決まります。

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| laravel            |
| mysql              |
| performance_schema |
| sys                |
| testing            |
| testing_test_1     |
| testing_test_2     |
| testing_test_3     |
| testing_test_4     |
| testing_test_5     |
| testing_test_6     |
| testing_test_7     |
+--------------------+

ちなみに、tmpfsなしのパラレルテストの所要時間は、5分28秒でした。tmpfs + parallelが最速のチームということですね。

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';
    }
}

うるう年の日の１年後あるいは１年前の計算いろいろ

Sat, 11 Feb 2023 05:17:54 +0900

１年と言っても必ずしも365日とはならないです。４年に１回のうるう年は366日となります。さて、この１年というあいまいな定義をデータベースのSQLあるいはプログラムで計算するとどういう結果になるかという話です。

SQLで計算

こういうときは、もちろんtinkerを使います。一番最近のうるう年の2020-02-29を起点として、まずDBでの１年後の計算。

> DB::select(DB::raw('select DATE_ADD("2020-02-29", INTERVAL 1 YEAR)'));
= [
    {#30074
      +"DATE_ADD("2020-02-29", INTERVAL 1 YEAR)": "2021-02-28",
    },
  ]

１年の代わりに365日を足しても同じです。

> DB::select(DB::raw('select DATE_ADD("2020-02-29", INTERVAL 365 DAY)'));
= [
    {#30059
      +"DATE_ADD("2020-02-29", INTERVAL 365 DAY)": "2021-02-28",
    },
  ]

今度は引き算で１年前の計算。

> DB::select(DB::raw('select DATE_SUB("2020-02-29", INTERVAL 1 YEAR)'));
= [
    {#30062
      +"DATE_SUB("2020-02-29", INTERVAL 1 YEAR)": "2019-02-28",
    },
  ]

１年の代わりに、365日を引くと、

> DB::select(DB::raw('select DATE_SUB("2020-02-29", INTERVAL 365 DAY)'));
= [
    {#30090
      +"DATE_SUB("2020-02-29", INTERVAL 365 DAY)": "2019-03-01",
    },
  ]

１日分の差が出ました。最初のは２月の最後から１年前の２月の最後という計算ですね。

※ちなみにこれはmysqlの結果です。

phpの関数で計算

今度は、Carbonを使用して計算です。

> use Carbon\Carbon;
> Carbon::parse('2020-02-29')->addYear(1)->format('Y-m-d');
= "2021-03-01"

あれ、365日計算でないですね。

> Carbon::parse('2020-02-29')->addDays(366)->format('Y-m-d');
= "2021-03-01"

366日の計算です。

今度は引き算で１年前の計算。

> Carbon::parse('2020-02-29')->subYear(1)->format('Y-m-d');
= "2019-03-01"

むむ。今度は365日の計算となりました。

> Carbon::parse('2020-02-29')->subDays(365)->format('Y-m-d');
= "2019-03-01"

【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()がベターと考えてそちらを採用することにしました。

DBテーブルをjoinして値を更新

Sun, 16 Oct 2022 11:57:03 +0900

これまた、データベースの話ですが、長期でアクティブに管理しているプロジェクトでは必ず登場してくる作業です。

どういうときに必要？

例えば、以下のようなデータの会員テーブル(users)があります。

id	name	rank
1	高橋美加子	A
2	浜田太一	B
3	中島充	A
4	渚あすか	B
5	渚和也	A

最後の項目は、会員ランクで過去２年間に会員が購入した商品の送金額により会員ランクが決まります。会員ランクには、ＡとＢの２つあり、会員ランクＡの会員は、購入の際に5%の割引があるなどの恩恵があります。Ｂランクの会員は残念ながら恩恵なしです。

さて、会員数も増えてきて、Ａランク会員が多すぎて購入額の総額も同じランクでばらつきがあることから、ランクを１つ増やすことにします。つまり、今度はＡ，Ｂ，Ｃと３つのランクとなります。

もちろん、Artisanコマンドを作成して新たなランク計算式を使い、usersのそれぞれのレコードを更新することも可能ですね。こんな感じで。

User::all()->each(function($user) {
    $user->rank = $user->calcNewRank();
    $user->save();
})

しかし、これではもとのランクの値がなんであったか残りません。更新前に、usersのテーブルをdumpしてファイルとして残してもよいですが、もしかしたら、移行後にも旧のランク値はクレームときのために必要かもしれません。

値の移行のためのテーブルを新規に作成

このようなときは、まず、一時的に使用するテーブルを作成して、そこでusersのそれぞれのレコードに対応する旧と新のランクをあらかじめレコードを作成します。テーブル名は、change_rankとして以下のようなデータとなります。

user_id	name	old_rank	new_rank
1	高橋美加子	A	A
2	浜田太一	B	C
3	中島充	A	B
4	渚あすか	B	C
5	渚和也	A	B

change_rankのテーブルとusersのテーブルは、両者のプライマリーキー(users.idとchange_rank.user_id)を介してまったく１対１の関係となり、後の一括更新に使用されます。さらに、この移行のテーブルを残しておけば、旧と新のランク値のスナップショットとなり、何かのときにとても有用なものとなります。

一括更新

通常更新は、１つのテーブルにおいて、例えば以下のように更新します。

UPDATE users SET rank = 'A';

しかし、今回のケースは２つのテーブルが関わる、つまり１つのテーブルの値をもとにもう１つのテーブルの値の更新となるので、joinが必要となります。SQL文では以下のようになります。

UPDATE users
INNER JOIN change_rank ON users.id = change_rank.user_id
SET user.rank = change_rank.new_rank;

さて、これをSQL文でなく、クエリビルダーで行うなら、以下のようなコードとなります。

DB::table('users')
    ->join('change_rank', 'users.id', '=', 'change_rank.user_id')
    ->update(['users.rank' => DB::raw('change_rank.new_rank')]);

ここ以下のように書いてしまいそうですが、DB::raw()がないとエラーとなるので注意を。

DB::table('users')
    ->join('change_rank', 'users.id', '=', 'change_rank.user_id')
    ->update(['users.rank' => change_rank.new_rank]);

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文でもいいのですね。

whereInが返す順番

Mon, 23 May 2022 04:08:20 +0900

whereIn()はLaravelではEloquentやQuery Builderで良く使われます。特にwith()メソッドでは自動的に。今までこのクエリが返すレコードの順番はたいして気にしていなかったのですが、これはどうしたものか、という状況にぶち当たりました。

SQLというのは何も指定しない、つまりorderByを指定しないとSQLが返すレコードの順番は保証がありません。以下見てください。

>>> User::whereIn('id', [10,1,3])->pluck('id');

=> Illuminate\Support\Collection {#4581
     all: [
       1,
       3,
       10,
     ],
   }

直感的には、10,1,3を返すと思うところ、なぜかその順番にソートされていません。自動的にid順となっています。多分、idがDBテーブルusersのプライマリーキーだから、その順で返している？

とにかく、orderByを明確に指定していないので返す順を頼りにすることはできません。

しかし、状況によっては指定した順番で返す必要あります。以下のように、お客さんが閲覧した商品の順番、最新閲覧した商品を一番左に持ってきます。

例えば、この商品のidがクッキーにその表示順でidを保存した場合は、その表示順で商品名や価格をDBから取得してくる必要あります。

この場合は、一般的はDBの項目の値に基づくorderByは使えません（もちろん、閲覧日時とかを別のDBテーブルに保存していないという仮定で）。

さて、どうしましょう？とリサーチすると便利なSQL関数がありました。こんな感じで使います。

>>> User::whereIn('id', [10,1,3])->orderByRaw("FIELD(id,10,1,3)")->pluck('id');

=> Illuminate\Support\Collection {#4579
     all: [
       10,
       1,
       3,
     ],
   }

そして、これを先の商品の例に適応すると、こんな感じです。$productIdsには配列として、例えば[10,1,3]のような値があると仮定します。

Product::query()
    ->whereIn('product_id', $productIds)
    ->orderByRaw('FIELD(product_id, '.implode(',', $productIds).')')
    ->pluck('name', 'product_id');

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

bulk insertをtransaction処理にする

Sat, 19 Jun 2021 03:00:16 +0900

以前投稿したbulk insertで大量のデータをDBに登録するの記事では10万レコードの挿入をbulk insertで行い、通常のinsertと比べてどれだけ速くなるのか検証しました。結果は一目瞭然で、大量のレコードをDBに登録する際には強力な武器になる事が分かりました。

しかし、前回のコードを実際の運用で使うには１つ問題があります。それはbulk insertの途中でエラーが発生した場合、DBに中途半端にレコードが残ってしまうという問題です。今回はこの問題を解決するために、前回のコードをtransactionに入れ、エラーが発生した際にロールバックされるように改修します。そして、transaction処理にする事でパフォーマンスにどのような影響があるか検証してみます。

エラー発生時の挙動

改修を始める前にまずは途中でエラーが発生し処理が異常終了してしまった場合の挙動を確認してみましょう。前回の記事で作成したUsersSeederを以下のように編集し、9999件目のレコード挿入でわざと重複エラーを発生させてみましょう。

database/seeds/UsersSeeder.php

use App\User;
use Faker\Factory as Faker;
use Illuminate\Database\Seeder;

class UsersSeeder extends Seeder
{
    /**
     * Run the database seeds.
     *
     * @return void
     */
    public function run()
    {
        $faker = Faker::create('ja_JP');

        $params = [];

        for ($i=0; $i < 100000; $i++) {
            $email = "test{$i}@example.com"; 

            // 9999件目でemailが重複
            if ($i == 9999) {
                $email = "test1@example.com";
            }

            $params[] = [ 
                'name' => $faker->name(),
                'email' => $email,
                'password' => 'testtest',
            ];

            if (count($params) >= 1000) {
                User::insert($params);
                $params = [];
            }
        }
    }
}

seederを実行すると以下のように重複エラーが発生するはずです。

% php artisan db:seed
Seeding: UsersSeeder

   Illuminate\Database\QueryException  : SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'test1@example.com' for key 'users_email_unique' (SQL: insert into `users` (`email`, `name`, `password`) values ...

この時点でDB上のレコード件数を確認してみると。。。

mysql> select count(*) from users;
+----------+
| count(*) |
+----------+
|     9000 |
+----------+
1 row in set (0.01 sec)

9999件目でエラーが発生し、処理がabortされたので最後の999件は登録されませんでしたが、それまでの9000件のレコードが登録されたままの中途半端な状態になっています。前回の記事ではseederの実行前にtruncateメソッドを実行し、テーブルを空にしていたため、再度seederを実行しても問題ありませんでした。しかし、エラーにより処理が途中で強制終了されたのであれば、失敗した中途半端な状態は残さず、実行前の状態に戻るのが望ましいです。

transaction処理の実装

それではtransaction処理を実装し、エラー発生時にロールバックするように修正してみましょう。Laravelでは以下のようにDBファサードを使うとtransaction処理が簡単に実装できます。

// transaction開始
DB::beginTransaction();

try {

    // 何かしらのDB操作...

    // transactionコミット
    DB::commit();
} catch (\Throwable $th) {

    // ロールバック
    DB::rollBack();
}

修正を加えたコードが以下になります。

database/seeds/UsersSeeder.php

use App\User;
use Faker\Factory as Faker;
use Illuminate\Database\Seeder;
use Illuminate\Support\Facades\DB;

class UsersSeeder extends Seeder
{
    /**
     * Run the database seeds.
     *
     * @return void
     */
    public function run()
    {
        DB::beginTransaction();

        try {
            $this->insertDummies();

            DB::commit();
        } catch (\Throwable $th) {
            DB::rollBack();

            throw new Exception('failed seeding User, so rolled back.');
        }
    }

    private function insertDummies()
    {
        $faker = Faker::create('ja_JP');

        $params = [];

        for ($i=0; $i < 100000; $i++) {

            $email = "test{$i}@example.com";

            // 9999件目でemailが重複
            if ($i == 9999) {
                $email = "test1@example.com";
            }

            $params[] = [
                'name'  => $faker->name(),
                'email' => $email,
                'password' => 'testtest',
            ];

            if (count($params) >= 1000) {
                User::insert($params);
                $params = [];
            }
        }
    }
}

runメソッドが冗長になってしまう為、レコード作成処理をinsertDummiesメソッドに切り出しました。レコード作成処理の途中でエラーが発生した場合はDB::rollback()によってinsertDummiesメソッド実行前に巻き戻されるはずです。

再度、seederを実行してみましょう。

% php artisan db:seed
Seeding: UsersSeeder

   Exception  : failed seeding User, so rolled back.
...

Errorが発生し期待通りロールバックされました。DB側を確認してみましょう。

mysql> select count(*) from users;
+----------+
| count(*) |
+----------+
|        0 |
+----------+
1 row in set (0.00 sec)

実行前の状態に戻されていますね。

処理速度に影響は？

通常のinsert処理からbulk insertに切り替える事の最大のメリットはその速さでしたが、transaction処理に切り替える事で何か影響は在るでしょうか？チェックしてみましょう。

insertDummiesメソッド内のエラーを発生させていた以下の行を削除し、正常終了するように直します。

database/seeds/UsersSeeder.php

...
            // 9999件目でemailが重複
            if ($i == 9999) {
                $email = "test1@example.com";
            }
...

再度、seederを実行してみましょう。

% php artisan db:seed
Seeding: UsersSeeder
Seeded:  UsersSeeder (6.87 seconds)
Database seeding completed successfully.

約6.9秒、transaction無しの状態で約5.8秒だったので約１秒遅くなりましたが、気にするほどでは無さそうですね。

bulk insertで大量のデータをDBに登録する

Mon, 03 May 2021 01:55:23 +0900

毎日走らせているcronのジョブの１つが、なかなか時間が掛かるのでどうにか改善できないかと悩んでいました。DBへデータを挿入する箇所で時間が掛かっており、コードを確認するとforループで１レコードずつinsert処理を行っていました。bulk insertするように改修したところ、劇的に処理時間が短くなりました。今回はそんな妙薬、bulk insertについてです。

Bulk insertとは？

bulk insertとはDBにレコードを保存する際に、複数のレコードを１クエリでまとめて挿入する方法です。１レコードずつクエリを発行するよりも効率的で高速です。

Laravelでは以下のようにクエリビルダのinsertメソッドを使い実装します。

DB::table('users')->insert([
    ['name' => 'John', 'email' => 'john@example.com', 'password' => 'testtest'],
    ['name' => 'Ben', 'email' => 'ben@example.com', 'password' => 'testtest'],
    ['name' => 'Tyler', 'email' => 'tyler@example.com', 'password' => 'testtest'],
]);

１レコードずつ挿入した場合とbulk insertを使った場合でどれ位処理時間が異なるのでしょうか？seederでusersテーブルに10万件のダミーレコードを登録するケースで比較してみます。

１レコードずつinsertする場合

※Laravelインストール後、DB接続設定やmigration実行完了時点の状態から進めています。

まずはseederを用意します。以下のコマンドでUsersSeederを作成してください。

php artisan make:seeder UsersSeeder

作成されたUsersSeederクラスを以下の様に編集します。

database/seeds/UsersSeeder.php

use App\User;
use Faker\Factory as Faker;
use Illuminate\Database\Seeder;
use Illuminate\Support\Facades\Hash;

class UsersSeeder extends Seeder
{
    /**
     * Run the database seeds.
     *
     * @return void
     */
    public function run()
    {
        $faker = Faker::create('ja_JP');

        for ($i=0; $i < 100000; $i++) { 
            $param = [ 
                'name' => $faker->name(),
                'email' => "test{$i}@example.com",
                'password' => 'testtest',
            ];
            User::create($param);
        }
    }
}

上記のコードではforループ内でcreateメソッドを呼んでおり、10万回ループ毎にDBにレコードが挿入されます。

emailにはループカウンターの$iが使用されています、これはusersテーブルに挿入する際にemailがユニークである必要があるためです。fakerのuniqueメソッドを使えばユニークなemailを生成することが出来ますが、10万件となると重複が発生し失敗してしまいます。

seederを追加したら以下のコマンドでcomposerのオートローダを再生成し、UsersSeederが読み込まれるようにしましょう。

$ composer dump-autoload

DatabaseSeeder.php も編集し、db:seedでUsersSeederを呼び出すようにします。コマンド実行毎にusersテーブルをtruncateメソッドで初期化し、挿入するemailが重複しないようにしています。

database/seeds/DatabaseSeeder.php

use Illuminate\Database\Seeder;
use Illuminate\Support\Facades\DB;

class DatabaseSeeder extends Seeder
{
    /**
     * Seed the application's database. 
     * 
     * @return void 
     */ 
    public function run()
    { 
        DB::table('users')->truncate();
        $this->call(UsersSeeder::class);
    }
}

これで準備が出来ました、db:seedコマンドを実行してみましょう。

$ php artisan db:seed
Seeding: UsersSeeder
Seeded: UsersSeeder (157.48 seconds)
Database seeding completed successfully.

上記はM1 MacBookAirでの実行で、約２分半掛かりました。また、Windows + VirtualBoxの仮想環境では約２０分掛かっていました。記事の内容とは関係無いですが、Appleシリコン速いですね！

bulk insertの場合

次に、UsersSeederを編集してbulk insertにしてみましょう。bulk insertにするには一度、挿入するデータを連想配列で用意し、insertメソッドに渡します。

database/seeds/UsersSeeder.php

...
public function run()
{ 
    $faker = Faker::create('ja_JP');

    $params = [];

    for ($i=0; $i < 100000; $i++) { 
        $params[] = [ 
            'name' => $faker->name(),
            'email' => "test{$i}@example.com",
            'password' => 'testtest',
        ];
    } 

    User::insert($params);
}

db:seedを実行してみましょう。

$ php artisan db:seed 
Seeding: UsersSeeder
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 4194312 bytes) in ...

流石に10万件のデータを一つの変数に格納するとメモリの使用上限に達し、エラーが発生してしまいました。（memory_limitは初期設定の128MBです）

ini_set()でmemory_limitを上げても良いですが、一体どれだけメモリを食うのか分かりません。1000件毎にinsertメソッドを実行、$paramsを初期化し、メモリ使用量を抑える事にしました。以下が修正を加えたコードです。

database/seeds/UsersSeeder.php

...
public function run()
{ 
    $faker = Faker::create('ja_JP');

    $params = [];

    for ($i=0; $i < 100000; $i++) { 
        $params[] = [ 
            'name' => $faker->name(),
            'email' => "test{$i}@example.com",
            'password' => 'testtest',
        ];

        if (count($params) >= 1000) {
            User::insert($params);
            $params = [];
        }
    } 
}

蛇足ですが、こちらの記事、High-speed inserts with MySQLにて

It takes around 1,000 inserts per query to reach the maximum throughput

と言及されているように、bulk insertの場合は１クエリ辺り1000件のインサートが最も効率が良いらしいです。

再度、db:seedを実行してみましょう。

$ php artisan db:seed
Seeding: UsersSeeder
Seeded:  UsersSeeder (5.8 seconds)
Database seeding completed successfully.

約２分半掛かっていたのが、約６秒です。約２０分掛かっていた Windows + VirtualBox の環境でも約６秒でした。すごい差です！

created_at, updated_atは自動入力されない

一点注意が必要なのは、bulk insertではModelクラスにて$timestampsをtrueに設定していても、created_atやupdated_atは自動入力されません。なぜならinsertメソッドはEloquent側ではなく、クエリビルダ側のメソッドだからです。したがって、insertするパラメタに明示的に含める必要があります。

まとめ

大量のレコードを挿入する場合、１レコードずつではなく、bulk insertで一括挿入することでとても速く処理できます。これは逆にDBへのクエリ発行がプログラムにおいて如何に重い処理か、という事を示しています。普段コードを書く際にも無駄なクエリを発行していないか気をつけねば、と思った次第です。

DBの負荷の緩和（3）コントローラにより接続を変える

Sun, 26 Apr 2020 01:28:18 +0900

マスターDBの変更が複製DBに反映されるまでの時間差を考えると、サイトの特定のページでは複製DBのアクセスを使用したくないかもしれません。例えば、会員のログインなど会員のアカウントの情報に関わるページとか、Eコマースのチェックアウトのページとか、あるいは管理者のみがアクセスする管理ページとか。そうなると、特定のコントローラだけに複製DBコネクションを限定するにはどのようにすればよいのでしょう？

まず、マスターDBのみのDBコネクションをmysqlとして、複製DBを使用するDBコネクションをmysql_rwとして、config/database.phpで２つのコネクションを設定します。

config/database.php

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

    'connections' => [

        'mysql' => [
            'driver' => 'mysql',
            'url' => env('DATABASE_URL'),
            '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' => 'utf8',
            'collation' => 'utf8_unicode_ci',
            'prefix' => '',
            'strict' => false,
            'engine' => null,
            'timezone' => 'Asia/Tokyo',
        ],

        'mysql_rw' => [
            'driver' => 'mysql',
            'url' => env('DATABASE_URL'),
            'read' => [
                'host' => env('DB_HOST_RO', env('DB_HOST', '127.0.0.1')),
                'username' => env('DB_USERNAME_RO', env('DB_USERNAME')),
                'password' => env('DB_PASSWORD_RO', env('DB_PASSWORD')),
            ],
            'write' => [
                'host' => env('DB_HOST', '127.0.0.1'),
                'username' => env('DB_USERNAME', 'forge'),
                'password' => env('DB_PASSWORD', ''),
            ],
            'port' => env('DB_PORT', '3306'),
            'database' => env('DB_DATABASE'),
            'unix_socket' => env('DB_SOCKET', ''),
            'charset' => 'utf8',
            'collation' => 'utf8_unicode_ci',
            'prefix' => '',
            'strict' => false,
            'engine' => null,
            'timezone' => 'Asia/Tokyo',
        ],
..

.envのファイルでは、DB_HOST_RO, DB_USERNAME_RO, DB_PASSWORD_ROの設定項目の指定が必要となります。 ROはRead Onlyという意味で読み込み専用のユーザーが複製DBにアクセスします。

また、デフォルトは、マスターDBのコネクションであることに注意してください。

次に、例えば、商品閲覧ページにおいてDBコネクションを変えるには、以下のように、コントローラのコンストラクタにおいて、コネクションのデフォルトを上書きしてDB::reconnect()で接続します。

app/Http/Controllers/ProductController.php

namespace App\Http\Controllers;

class ProductController extends Controller
{
    public function __construct()
    {
        parent::__construct();

        config(['database.default' => 'mysql_rw']);
        DB::reconnect();
..

簡単ですね。

いちいち、それぞれのコンストラクタでコネクションを変えるのが面倒なら、以下のよう親のコントローラにおいてまとめて指定することも可能です。試してはいないですが、ミドルウェアでの対応も可能なはずです。

app/Http/Controllers/Controller.php

    public function __construct()
    {
        $route = Route::currentRouteName();

        // 特定のページだけDBコネクションを変更する
        $routes = [
            'user.home',
            'user.page',
            'user.shop',
            'user.category',
            'user.collection',
            'user.product',
        ];

        if (in_array($route, $routes)) {
            config(['database.default' => 'mysql_rw']);
            DB::reconnect();
        }
...

DBの負荷の緩和（２）トランザクション

Mon, 20 Apr 2020 02:31:25 +0900

前回において、Laravelの読み込みと書き込みのDBを自動使い分け機能により、プログラムの設定だけで簡単にDB負荷を緩和できることを知りました。今回は、DBのトランザクションにおいてその機能の振る舞いをチェックしてみます。

例えば、以前の個数管理での在庫数変更の以下の例を見てます。

$product = Product::find(1);　// 複製のDBから読み込む
 
$product->update(['inventory' => $product->inventory - 1]); // マスターのDBで書き込む

上では、まず、商品の情報をDBから読み込み、そこから得る在庫数をもとに次の行で在庫数を変更します。しかし、２つのDBを使用するとなると、最初の行は複製DBからの読み込みとなり、次の行ではマスターのDBにおいての書き込みとなります。

問題は、複製のDBはマスターDBとの時間差があるので、もしかしたら最初の行で読み込んだのは最新の在庫数ではないかもしれないません。つまりデータの整合性の問題となる可能性です。

そうなら、以下のようにトランザクションで囲んでみましょう。

DB::beginTransaction();
 
$product = Product::find(1);
 
$product->update(['inventory' => $product->inventory - 1]);
 
DB::commit();

しかし、トランザクションはマスターDB内だけでの作業の整合性を保証するものなので、同じ問題となるのでは？

Laravelのコードを深く追ってみます。

まず、LaravelのDB接続のクラスでは、マスターDBの$pdoと読み込み専用の$readPdoの２つのDB接続のための変数が宣言されています。

/vendor/laravel/framework/src/Illuminate/Database/Connection.php

...
class Connection implements ConnectionInterface
{
    use DetectsDeadlocks,
        DetectsLostConnections,
        Concerns\ManagesTransactions;

    /**
     * The active PDO connection.
     *
     * @var \PDO|\Closure
     */
    protected $pdo;

    /**
     * The active PDO connection used for reads.
     *
     * @var \PDO|\Closure
     */
    protected $readPdo;
...

そして、同じクラス内で、読み込みDBの接続の取得は、以下のメソッドで定義されています。

    /**
     * Get the current PDO connection used for reading.
     *
     * @return \PDO
     */
    public function getReadPdo()
    {
        if ($this->transactions > 0) { //トランザクションがあると、マスターのDB接続を使用
            return $this->getPdo();
        }

        if ($this->recordsModified && $this->getConfig('sticky')) {
            return $this->getPdo();
        }

        if ($this->readPdo instanceof Closure) {
            return $this->readPdo = call_user_func($this->readPdo);
        }

        return $this->readPdo ?: $this->getPdo();
    }
...

トランザクションがあると、読み込み専用のDBではなく、マスターのDBが使われる条件文があります。つまり、トランザクションの中では、たとえDB実行文が読み込み（SELECT SQL文）であっても、読み込みのDB接続は使われずマスターDBしか使われないということです。

ちなみに、上のコードではstickyのときも、条件文で読み込みのDBの使用しないようになっています。これは以下のようにデータベースの設定で指定できます。そして、目的はDB更新後に、書き込みをしたマスターDBから値を読みたいときです。トランザクションと同様に、読み込み専用のDBからでは時間差の問題が生ずるからです。良く考えられていますね。

config/database.php

...
'mysql' => [
    'read' => [
        'host' => [
            '192.168.1.1',
            '196.168.1.2',
        ],
    ],
    'write' => [
        'host' => [
            '196.168.1.3',
         ],
    ],
    'sticky'    => true,
    'driver'    => 'mysql',
    'database'  => 'database',
    'username'  => 'root',
    'password'  => '',
    'charset'   => 'utf8mb4',
    'collation' => 'utf8mb4_unicode_ci',
    'prefix'    => '',
],
...

個数管理

Sat, 28 Mar 2020 05:46:15 +0900

商品の在庫数管理など一般的な個数管理に必要とされる、Eloquentのメソッドdecrementを紹介します。

準備

まず、商品テーブルの作成からです。migrationを作成します。

$ php artisan make:migration create_products_table --create=products

作成されたファイルを編集して、name, price, inventoryの項目を追加します。

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

class CreateProductsTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('products', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->char('name', 100); // 商品名
            $table->decimal('price', 10, 0);　// 価格
            $table->smallInteger('inventory'); // 在庫数
            $table->timestamps();
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::dropIfExists('products');
    }
}

これをmigrateしてテーブルを作成します。

$ php artisan migrate

次に、tinkerを立ち上げて商品レコードを作成します。

$ php artisan tinker
Psy Shell v0.9.12 (PHP 7.2.16 — cli) by Justin Hileman
>>> use App\Product;
>>> Product::create(['name' => '商品', 'price' => 1000, 'inventory' => 10]);
=> App\Product {#3064
     name: "商品",
     price: 1000,
     inventory: 10,
     updated_at: "2020-03-27 19:35:37",
     created_at: "2020-03-27 19:35:37",
     id: 1,
   }

トランザクションで整合性を保持

商品の在庫から購入数分だけ差し引く処理として、まず考えられるのは以下のようになります（引き続きtinkerを使用します）。

>>> use App\Product;
>>> $product = Product::find(1);
=> App\Product {#3056
     id: 1,
     name: "商品",
     price: "1000",
     inventory: 10,
     created_at: "2020-03-27 19:35:37",
     updated_at: "2020-03-27 20:03:27",
   }
>>> $product->update(['inventory' => $product->inventory - 1]);
=> true
>>> $product->refresh();
=> App\Product {#3056
     id: 1,
     name: "商品",
     price: "1000",
     inventory: 9,
     created_at: "2020-03-27 19:35:37",
     updated_at: "2020-03-27 20:04:56",
   }
>>>

つまり、商品をオブジェクトに読み込んで、現在の在庫数の属性（inventory）の値から、必要な個数（ここでは１個）を引いた値でDBレコードを更新（update）します。

上で実行されたSQL文を確認のために見てみましょう。レコード読み込み、更新、さらに読み込みと３つのSQL文となります。

>>> sql();
=> [
     [
       "query" => "select * from `products` where `products`.`id` = ? limit 1",
       "bindings" => [
         1,
       ],
       "time" => 14.83,
     ],
     [
       "query" => "update `products` set `inventory` = ?, `products`.`updated_at` = ? where `id` = ?",
       "bindings" => [
         9,
         "2020-03-27 20:04:56",
         1,
       ],
       "time" => 5.79,
     ],
     [
       "query" => "select * from `products` where `products`.`id` = ? limit 1",
       "bindings" => [
         1,
       ],
       "time" => 8.23,
     ],
   ]

このやり方、一見良さそうに見えますが、大きな問題があります。

ウェブのように同時に同じ処理が可能な環境において、レコードを読み込んだ時と書き込むときの間に在庫数がすでに更新されているかもしれないことです。その場合には在庫数は不正確になってしまいます。

これを防ぐには、上のプログラムをトランザクションで囲むことです。

DB::beginTransaction();

$product = Product::find(1);

$product->update(['inventory' => $product->inventory - 1]);

DB::commit();

トランザクションでは複数のSQL文の実行があたかも１つのように実行してくれるので、その間の作業の整合性を保持してれます。

よりシンプルに

先のトランザクションでも問題ないですが、以下のようEloquentのdecrementのメソッドを使用して同様な処理も可能です。

>>> Product::where('id', '=', 1)->decrement('inventory', 1);
=> 1
>>> sql();
=> [
     [
       "query" => "update `products` set `inventory` = `inventory` - 1, `products`.`updated_at` = ? where `id` = ?",
       "bindings" => [
         "2020-03-27 20:18:48",
         1,
       ],
       "time" => 9.34,
     ],
   ]

こうなるとSQL文は１つなので、整合性保持のためのトランザクションの必要はなくなります。

さて、注意する必要があるのは、上の例を見て、以下でも同じことができるのでは？と思われることです。

>>> Product::find(1)->decrement('inventory', 1);
=> 1

しかし、このSQL文を見てみると、以下のように読み込みと更新の２つのSQL文になっています。これではトランザクションが必要となります。

>>> sql();
=> [
     [
       "query" => "select * from `products` where `products`.`id` = ? limit 1",
       "bindings" => [
         1,
       ],
       "time" => 12.63,
     ],
     [
       "query" => "update `products` set `inventory` = `inventory` - 1, `products`.`updated_at` = ? where `id` = ?",
       "bindings" => [
         "2020-03-27 20:22:48",
         1,
       ],
       "time" => 2.58,
     ],
   ]

在庫がゼロにならないようにするには

在庫数を減らすときに、在庫数がゼロにならないようにするには、チェックが必要です。これも以下のように実行するなら１つのSQL文で済みます。

>>> Product::where('id', '=', 1)->whereRaw('inventory - 1 >= 0')->decrement('inventory', 1);
=> 1
>>> sql();
=> [
     [
       "query" => "update `products` set `inventory` = `inventory` - 1, `products`.`updated_at` = ? where `id` = ? and inventory - 1 >= 0",
       "bindings" => [
         "2020-03-27 20:38:46",
         1,
       ],
       "time" => 10.09,
     ],
   ]

最初の行の実行で返り値が１となっていること気づいたと思いますが、そこでは更新されたレコードの数が返っています。

もし、実行の前の在庫数がすでにゼロなら、

>>> Product::where('id', '=', 1)->update(['inventory' => 0]);
=> 1
>>> Product::where('id', '=', 1)->whereRaw('inventory - 1 >= 0')->decrement('inventory', 1);
=> 0

０が返って更新はなかった、ということです。

Googleデータポータル：データソースとレポートの作成

Mon, 22 Jul 2019 03:14:11 +0900

以前からお客さんのプロジェクトの管理画面のダッシュボードに日別や月別の売り上げ合計や会員の獲得数などをグラフで表示したいと思っていました。もちろん、グラフを作成するjavascriptのライブラリはいくつかありますが、習得にも開発にも時間がたくさんかかりそうです。そこで私の目に留まったのが、Googleデータポータル。データソースを指定してビジュアルなツールでちょいちょいとグラフ化できそうです。今回は、それを使用してMySQLのデータベースから月別に登録した会員数の棒グラフの作成の仕方を説明します。

完成は以下のような画面です。

準備：データベース

まず、データポータルが取得してくるデータのソースとなるデータベースの準備が必要です。コマンドラインから、以下を実行します。

$ mysql -u root mysql -p
Enter password: 
mysql> create database l58;
mysql> create user 'gds'@'%' identified by 'password';
mysql> grant select on l58.* to 'gds'@'%';

データベース名　⇒　l58 ユーザー名　⇒　gds パスワード　⇒　password 権限　⇒　SQL文でSELECTのみの実行が可能 アクセス権限　⇒　インターネットのどこからも（上では、‘gds’@’%‘の%の指定により）

という設定です。しかし、たとえパスワードの認証があってもインターネットのどこからでもこのDBにアクセスできるのは不安ですね。これに関しては後に対応します。

次は、このデータベースを使用するLaravelのプロジェクトの作成ですが、ここでは最新のLaravelのバージョン（5.8）をインストールしたと仮定します。.envの設定には先のデータベース情報を使用することを忘れずに。

このデータベースでのDBテーブルの作成は、以下のようにmigrateを実行します。

$ php artisan migrate
Dropped all tables successfully.
Migration table created successfully.
Migrating: 2014_10_12_000000_create_users_table
Migrated:  2014_10_12_000000_create_users_table (0.02 seconds)
Migrating: 2014_10_12_100000_create_password_resets_table
Migrated:  2014_10_12_100000_create_password_resets_table (0.02 seconds)

今度は、DBテーブル、usersを会員のテーブルとして、ここにフェイクの会員レコードを100個作成します。もちろん、factory()のヘルパーを使用してレコード作成となりますが、１つ問題があります。デフォルトの設定では、作成された会員のレコード作成日時(created_at)が皆作成日が同じになってしまうのです。これでは月別の棒グラフでは今月のみの表示となってしまいます。

Fakerのドキュメントを閲覧すると、dateTimeThisYear()という関数があり、多分に今年の日付をランダムに作成してくれるようです。この関数を使い、以下のようにUserFactory.phpを編集して、created_atに値がランダムに振り当てられるようにします。

...                                                                                                                                                                                                 
$factory->define(User::class, function (Faker $faker) {                                                                                                                                                            
    $dtm = $faker->dateTimeThisYear($max = 'now', $timezone = 'Asia/Tokyo');                                                                                                                                       
                                                                                                                                                                                                                   
    return [                                                                                                                                                                                                       
        'name' => $faker->name,                                                                                                                                                                                    
        'email' => $faker->unique()->safeEmail,                                                                                                                                                                    
        'email_verified_at' => now(),                                                                                                                                                                              
        'password' => '$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi', // password                                                                                                                  
        'remember_token' => Str::random(10),                                                                                                                                                                       
        'created_at' => $dtm,                                                                                                                                                                                      
        'updated_at' => $dtm,                                                                                                                                                                                      
    ];                                                                                                                                                                                                             
});

用意ができたところで、いつものようにtinkerでレコード作成してみましょう。

>>>  factory(App\User::class, 100)->create();
=> Illuminate\Database\Eloquent\Collection {#2982
     all: [
       App\User {#2978
         name: "鈴木 直子",
         email: "kana93@example.com",
         email_verified_at: "2019-07-18 20:06:46",
         created_at: "2018-10-13 10:06:32",
         updated_at: "2018-10-13 10:06:32",
         id: 1,
       },
       App\User {#2976
         name: "伊藤 幹",
         email: "shuhei93@example.com",
         email_verified_at: "2019-07-18 20:06:46",
         created_at: "2019-05-17 21:42:06",
         updated_at: "2019-05-17 21:42:06",
         id: 2,
       },
     ...

100個レコードできました。意図通りに、作成日時（created_at）もレコードごとに違います。しかし、何故か去年のレコードが作成されているのは変ですね。いつか調べてみます。

準備：MySQLのセキュリティ

先ほど設定したデータベースは、ユーザー情報があればインターネットのどこからでも3306のポートでアクセスできます。Googleデータポータルだけからのアクセスに制限したいなら、ここで書かれているIPのみに制限を課すことができます。

AWSならEC2でセキュリティグループを作成して以下のIPだけから、MySQLのポート(3306)にアクセスできる制限を設定できます。そして、このセキュリティグループを使用しているEC2のセキュリティに追加すればよいです。

データソースの作成

データベースとデータの準備ができたところで、今度はGoogleデータポータルに移ります。まずは、先のデータベースに接続するために、データソースなるものを作成します。Googleのアカウントですでにログインしていると仮定して、こちらへアクセスしてください。

以下の画面で、作成ボタンを押して、データソースを選択します。

次に、数あるデータコネクタから、MySQLを選択します。左上のデータソース名を無題から改名することもお忘れずに。

今度は、データベース情報を入力して、認証ボタンを押します。

認証が成功すると、DBテーブルのリストが右に表示されます。そこから、使用したいDBテーブルを選択します。ここでは、会員のusersを選択します。そして、右上の再接続をクリックしてください。

再接続したのちに表示される画面は、DBテーブル、usersの項目のリストです。なぜか、create_at, updated_atのtimestampの項目は「テキスト」となっているので、以下のように日時のタイプを選択しておいてください。

もう１つの作業として、最終の棒グラフでは、X軸を年月としたいので、年月のフィールドをcreated_atをもとに作成します。

以下のように、フィールドを追加で開かれる画面で、計算式をTODATE(created_at,‘DEFAULT_DECIMAL’, ‘%Y-%m’)と設定します。ここ、MONTH(created_at)のように思われますが、グラフが月別の表示とならなくうまく行きません。Googleデータポータルは、MySQLのtimestampのデータタイプを文字列とみなしているためかもしれません。

レポートの作成

フィールドの設定が完了したところで、このデーターソースを使ってレポートを作成します。画面右上のレポートを作成ボタンを押してください。

開かれた画面で、縦棒グラフを追加します。

次に、以下のように、棒グラフの右のパネルで指定します。「使用可能な項目」から、適切な項目をドラグして以下にドロップします。

上の画面で行った設定は、 データソース ⇒ DS MySql（すでにデフォルトで設定されている） 期間のディメンション ⇒　created_at ディメンション ⇒ 年月指標　⇒　idをドラグして、名前を「会員数」とし、集計方法を「件数」に変更。 並べ替え ⇒　年月。降順から昇順に変更。

こう設定すると、X軸に年月、Y軸にに会員数と、指定のデータベースのデータをもとにした棒グラフが期待通りに表示されます。

表示モードとするとこのポストの最初の画面となります。右上の期間の指定を変えてみてください。応じて、棒グラフが変わります。

最後に、ここで作成したレポートは、どのように管理画面にはめ込むのでしょうか？それは次回のポストとします。

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

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

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

MySQLデータベースのレプリカにAWS RDSを利用

Tue, 02 Oct 2018 11:33:08 +0900

昔からMySQLでレプリカ（複製）が作成できる機能の存在は知っていたけれど、大きなスケールのサイトで、ロードバランスに使用される読み込み専門のレプリカとして使われるだろうな、くらいに思っていました。しかし、最近はこれがほぼリアルタイムに近いバックアップとしても使える可能性を知り、早速取り組んだ次第です。

AWS RDS

MySQLのデータベースのレプリカを作成するには、もちろんレプリカのソースとなるマスターのMySQLサーバーがあります。私のケースでは、LAMPなのでマスターはAWSのEC2のマシンに常駐サービスの１つとして存在しますが、さてレプリカはどこに置いたら良いでしょう？

レプリカと言ってもこれもまたMySQLサーバーが必要なので、新規のEC2のマシンを用意して、そこにレプリカを置くことになります。しかし単にレプリカのためだけの目的で、もう１つマシンを用意するのはちょっとです。将来においてマシンのOS更新とかバックアップの設定とかメンテが面倒です。そこで注目したのは、AWSのRDSです。今時流行りのSAAS（Software AS Service）です。

今まで使ったことがないAWSのサービスなので親交を深める良い機会です。と思って取り組みましたが、はっきり言って、手順が複雑です。数日かけて何回も失敗して、レプリカのＤＢを何回も作成し直して。。。ということで、忘れないように貴重な（少なくとも私には）手順の作成となりました。

１．レプリカのDBインスタンスの作成（AWS）

まずは、AWS RDSのページへ行き、レプリカを保存するDBインスタンス（マシン）の作成です。以下へのアクセスは、AWSへのアカウントへのログインが必要です。

https://ap-northeast-1.console.aws.amazon.com/rds/home?region=ap-northeast-1#launch-dbinstance:

その後以下のステップを経て、DBインスタンスの作成です。AWSでは「データベースの作成」という言葉が使用されていますが、実際は、DBインスタンス、つまりマシンの作成です。１つのDBインスタンスで、いくつものデータベースを作成が可能ですので。混乱しないように注意してください。

ステップ１　エンジンの選択

ここでは、「エンジン」にはMySQLを選択します。また、最初のテスト段階では必ず「無料バージョン」を選択するのを忘れずに。

ステップ２ DB詳細の指定

ここでは、とくに「DBエンジンのバージョン」に注意してください。なるべくマスターと同じMySQLのバージョンの使用を薦めます。すでに「無料利用枠」を選択しているなら、「DBインスタンスのクラス」は、一番小さいマシンのt2.microしか選択できません。他のオプションも選択不可となっています。下の画面には表示されていませんが、「DBインスタンの識別子」や「マスターユーザーの名前」と「マスターパスワード」の入力も必要です。

ステップ３詳細設定の指定

この画面での注意としては、「パブリックアクセシビリティ」では「いいえ」を選択すること。いろいろなケースがありますが、今回はマスターとのコミュニケーションをプライベートのIPアドレスを通して行うゆえにです。さらに、「アベイラビリティーゾーン」では、必ずマスターとは違うゾーンを選ぶことです。ゾーンは物理的に独立した場所にあるデータセンターなので、片方で火事などが起こってデータを失ってもも片方ではＯＫという仮定です。ここでは触れませんが、このためにVPCのサブネットを前もって作成する必要があるかもしれません。

完了！

これでDBインスタンス作成の設定が完了です。これから数分間でDBインスタンスへのアクセスが可能となります。

２．マスターでの設定と作業

レプリカのDBインスタンスを作成したところで、今度はマスターでの設定です。いくつかの作業があります。

レプリカのログの作成

マスターのMySQLサーバーにおいて、レプリカのためのログの作成が必要です。このログは、マスターのDBで実行されるすべてのSQL文を皆バイナリのファイルに入れたようなものです。それをレプリカが定期的にのMySQLサーバーが取りに行き、レプリカでそれらを実行してマスターと同期するわけです。

ログのファイルは以下のように番号が付いたファイルとして作成されます。最新のものほど大きい番号となります。

$ ls -1
mysql-bin.000001
mysql-bin.000002
mysql-bin.000003
mysql-bin.index

このログ作成の設定は、マスターのマシンの/etc/my.cnfで行います。

/etc/my.cnf

...
[mysqld]
...
server-id=1	
binlog-do-db = test1_db
binlog-do-db = test2_db
log-bin=/var/lib/mysql/logs/mysql-bin.log	
...

server-idはユニークな数字のIDでレプリカのIDとは重複しないようにしてください。私の設定ではAWS RDSのレプリカのserver-idは非常に大きな数字（例：2092607505）なので小さい数字ならとりあえずＯＫです。binlog-do-dbではレプリカを作成したいDB名を指定します。複数のときは例のように複数行で指定します。log-binは、ログファイルの場所とそのファイル名のフォーマットを指定します。

設定後に、MySQLサーバーをリスタートします。もちろんその前にLaravelのアプリなら、

$ php artisan down

や、クロンジョブなどのサービスをダウンさせること忘れないでください。

リスタート後に、MySQLのコマンドで、マスターのステータスを見ることができます。

		
mysql> show master status;

+------------------+----------+----------------------------------+------------------+
| File             | Position | Binlog_Do_DB                     | Binlog_Ignore_DB |
+------------------+----------+----------------------------------+------------------+
| mysql-bin.000001 |      107 | test1_db, test2_db               |                  |
+------------------+----------+----------------------------------+------------------+
1 row in set (0.00 sec)

この時点では、Laravelのアプリもクロンジョブも再開してＯＫです。

レプリカのためのDBユーザーの作成

今度は、レプリカのMySQLがマスターのログからデータを取得するために、マスターにおいてDBユーザーを作成します。

$ mysql -u root -p
...
mysql> GRANT REPLICATION SLAVE ON *.* TO 'slave_user'@'%' IDENTIFIED BY 'testtest';
mysql> FLUSH PRIVILEGES;

最初の行は、slave_userがtesttestのパスワードでログインして複製の情報を取得することをＯＫしています。ここではどこのホストからでもマスターのどのデータベースの複製がＯＫという設定です。

レプリカからマスターへのアクセス制限

ここではインスタンス（マシン）レベルで、レプリカがマスターにアクセスできる設定をします。まず、レプリカのDBインスタンスのＩＰアドレスが必要です。DBインスタンスの情報画面で、まず「エンドポイント」のホスト名を取得します。

それを、シェルでpingします。

$ ping db1.xxxxxx.us-west-2.rds.amazonaws.com
PING db1.xxxxxx.us-west-2.rds.amazonaws.com (10.0.1.32) 56(84) bytes of data.

そのIPアドレスを今度は、AWSのコンソールの「セキュリティグループ」で以下のように、ポート3306に対してオープンします。このセキュリティグループはマスターで使用されているものです。

レプリカの設定

もうゴールは近しです。マスターのデータをレプリカにコピーしてレプリカの開始です。

マスターからレプリカへのアクセスの設定

先ほどとは逆に、今度はマスターからレプリカへアクセスできるための設定です。AWSコンソールで先と同様な作業ですが、今度は、レプリカの「ステップ３詳細設定の指定」の画面で作成したあるいは指定したセキュリティグループにおいて、マスターからのアクセスを許します。

画面での、10.0.0.137は、マスターのプライベートのIPアドレスです。

マスターのデータをレプリカにコピーして複製を開始

まず、マスターで対象のデータベースのデータをエクスポートします。

$ mysqldump -u root test1_db --master-data -p > test1_db.sql

次には、レプリカにアクセスしてそのデータをレプリカにインポートします。

$ mysql -u root -h db1.xxxxxx.us-west-2.rds.amazonaws.com -p
...
mysql> source test1_db.sql
...

引き続いて、レプリカのMySQLコマンドでマスターを設定して、複製を開始します。

mysql> CALL mysql.rds_set_external_master ('10.0.0.137', 3306, 'slave_user', 'testtest', 'mysql-bin.000001', 107, 0);		
mysql> CALL mysql.rds_start_replication;

最初の行の、‘mysql-bin.000001’, 107の数字は、test_db1.sqlのファイルの最初のページから情報が得られます（以下）。

--
-- Position to start replication or point-in-time recovery from
--

CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=107;

エクスポートの時点でのどのログファイル、どの位置かがこれでわかるため、エクスポートからインポートの間にどんなに時間が開いても、どんな変更があっても、そこの場所から複製を開始してマスターと同期できるわけです。

最後に、レプリカの複製の状況を見たいときは、コマンドshow slave statusを実行します。ここで問題があれば、エラーとして表示されますので注意をしてください。

mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.0.0.137
                  Master_User: slave_user
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000003
          Read_Master_Log_Pos: 8148599
               Relay_Log_File: relaylog.002965
                Relay_Log_Pos: 658
        Relay_Master_Log_File: mysql-bin.000003
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: mysql.rds_sysinfo,mysql.rds_history,mysql.rds_replication_status
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 8148599
              Relay_Log_Space: 1357
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 1
1 row in set (0.00 sec)

マスター側では、レプリカのRDSからログを取得に来ているのが以下でわかります。

$ mysql -u root -p
...
mysql> show processlist;
+--------+------------+-----------------------------------------------+------+-------------+--------+-----------------------------------------------------------------------+------------------+
| Id     | User       | Host                                          | db   | Command     | Time   | State                                                                 | Info             |
+--------+------------+-----------------------------------------------+------+-------------+--------+-----------------------------------------------------------------------+------------------+
|  54532 | slave_user | ip-10-0-1-32.us-west-2.compute.internal:47756 | NULL | Binlog Dump | 440946 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL             |
| 102446 | root       | localhost                                     | NULL | Query       |      0 | NULL                                                                  | show processlist |
+--------+------------+-----------------------------------------------+------+-------------+--------+-----------------------------------------------------------------------+------------------