RDS on ララジャパン

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'    => '',
],
...

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

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 |
+--------+------------+-----------------------------------------------+------+-------------+--------+-----------------------------------------------------------------------+------------------

RDS on ララジャパン

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

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

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

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

謎をひも解く

非同期の解決方法

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

準備

実行

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

デバッグ

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

AWS RDS

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

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

ステップ２ DB詳細の指定

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

完了！

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

レプリカのログの作成

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

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

レプリカの設定

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

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

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

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