DB tech showcase_tokyo2018_LOCONDO

5.6から5.7へ、そして更なるサービスの可用性を目指して
～急成長する靴の通販 LOCONDO.jp を支えるサービス安定化への取り組み～
db tech showcase Tokyo 2018 [D26]
Copyrights LOCONDO,Inc. All Rights Reserved.
●●
2018/09/20
株式会社ロコンド - Design & Tech本部 IT部門 / シニア・ディレクター
杉山真也

https://www.youtube.com/watch?v=ZU8uE80OPR4
●●

●●
ブランド工場
ブランド店舗
他EC
LOCONDO.jp LOCOMALL BOEM
プラットフォーム事業
Ex: E3PLサービス
ブランド事業EC事業

●●

売り上げ推移

●●
1: LOCOCHOC（ロコチョク）: 店舗向けのクラウド型欠品フォローシステム。
EC在庫を店舗で販売可能(店舗で注文➡店舗で支払い➡ LOCOPORT（倉庫）からお客さまへ配送)
2: LOCOPOS（ロコポス）: 店舗向けのクラウド型POSシステム。
店舗在庫をECでリアルタイムに販売可能
3: LOCOPAY（ロコペイ）: 会員情報・ポイント情報のオムニ化を実現。
会員カード兼QR決済機能
4: LoCore（ロコア）: 卸・店舗を含めた「売上管理」、工場の「生産原価管理」の一元管理が可能。
クラウド型基幹システム（計画: 2019 年 1 月～）
5: LOCOCOLLE（ロココレ）: 卸事業（B2B2C）のデジタル販売・管理が可能。
B2Bおよび展示会向けの受注受付機能（計画: 2019 年 1 月～）
更なるサービス拡張
https://www.youtube.com/watch?v=NuQkBR6kMcs

システム対応
更に顧客満足度の高いサービスを継続的に提供する為に..

目的
1: サイトの高可用性構成（マスター障害からの自動復旧）
2: 参照用スレーブ障害発生時の自動復旧
3: 障害発生時にアプリケーション側で設定変更不要
4: オンラインでスレーブ追加(プロビジョニング半自動化は次のフェーズ)
●●
ビジネス成長と共に、システム障害発生によるビジネスインパクトが年々増加。
システムの増加を抑えつつ、インフラ全体を更に冗長化する事でサービスの
安定化と機会損失を削減!! お客様のデータを保護し安定したサービスを提供。
＋障害発生時もエンジニアが落ち着いて対応出来る環境を構築。
KPI: 99.999% (5分15秒)
※ 計画メンテナンスを除く

要件
1: 今後の成長、2020年（x2.5倍の処理を行う事が出来るか?)
2: バッチ処理適用遅延についての仕様が許容出来るか?
3: 参照処理のスケールアウトが可能か?
4: バックアップ＆リカバリーの確実性
5: データーベース移行時の切り替えダウンタイム最小化
6: コスト的な妥当性の確認
●●

●●
●●
●●
これからまだ、安定稼働・自動復旧・開発効率改善・
自動化・最新技術への取り組み、スキルアップ等々
課題や改善すべきところは多々あるが、
まずはサービスのコアであるデータベースへの対応

対応中：可用性構成
Locondo.jp Logistics
Pri Sec Sec
Management
nginx
Network Devices (Router, LB)
MySQL Router MySQL Router MySQL Router
jdbc:mysql:replication://localhost:3306,localhost:3307 ... jdbc:mysql:replication://localhost:3306,localhost:3307 …jdbc:mysql:replication://localhost:3306,localhost:3307 …
Slave
MySQL8.0
Redis
Memcached
(Session)
●●

可用性構成: 障害発生時
Locondo.jp Logistics (WMS)
Pri Pri Sec
Management
nginx
Network Devices (Router, LB)
MySQL Router MySQL Router MySQL Router
jdbc:mysql:replication://localhost:3306,localhost:3307 ... jdbc:mysql:replication://localhost:3306,localhost:3307 …jdbc:mysql:replication://localhost:3306,localhost:3307 …
Slave
MySQL8.0
Redis
Memcached
(Session)
1: 障害発生時にPrimaryメンバーの自動フェールオーバー
2: Secondaryメンバーは、自動的に新PrimaryメンバーへのChange Master
3: MySQL RouterがGroupレプリケーションのメタデータをベースに接続先の自動振り分け
●●

MySQL5.6からMySQL5.7へ
既存環境をMySQL5.7にすることで、InnoDB Clusterの実装が可能
とはいえ先ずは..

アップグレードステップ
GTIDモードへオンラインで変更可能
JSONデータ型や関数が利用可能
日本語全文検索が利用可能
幾つかのパラメータが変更されている為、
my.cnfパラメータ調整
例 ) 変更/追加
log_timestamps=SYSTEM
log_error_verbosity=2
sql_mode
slave_parallel_type=LOGICAL_CLOCK
slave_parallel_workers=8
コメントアウト
innodb_file_format
innodb_log_block_size
thread_concurrency
Connector/Jが対応しているか?
enforce_gtid_consistency=WARN
クエリーが問題無いか、開発 1週間程確認。
本番環境では1ヶ月程度確認。
SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = ON;
SET @@GLOBAL.GTID_MODE = OFF_PERMISSIVE;
SHOW STATUS LIKE
'ONGOING_ANONYMOUS_TRANSACTION_COUNT';
SET @@GLOBAL.GTID_MODE = ON;
オプションファイル編集：
gtid_mode=ON
enforce_gtid_consistency=ON
binlog_gtid_simple_recovery=1
詳細： 16.1.5.2 Enabling GTID Transactions Online
MySQL5.6のバイナリーをMySQL5.7へアプリがGTIDに対応しているか確認オンラインでGTIDモードへ変更

スペックと用途に合ったパラメータを選択
Multi-Thread-slaveは、GTIDに移行後で無いとメリットは無い事も
グループレプリケーションでは勿論、 Multi-Thread-slaveを設定。
log_slave_updatesは、マスターにならないスレーブでは忘れずにOFF
binlog_formatは、ディスクI/Oやネットワーク負荷が増えるので要確認。
グループレプリケーションでは、ROWフォーマットが必須。

Pri Sec Sec
Master Slave Slave Slave
アップグレードステップ
既存環境を全て5.7にすることで、オンラインでGTIDモードへ変更可能。
GTIDモードであれば、InnoDB Clusterをスレーブとして追加してデータ同期可能
完全同期して問題無い事を確認したら、InnoDB Clusterに接続を切り替え。
GTID
(2) LOG POSITION → GTIDへ変更
データ同期が完了次第、アプリケーション
接続をこちらのクラスターに切り替え
(1) 5.6 ➡ 5.7
(3) InnoDB Clusterをスレーブとして追加
※ GTIDモードがInnoDB Clusterの必須要件
(4) アプリケーションの接続先を
InnoDB Clusterに変更（MySQL Router)

障害試験
常に安定したサービスを提供出来るか? 障害発生してもサービスを継続出来るか?

+---------------------------+--------------------------------------+-------------+-------------+----------------+
+---------------------------+--------------------------------------+-------------+-------------+----------------+
| group_replication_applier | e1731e29-f269-33j4-8646-020114770060 | TST-db-14 | 3306 | RECOVERING |
+---------------------------+--------------------------------------+-------------+-------------+----------------+
+----------------+
| primary master |
+----------------+
| TST-db-12 |
+----------------+
+---------------------------+--------------------------------------+-------------+-------------+---------------+
+---------------------------+--------------------------------------+-------------+-------------+---------------+
+---------------------------+--------------------------------------+-------------+-------------+---------------+
+----------------+
| primary master |
+----------------+
| TST-db-12 |
+----------------+
Slave
障害復旧
スレーブ障害
スレーブが復旧するとリカバリーモードに
なる。MySQL Routerがオンラインになっ
たのを判断して再接続を開始する。

+----------------+
| primary master |
+----------------+
| TST-db-12 |
+----------------+
[root@TST-db-12 benchmark]# kill 37299
[root@TST-db-12 benchmark]# ps -ef | grep mysql
root 21661 33444 0 15:53 pts/0 00:00:00 grep --color=auto mysql
[root@TST-db-12 benchmark]#
+---------------------------+--------------------------------------+-------------+-------------+--------------+
+---------------------------+--------------------------------------+-------------+-------------+--------------+
+---------------------------+--------------------------------------+-------------+-------------+--------------+
+----------------+
| primary master |
+----------------+
| TST-db-14 |
+----------------+
MASTER
障害発生
マスター障害
✓マスター障害が発生すると同時に自動的にグループ内のメンバーが
PRIMARYに昇格して更新処理を行う。(group_replication_member_weight)
✓スレーブは自動的に新しいマスターを参照しデータを受け取る。
✓ MySQL Routerはメタデータで新しいマスターを判断する。
Pri SecPri

localhost [BENCHMARK]> delete from t_slap01 where ID = 10;
Query OK, 1 row affected (0.00 sec)
localhost [BENCHMARK]> select @@hostname;
+------------+
| @@hostname |
+------------+
| TST-db-14 |
+------------+
localhost [BENCHMARK]> delete from t_slap01 where ID = 10;
ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement
itlocondo12@localhost [BENCHMARK]> select @@hostname;
+------------+
| @@hostname |
+------------+
| TST-db-13 |
+------------+
マスター障害
+---------------------------+--------------------------------------+-------------+-------------+---------------+
+---------------------------+--------------------------------------+-------------+-------------+---------------+
+---------------------------+--------------------------------------+-------------+-------------+---------------+
MASTER
復旧
新しいマスターでは更新処理が出来るが、
セカンダリーメンバーではrootでも更新処理
は出来ないので安全。
旧マスターが復旧しても、マスターは障害発
生時に選択されたメンバーが引き続き処理

[mysql_innodb_cluster_metadata]> show tables;
+-----------------------------------------+
| Tables_in_mysql_innodb_cluster_metadata |
+-----------------------------------------+
| clusters |
| hosts |
| instances |
| replicasets |
| routers |
| schema_version |
+-----------------------------------------+
[mysql]> SELECT member_host as "primary master" FROM performance_schema.global_status
JOIN performance_schema.replication_group_members WHERE variable_name = 'group_replication_primary_member' AND member_id=variable_value;
+----------------+
| primary master |
+----------------+
| TST-db-12 |
+----------------+
[mysql_innodb_cluster_metadata]> SELECT member_id, member_host, member_port, member_state, @@group_replication_single_primary_mode FROM
performance_schema.replication_group_members WHERE channel_name = 'group_replication_applier';
+--------------------------------------+-------------+-------------+--------------+-----------------------------------------+
| member_id | member_host | member_port | member_state | @@group_replication_single_primary_mode |
+--------------------------------------+-------------+-------------+--------------+-----------------------------------------+
| e1731e29-f269-33j4-8646-020114770060 | TST-db-14 | 3306 | ONLINE | 1 |
| 42c3cbdc-f269-33j4-b56c-02011477005e | TST-db-12 | 3306 | ONLINE | 1 |
| e53e17a3-f269-33j4-98c5-02011477005f | TST-db-13 | 3306 | ONLINE | 1 |
+--------------------------------------+-------------+-------------+--------------+-----------------------------------------+
アプリケーション
MySQL Router
アプリケーションはMySQL Routerに接続
MySQL Routerはデータベース内のメタデータを
参照し障害を検知して自動的に振り分ける!!
アプリケーション側での対応は不要。
メモ：“max_connections = 2048“ 等,パラメータ設定は調整
bootstrap_server_addresses=
mysql://TST-db-12:3306,
mysql://TST-db-13:3306,
mysql://TST-db-14:3306
localhost:6446
localhost:6447
Application

補足：名前解決が出来ない環境の場合
MySQL localhost:3306 JS > shell.connect('cluster_user@192.168.100.10:3306');
Creating a session to 'cluster_user@192.168.100.10:3306'
Please provide the password for 'cluster_user@192.168.103.130:3306': ************
Save password for 'cluster_user@192.168.100.10:3306'? [Y]es/[N]o/Ne[v]er (default No):
<SNIP>
MySQL 192.168.100.10:3306 JS > var cluster = dba.createCluster('locondoCluster');
A new InnoDB cluster will be created on instance 'cluster_user@192.168.100.10:3306‘
cluster.addInstance('cluster_user@192.168.100.11:3306');
cluster.addInstance('cluster_user@192.168.100.12:3306');
$mysqlrouter --bootstrap cluster_user:cluster_manager@192.168.100.10:3306 --force --user=sys_manager
<SNIP>
[metadata_cache:locondoCluster]
router_id=1
bootstrap_server_addresses=mysql://192.168.100.10:3306,mysql://192.168.100.11:3306,mysql://192.168.100.12:3306
ルータはBootstrap時にデータベース内の
メタデータからルーティング情報を作成する
ので、IPアドレスで登録した場合はhosts
ファイル等をメンテナンスしなくて良い。

負荷試験
中期的に、ユーザーに安定したサービスを提供する事が出来るか?

OLTP更新とバッチ処理の負荷シュミレーション
SYSBENCH用: 初期データ(4テーブル)
+----------+---------+------------+
| Database | Table | Size in MB |
+----------+---------+------------+
| sysbench | sbtest3 | 22426.69 |
+----------+---------+------------+
Pri Sec Sec
Tool: mysqlslap (バッチ系の処理を確認)
大量にまとめてデータをINSERTして削除する等、一つのトランザクションで大量にデータを処理する試験に使用。
Tool: sysbench(更新処理内容：計測の為に各ベンチマークを10分間実行)
INSERT INTO sbtest1 (id, k, c, pad) VALUES (75087935, 12463253, '13889104256-30791869017-66538184821-5…….
DELETE FROM sbtest1 WHERE id=75087935
UPDATE sbtest1 SET k=k+1 WHERE id=63874937
UPDATE sbtest4 SET c='51744764069-67682943268-15332003429-10934680309-42746352369-…………….' WHERE id=12627688
アーキテクチャ: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 40
Model name: Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz
Memory : 128GB
Disk : SanDisk ioMemory PX Series

OLTP:複数接続＋細かいデータ更新処理
[benchmark]# ./mysqlslap_check_group_member_lag.sh
BENCHMARKデータベースに対して、100クライアント x 1000件実行します
Enter password:
Benchmark
Average number of seconds to run all queries: 0.012 seconds
Minimum number of seconds to run all queries: 0.010 seconds
Maximum number of seconds to run all queries: 0.213 seconds
Number of clients running queries: 100
Average number of queries per client: 1
SQL> SELECT * FROM performance_schema.replication_group_members;SELECT count_transactions_in_queue FROM
performance_schema.replication_group_member_stats;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
+---------------------------+--------------------------------------+-------------+-------------+--------------+
+---------------------------+--------------------------------------+-------------+-------------+--------------+
細かくトランザクションが分かれているので、
トランザクションがQueueに溜まる事はあるが、
グループメンバー間に差は発生していない。
“insert”毎のコミット処理

select CHANNEL_NAME,RECEIVED_TRANSACTION_SET from replication_connection_status where CHANNEL_NAME = "group_replication_applier"¥G
select TRANSACTIONS_COMMITTED_ALL_MEMBERS from performance_schema.replication_group_member_stats¥G
select CHANNEL_NAME,WORKER_ID,LAST_SEEN_TRANSACTION from replication_applier_status_by_worker where CHANNEL_NAME = "group_replication_applier";
select @last_exec:=SUBSTRING_INDEX(SUBSTRING_INDEX(SUBSTRING_INDEX( @@global.GTID_EXECUTED,':',-1),':',1),'-',-1) last_executed;
select @last_rec:=SUBSTRING_INDEX(SUBSTRING_INDEX(SUBSTRING_INDEX( Received_transaction_set,':',-1),':',1),'-',-1) last_received FROM
performance_schema.replication_connection_status WHERE Channel_name = 'group_replication_applier';
select (@last_rec - @last_exec) as real_lag;SELECT count_transactions_in_queue FROM performance_schema.replication_group_member_stats;
*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
RECEIVED_TRANSACTION_SET: cb904887-a1fc-11e8-ae58-02011477005e:1-14035941
*************************** 1. row ***************************
TRANSACTIONS_COMMITTED_ALL_MEMBERS: cb904887-a1fc-11e8-ae58-02011477005e:1-13896262
<SNIP>
| group_replication_applier | 5 | cb904887-a1fc-11e8-ae58-02011477005e:14035940 |
+---------------------------+-----------+-----------------------------------------------+
+----------+
| real_lag |
+----------+
| 0 |
+----------+
+-----------------------------+
| count_transactions_in_queue |
+-----------------------------+
| 0 |
+-----------------------------+
この値は、Certificationモジュールによってグループ
メンバー全体の状況を確認する為に、一定の間隔で
更新される為、リアルタイムモニタリングには使えない。
受け取ったトランザクションはApplierスレッドが処理完了、
若しくは処理中。以下のクエリーの値が”0”を返す場合
は、まだコミットしていないトランザクションが残っている。
SELECT GTID_SUBSET(LAST_SEEN_TRANSACTION,
@@GLOBAL.GTID_EXECUTED) FROM
performance_schema.replication_applier_status_by_worker;
Queuingしているトランザクション数
大量に処理を流すと、Queueに溜まるが, 検証中は
問題になる程Queueは滞留する事はなかった。
受け取ったトランザクションセットの内容が
適用済みかどうか? 適用が完了していない、
トランザクションがあるかどうかの確認。

[root@TST-db-12 oltp32th80G]# ../oltp_test_read_only
sysbench 0.5: multi-threaded system evaluation benchmark
Running the test with following options:
Number of threads: 32
Initializing random number generator from timer.
Random number generator seed is 0 and will be ignored Threads started!
OLTP test statistics:
queries performed:
read: 41072402
write: 0
other: 5867486
total: 46939888
transactions: 2933743 (4889.52 per sec.)
deadlocks: 0 (0.00 per sec.)
read/write requests: 41072402 (68453.27 per sec.)
other operations: 5867486 (9779.04 per sec.)
General statistics:
total time: 600.0064s
total number of events: 2933743
total time taken by event execution: 19191.3811s
response time:
min: 3.10ms
avg: 6.54ms
max: 335.13ms
approx. 95 percentile: 9.27ms
Threads fairness:
events (avg/stddev): 91679.4688/1854.80
execution time (avg/stddev): 599.7307/0.04
※ MySQL Router経由での処理は別途確認だがスレーブは分散されるのでスケール可
queries performed:
read: 32271554
write: 0
other: 4610222
total: 36881776
General statistics:
response time:
min: 2.97ms
avg: 4.16ms
max: 66.61ms
Threads fairness:
SELECT
TPS:3841.82 TPS:4889.52

queries performed:
read: 47745418
write: 0
other: 6820774
total: 54566192
General statistics:
response time:
min: 3.41ms
avg: 11.26ms
max: 227.48ms
Threads fairness:
queries performed:
read: 46954110
write: 0
other: 6707730
total: 53661840
General statistics:
response time:
min: 3.67ms
avg: 22.89ms
max: 1030.25ms
Threads fairness:
※ MySQL Router経由での処理は別途確認し、スレーブ側処理は分散されスケールした
※ 1G程度の小さいテーブルであれば、512 threadsでTPS: 6500/sec以上可能であった
SELECT
TPS:5683.85 TPS:5589.53

[root@TST-db-12 write16th80G]# ../oltp_test_write
queries performed:
read: 12396902
write: 3541972
other: 1770986
total: 17709860
General statistics:
response time:
min: 5.93ms
avg: 10.84ms
max: 1178.88ms
Threads fairness:
※ count_transactions_in_queueは0～5の間で推移し遅延無し
queries performed:
read: 17297210
write: 4942060
other: 2471030
total: 24710300
General statistics:
response time:
min: 6.28ms
avg: 15.54ms
max: 1910.89ms
Threads fairness:
※ count_transactions_in_queueは0～30の間で推移し遅延無し
DML
TPS:2059.16TPS:1475.79

queries performed:
read: 20136074
write: 5753164
other: 2876582
total: 28765820
General statistics:
response time:
min: 7.16ms
avg: 26.70ms
max: 2889.46ms
Threads fairness:
※ count_transactions_in_queueは0～300の間で推移するが遅延無し
queries performed:
read: 21410284
write: 6117224
other: 3058612
total: 30586120
General statistics:
response time:
min: 10.29ms
avg: 50.21ms
max: 2539.81ms
Threads fairness:
※ count_transactions_in_queueは0～400の間で推移するが遅延無し
※ こちらのワークロードでは、512 Threadsまではトランザクションがスケールする事を確認。
※ 1G程度の小さいテーブルであれば、512 ThreadsでTPS: 3500/sec以上可能
DML
TPS:2548.67TPS:2397.08

queries performed:
read: 23119866
write: 6605676
other: 3302838
total: 33028380
General statistics:
response time:
min: 31.27ms
avg: 186.02ms
max: 3222.41ms
Threads fairness:
6,605,676書き込み/600秒
= 約11,000/秒
合計: 2746.82トランザクション/秒
細かいトランザクションであれば、
マスターとスレーブ間は同期状態
処理数を増やしていっても
ギャップが発生しない事を確認 ◎
更新処理も通常のOLTP処理であれば、
3倍以上は捌けると判断。

バッチ：長時間を要するシングルトランザクション
[BENCHMARK]> select now(),@@hostname;delete from t_slap01;select now(),@@hostname;
+---------------------+------------+
| now() | @@hostname |
+---------------------+------------+
| 2018-08-28 19:41:00 | TST-db-12 |
+---------------------+------------+
Query OK, 5000000 rows affected (1 min 53.19 sec)
+---------------------+------------+
| now() | @@hostname |
+---------------------+------------+
| 2018-08-28 19:42:53 | TST-db-12 |
+---------------------+------------+
[BENCHMARK]> select now(),@@hostname,count(*) from BENCHMARK.t_slap01;
+---------------------+------------+----------+
| now() | @@hostname | count(*) |
+---------------------+------------+----------+
| 2018-08-28 19:44:28 | TST-db-13 | 5000000 |
+---------------------+------------+----------+
[BENCHMARK]> select now(),@@hostname,count(*) from BENCHMARK.t_slap01;
+---------------------+------------+----------+
| now() | @@hostname | count(*) |
+---------------------+------------+----------+
| 2018-08-28 19:44:37 | TST-db-13 | 0 |
+---------------------+------------+----------+
注意： Primaryノードで長時間かかるトランザクションは、
コミットするまでバイナリーログが作成されない為、
スレーブへの反映が同様に遅れてしまう。

[performance_schema]> show variables like 'group_replication_flow_control_certifier_threshold';
+----------------------------------------------------+-------+
| Variable_name | Value |
+----------------------------------------------------+-------+
| group_replication_flow_control_certifier_threshold | 25000 |
+----------------------------------------------------+-------+
[performance_schema]> show variables like 'group_replication_flow_control_applier_threshold';
+--------------------------------------------------+-------+
| Variable_name | Value |
+--------------------------------------------------+-------+
| group_replication_flow_control_applier_threshold | 25000 |
+--------------------------------------------------+-------+
メモ：フローコントロールを設定するとグループメンバーの同期状態をコントロールする事が可能。
検証ではこちらの既定値で問題は無かったので、将来的にバッチ処理の内容等によって必要に応じて調整する。
参考：フローコントロール設定(Default) ●●

参照はセカンダリーノードにて処理を分散。
レポート関連は、グループレプリケーション
グループメンバー外で対応。
細かい更新処理は、コミット単位が細かいので
問題無い。バッチ処理は細かくトランザクション
を分割して対応する必要がある。

バックアップ＆リカバリー
障害からの回復とノード追加の為に必須なオペレーション

バックアップリカバリー
手法特徴
mysqldump MySQLの論理バックアップの定番
Group Replicationでもシングルトランザクションオプション利用して整合性のある
バックアップが取得可能。(MySQL 5.7.19 ～)
mysqlpump MySQL5.7以降で利用可能になったmysqldumpをマルチスレッド対応にした
論理バックアップツール
mysqlbackup MySQL Enterprise版のオンラインバックアップツール
物理バックアップで高速にバックアップを取得可能でTDE等にも対応している。
Group Replicationにも勿論完全対応!!
※Enterprise版にはグループレプリケーションをモニタリングするツールも付いてくる。
innobackupex Percona社が提供している、無償のオンライン物理バックアップツール(xtrabackup)
Group Replicationに対応しているが、リストア時にひと手間必要。
コールドバックアップグループメンバーのうち、1台のMySQLDを停止してデータファイルをコピー
コピー後にauto.cnfを削除して起動すれば直ぐにメンバーとして参加可能。
但し、コールドバックアップなのでサービス負荷が高くない時にしか実施出来ない。

xtrabackupにてリカバリー時のひと手間
[(none)]> select * from mysql.gtid_executed;
+--------------------------------------+----------------+----------------+
| source_uuid | interval_start | interval_end |
+--------------------------------------+----------------+----------------+
| cb904887-a1fc-11e8-ae58-02011477005e | 1 | 24598584 |
+--------------------------------------+----------------+----------------+
[(none)]> select @@global.GTID_EXECUTED;
+--------------------------------------------------------------------------------------------+
| @@global.GTID_EXECUTED |
+--------------------------------------------------------------------------------------------+
| cb904887-a1fc-11e8-ae58-02011477005e:1-24598587 |
+--------------------------------------------------------------------------------------------+
バックアップ取得時も
mysql.gtid_executedと
実際に実行したGTIDは異なる。
[(none)]> select * from mysql.gtid_executed;
+--------------------------------------+----------------+---------------+
+--------------------------------------+----------------+---------------+
| cb904887-a1fc-11e8-ae58-02011477005e | 1 | 24598584 |
+--------------------------------------+----------------+---------------+
リストア後にグループレプリ
ケーションは自動的に起動す
るが以下のエラーになって
グループ参加出来ない。
Duplicate entry '4600001' for key 'PRIMARY', Error_code: 1062;
handler error HA_ERR_FOUND_DUPP_KEY;
リストア時にテーブルの中身が実際にEXECUTEされた値ではない
バックアップ時（テーブルの中身が実際にEXECUTEされた値ではない)

xtrabackupにてリカバリー時のひと手間
[TST-db-14 2018-08-30_15-14-15]# cat xtrabackup_binlog_info
mysql-bin.000698 1257 cb904887-a1fc-11e8-ae58-02011477005e:1-24598587
[TST-db-14 2018-08-30_15-14-15]#
root@localhost [(none)]> stop group_replication;
Query OK, 0 rows affected (9.31 sec)
root@localhost [(none)]> reset master;
root@localhost [(none)]> select * from mysql.gtid_executed;
Empty set (0.00 sec)
root@localhost [(none)]> SET GLOBAL gtid_purged="cb904887-a1fc-11e8-ae58-02011477005e:1-24598587";
root@localhost [(none)]> select * from mysql.gtid_executed;
+--------------------------------------+----------------+--------------+
+--------------------------------------+----------------+--------------+
| cb904887-a1fc-11e8-ae58-02011477005e | 1 | 24598587 |
+--------------------------------------+----------------+--------------+
root@localhost [(none)]> start group_replication;

リストア完了
[mysql]> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | 3ca1e999-ac20-11e8-a526-020114770060 | TST-db-14 | 3306 | ONLINE |
| group_replication_applier | 42c3cbdc-a137-11e8-b56c-02011477005e | TST-db-12 | 3306 | ONLINE |
| group_replication_applier | e53e17a3-a137-11e8-98c5-02011477005f | TST-db-13 | 3306 | ONLINE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
メンバーを追加する場合も同様の手順で,新規ノードにリストアすれば、最大9台までオンラインで追加可能
参考：
https://yoku0825.blogspot.com/2017/07/gtid.html
https://www.percona.com/blog/2013/05/09/how-to-create-a-new-or-repair-a-broken-gtid-based-slave-with-percona-xtrabackup/

バージョンアップに伴う追加メリット
MySQLのレプリケーションは1メジャーバージョンの違いはサポート対象
“MySQL supports replication from one release series to the next higher release series. ”

MySQL8.0：集計関数が利用可能(Windows関数・CTE)
Pri
5.7
Sec
5.7
Sec
5.7
Slave
MySQL8.0
mysql> select
-> rank() over w as 'rank',
-> Continent,Name,GNP,
-> row_number() over w as 'row_number',
-> dense_rank() over w as 'dense_rank'
-> from country
-> window w as (order by GNP desc) limit 10;
+------+---------------+----------------+------------+------------+------------+
| rank | Continent | Name | GNP | row_number | dense_rank |
+------+---------------+----------------+------------+------------+------------+
| 1 | North America | United States | 8510700.00 | 1 | 1 |
| 2 | Asia | Japan | 3787042.00 | 2 | 2 |
| 3 | Europe | Germany | 2133367.00 | 3 | 3 |
| 4 | Europe | France | 1424285.00 | 4 | 4 |
| 5 | Europe | United Kingdom | 1378330.00 | 5 | 5 |
| 6 | Europe | Italy | 1161755.00 | 6 | 6 |
| 7 | Asia | China | 982268.00 | 7 | 7 |
| 8 | South America | Brazil | 776739.00 | 8 | 8 |
| 9 | North America | Canada | 598862.00 | 9 | 9 |
| 9 | Europe | Spain | 598862.00 | 10 | 9 |
+------+---------------+----------------+------------+------------+------------+
mysql> with t1 as (select * from city where CountryCode = 'JPN')
-> select * from t1 limit 5;
+------+---------------------+-------------+----------+------------+
| ID | Name | CountryCode | District | Population |
+------+---------------------+-------------+----------+------------+
| 1532 | Tokyo | JPN | Tokyo-to | 7980230 |
| 1533 | Jokohama [Yokohama] | JPN | Kanagawa | 3339594 |
| 1534 | Osaka | JPN | Osaka | 2595674 |
| 1535 | Nagoya | JPN | Aichi | 2154376 |
| 1536 | Sapporo | JPN | Hokkaido | 1790886 |
+------+---------------------+-------------+----------+------------+
Windows関数による、容易なランキング集計
CTEによる、Viewや一時テーブル処理と比較したパフォーマンス改善
http://mysqlserverteam.com/mysql-8-0-improved-performance-with-cte/

サマリー
■ 移行完了後には、データベースの可用性は99.999%まで向上
■ データベース障害発生時の緊急対応は不要
■ 自動リカバリーによるシステム障害発生時の機会損失を削減
■ ECサイトからの処理は現状の3倍以上になっても処理可能
■ バッチ処理に関しては、細かくトランザクションを分割し対応
■ バックアップはそれぞれの環境にあった方法を選択
■ レポート関連処理に関しては、グループ外スレーブとして
Windows関数、CTEが利用出来るMySQL8.0を活用し生産性を向上

ロコンドでは引き続き顧客満足度の高いサービスを
提供する為に、必要な開発やシステム改善、そして
技術的チャレンジを継続的に行っていきます!!
メンバー募集しています。
興味がある方は、是非ご応募下さい。
最後に.. 技術的側面からビジネスを促進＆支援

https://www.locondo.co.jp/recruit#recruitment
エンジニア募集中!!

有難うございました

DB tech showcase_tokyo2018_LOCONDO

More Related Content

What's hot

Similar to DB tech showcase_tokyo2018_LOCONDO

More from Shinya Sugiyama

DB tech showcase_tokyo2018_LOCONDO