Locondo 20190703@inno db_cluster

「靴業界全体の収益性・効率性の構造改革」
に取り組むLOCONDO.jpの可用性への取り組み
~ InnoDB Cluster導入から1年を通じた運用ノウハウの共有 ~
Copyrights LOCONDO,Inc. All Rights Reserved.
株式会社ロコンド - Design & Tech本部 IT部門/シニア・ディレクター
杉山真也 Twitter: @RDBMS
●●
2019/07/03@マジセミ

https://www.youtube.com/watch?v=ZU8uE80OPR4Copyrights LOCONDO,Inc. All Rights Reserved.
●●
「業界に革新を､お客さまに自由を」

●●
お客様のメリット

更に多くの商品を

ロコンド倉庫
（LOCOPORT）
3Q出荷個数: 605,517個
店舗倉庫
在庫在庫
LOCONDO.jp LOCOMALL
（楽天、Yahoo!)
BOEM
(自社EC支援)
リアル店舗同盟サイト
(magaseek, d fashion)
同盟サイト倉庫
（magaseek）
在庫
●●
WMS: B2B
EC: B2C
サプライヤー様のメリット(在庫の最適化)
https://www.locondo.co.jp/#our_business

●●
詳細: https://www.locondo.co.jp/partner/
物流受託
e3PL (E 3rd Party Logistics)
WMS:在庫管理システム(Warehouse Management System)
自社EC運営
BOEM 2.0
Brand’s Official EC Management
POS & QR決済
モバイル会員カード
LOCOPOS & LOCOPAY
店舗スタッフ用
在庫販売システム
LOCOCHOC

卸販売システム
LOCONDO Wholesale
(2019年9月2日ローンチ予定)
●●クラウド基幹システム
LoCore
(2019年9月2日ローンチ予定)
関連ニュース https://lnews.jp/2019/07/l0701404.html

取扱高推移(単体)
●●
目標: 2020年300 億

システム対応
更に顧客満足度の高いサービスを継続的に提供し、
サプライヤー様の売り上げ利益をサポートする為の取り組み
●●

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

システム要件
1: 今後の成長、2020年（x2.5倍の処理を行う事が出来るか?)
2: バッチ処理適用遅延についての仕様が許容出来るか?
3: 参照処理のスケールアウトが可能か?
4: バックアップ＆リカバリーの確実性
5: データーベース移行時の切り替えダウンタイム最小化
6: 管理工数を含むコストの妥当性の確認
7: その他
●●
2020年以降は
マイクロサービス化?
クラウド分散?

●●
●●
●●
InnoDB Cluster導入@2018
～MySQLに組み込まれたコストパフォーマンスの良い高可用性ソリューション～

●●
要件、導入事前検証、移行詳細に関しては、
昨年のセミナー資料を確認下さい。
https://www.slideshare.net/ShinyaSugiyama/db-tech-
showcasetokyo2018locondo

●●
継続的に安定したサービスを提供する為に、
障害発生に備え、サービス停止を最小限に
抑える必要があるかと思います。
但し、新しいシステム構成で運用すると、
これまで慣れ親しんだ構成と異なった事象に遭遇する
事もあるかと思います。本日は敢えてInnoDB Clusterを
運用する上で事前に知っておいた方が良い
と思われる項目を中心に説明させて頂きます。

参照: https://www.s-style.co.jp/jirei/case049.html
詳細: 16.1.5.2 Enabling GTID Transactions Online
●●
PHASE1: 5.7アップグレード

基本的にMySQLのオプティマイザーはバージョンアップと共に改良されていますが、
汎用的なパラメータの為に全ての条件に最適化されている訳ではありません。
移行後に一部処理が遅くなっていた為、パラメータや処理内容を見直しました。
例) 通常30分で終わるバッチ処理が、20時間かかってしまった。
アップグレードしたタイミングで実行プランが変わりVIEW経由のアクセスが遅くなった
【対応】実行プランを確認し、VIEWでは無くBASE TABLEを直接参照する事で対応し解消
※ ビジネスの成長過程で、工数をかけるべきポイントの優先順位は都度変わっていくものです。
常に全ての処理がベストな状況では無いかと思いますので臨機応変に適切に対応していく事が重要です。
20h:37m:53s ⇒ 36m 26s
※内部的に重い処理を複数回実行する処理(1 min 4.92 sec → 0.03 sec)
●●
振り返り：5.7アップグレードに伴う対応
重要な処理は、Query Playback等で予め確認しておくことをお勧めします。

オプティマイザー(条件フィルタリング)の調整
set global optimizer_switch='condition_fanout_filter=off';
9.01 sec ⇒ 0.94 sec
5 min 48.71 sec ⇒ 3 min 13.31 sec
その他、考慮事項： WHERE句で絞り込めるデータを､データ参照時に適切に絞りこめているかも適宜確認。
特定クエリーのみであれば、ヒント句での対応をお勧め。
●●
動的設定変数なので
オンラインで設定変更可能

Default Page Size 16K byteでは、行の最大長が約 8000 byte
[mysql]> show global variables like 'internal_tmp_disk_storage_engine';
+----------------------------------+--------+
| Variable_name | Value |
+----------------------------------+--------+
| internal_tmp_disk_storage_engine | MyISAM |
+----------------------------------+--------+
row size too large in mysql 5.7 query
InnoDB: Cannot add field `xxxxx` in table `tmp`.`#sql_be123_289` because after adding it, the row size is 8132
which is greater than maximum allowed size (8126) for a record on index leaf page.
https://bugs.mysql.com/bug.php?id=77398
Important
In MySQL 8.0.16 and later, on-disk internal temporary tables always use the InnoDB storage engine;
as of MySQL 8.0.16, this variable has been removed and is thus no longer supported.
https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_internal_tmp_disk_storage_engine
●●

振り返り：5.7アップグレード後の残作業
[sys]> select * from schema_redundant_indexes limit 10,1¥G
*************************** 1. row ***************************
table_schema: demo
table_name: shopping_order
redundant_index_name: shopping_id_idx
redundant_index_columns: shopping_id
redundant_index_non_unique: 1
dominant_index_name: shopping_detail_uq_idx
dominant_index_columns: shopping_id, shopping_detail_id
dominant_index_non_unique: 0
subpart_exists: 0
sql_drop_index: ALTER TABLE `demo`.`shopping_order` DROP INDEX ` shopping_id_idx `
1 row in set (0.22 sec)
1:不要なインデックスの削除
2:必要に応じ文字コード変換
3:PKが無い場合はPKを付与
[sys]> explain select * from demo.shopping_order where shopping_id = 1;
+----+-------------+----------------+------------+------+----------------------------------------+------------------------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+----------------+------------+------+----------------------------------------+------------------------+---------+-------+------+----------+-------+
| 1 | SIMPLE | shopping_order | NULL | ref | shopping_detail_uq_idx,shopping_id_idx | shopping_detail_uq_idx | 4 | const | 1 | 100.00 | NULL |
+----+-------------+----------------+------------+------+----------------------------------------+------------------------+---------+-------+------+----------+-------+
●●

参照: https://www.s-style.co.jp/jirei/case049.html
●●
Search: ElasticSearch
Cache: Redis
マルチマスター構成・シングルマスター構成を選択可能
今回はアプリケーション側の処理を考えシングルマスター構成を選択
PHASE2: InnoDB Cluster構成
Slave

●●
障害発生時も自動的に切り替え、
Tomcat等の再起動は不要で対応工数 “0”
データベースは障害発生時にグループ内で自動的にフェールオーバー
メンバーは自動的にPRIMARYを切り替え & 対応工数 “0”で機会損失を最小限に抑える
Slave

●●
mysql> show global variables like 'super_read_only';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| super_read_only | ON |
+-----------------+-------+
1 row in set (0.00 sec)
mysql> select * from emp where empno = 7369 for update;
ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option
so it cannot execute this statement
PRIMARYのみ書き込み可＝SECONDARYは参照のみ可
SUPER権限及び参照のみなので, SECONDARYノードでのロックは正直気にしていなかった。

SECONDARYでロックが発生すると…
Id: 1000
Id: 1001
Id: 1002
Id: 1000
Id: 1000
Id: 1001
Id: 1002
SYSTEM LOCK
Applier Threadでログの適用が出来ない。
= データに差異が発生してしまう。
●●

●●
05:07:29 [01] ...done
05:07:29 Finished backing up non-InnoDB tables and files
05:07:29 Executing LOCK BINLOG FOR BACKUP...
05:07:29 >> log scanned up to (2213658429613)
<SNIP>
17:47:34 >> log scanned up to (2213731733101)
17:47:35 >> log scanned up to (2213731733101)
17:47:36 >> log scanned up to (2213731733101)
17:47:37 >> log scanned up to (2213731733101)
xtrabackup:
Executing LOCK BINLOG FOR BACKUP
Id: 1000
Id: 1001
Id: 1002
Id: 1000Id: 1000
Id: 1001
Id: 1002
バックアップによるロック
LP #1527463: Waiting for binlog lock
https://bugs.launchpad.net/percona-server/+bug/1527463

●●
Bug #89247 Deadlock with MTS when slave_preserve_commit_order = ON.
Bug #86078 Bad Write Set tracking with UNIQUE KEY on a DELETE followed by an INSERT.
Applier ThreadにてXロックが発生
Id: 1000
Id: 1001
Id: 1002
Id: 1000Id: 1000
Id: 1001
Id: 1002
バグ関連のロック
その他参考資料： MySQL Parallel Replication by Booking.com
https://www.slideshare.net/JeanFranoisGagn/fosdem-2018-premysql-day-mysql-parallel-replication

バックアップを取得するのであれば
バックアップツールメモ
mysqldump データ量が少なければこれでOK
データ量が大きい場合は、バックアップ＆リストア時間がかかりすぎるので、
障害発生時に短期間でリカバリーする必用があるシステムには向いていない。
mysqlbackup 高速且つ、Default Lock Time Outが60秒なので安心。
backup-to-imageオプションはGroup Replicationとの相性は良いが、
バックアップサイズが2倍位になる事もあるので容量を確認。
xtrabackup 高速、且つ無償。LOCK BINLOG FOR BACKUPが気になる場合は、
スレーブを追加してバックアップをグループ外で取得した方が良いかもしれません。
Id: 1000
Id: 1001
Id: 1002
Id: 1000
Id: 1001
Id: 1002
Id: 1000
Id: 1001
Id: 1002
Id: 1000
Id: 1001
Id: 1002
レプリケーション
●●
◎
〇

MySQL Router
2019-06-10 16:38:39 metadata_cache INFO [7f1408738700] Metadata for cluster ‘singleCluster' has 1 replicasets:
2019-06-10 16:38:39 metadata_cache INFO [7f1408738700] 'default' (3 members, single-master)
2019-06-10 16:38:39 metadata_cache INFO [7f1408738700] 192.168.10.10:3306 / 33060 - role=HA mode=RW
2019-06-10 16:38:39 metadata_cache INFO [7f1408738700] 192.168.10.11:3306 / 33060 - role=HA mode=RO
2019-06-10 16:38:39 metadata_cache INFO [7f1408738700] 192.168.10.12:3306 / 33060 - role=HA mode=RO
2019-06-10 16:38:39 routing INFO [7f1408738700] Routing routing: singleCluster_default_ro listening on 3307 and named socket
/etc/mysqlrouter/mysqlro.sock got request to disconnect invalid connections: metadata change
2019-06-10 16:38:39 routing INFO [7f1408738700] Routing routing: singleCluster_default_rw listening on 3306 and named socket
/etc/mysqlrouter/mysql.sock got request to disconnect invalid connections: metadata change
●●
便利：ノードの追加, ノードの削除, 再起動などを自動認識してくれるので
運用コスト削減と高可用性を担保する事が可能。
ネットワークセグメントが異なり、DNSでの名前解決出来ない場合は、IPでの設定若しくは/etc/hostsで名前解決対応。
MySQL Routerは、select instance_name from mysql_innodb_cluster_metadata.instances;から接続情報を作成

MySQL Router: when Rebooting the Instance.
[root@ec2-app-01 ~]$ tail -n 30 /var/log/mysqlrouter/mysqlrouter.log
2019-06-10 16:37:48 metadata_cache WARNING [7f47e2bfd700]
Member ec2-db-12:3306 (d6021b8b-81f2-11e9-8932-010113880060) defined in metadata not found in actual replicaset
再起動時は自動的に割り振りから外してくれ、
上記のようなログが記録される。
長期間起動しない、若しくは永続的に停止する場合は
ログの生成を止める為にも、removeInstance()で
該当インスタンスを外す事も検討。
●●

●●
Bug #94057 EMPTY cluster-metadata-servers in state.json
{
"metadata-cache": {
"group-replication-id": "641d3645-1e10-11e9-8166-0800271b198a",
"cluster-metadata-servers": []
}
MySQL Router: when Reboot or Stop all
Instances at the same time.
{
"metadata-cache": {
"group-replication-id": "641d3645-1e10-11e9-8166-0800271b198a",
"cluster-metadata-servers": [
"mysql://ec2-db-10:3306",
"mysql://ec2-db-11:3306",
"mysql://192.168.10.20:3306"
]
}
MySQL Router 8.0.16にアップグレードしておく
Thank you to Ivan for this bug report.

その他、留意事項
1: 障害発生時の復旧方法の事前確認
新規ノード追加の時は特に気にしなくても良いが, サーバー障害時にグループ内のサーバーをmysqlbackupや
xtrabackup等の物理バックアップからリストアするとauto.cnfが再作成されてしまいUUIDが変わってしまう。
[mysql_innodb_cluster_metadata]> select mysql_server_uuid,instance_name from instances;
+--------------------------------------+----------------------+
| mysql_server_uuid | instance_name |
+--------------------------------------+----------------------+
| 1d22f998-d822-11e8-8932-01011388005e | ec2-db-10:3306 |
| 9392f3ac-875a-11e9-8932-01011388005f | ec2-db-11:3306 |
| d6021b8b-81f2-11e9-8932-010113880060 | ec2-db-12:3306 |
+--------------------------------------+----------------------+
[root@ec2-db-10]# cat /mnt/data/mysql/auto.cnf
[auto]
server-uuid=d6021b8b-81f2-11e9-8932-010113880060
cluster.rescan();
or
cluster.removeInstance();
cluster.addInstance();
"ec2-db-12:3306": {
"address": "ec2-db-12:3306",
"mode": "R/O",
"readReplicas": {},
"role": "HA",
"status": "(MISSING)"
●●

MySQL 192.168.10.13:3306 JS > cluster.removeInstance('cluster_admin@192.168.10.20:3306');
ERROR: The instance '192.168.10.20:3306' cannot be removed because it is on a '(Missing)' state.
Please bring the instance back ONLINE and try to remove it again. If the instance is permanently not reachable,
then you can choose to proceed with the operation and only remove the instance from the Cluster Metadata.
Do you want to continue anyway (only the instance metadata will be removed)? [y/N]: y
The instance '192.168.10.20:3306' is not reachable and it will only be removed from the metadata.
Please take any necessary actions to make sure that the instance will not rejoin the cluster if brought back online.
The instance will be removed from the InnoDB cluster. Depending on the instance
being the Seed or not, the Metadata session might become invalid. If so, please
start a new session to the Metadata Storage R/W instance.
The instance '192.168.10.20:3306' was successfully removed from the cluster.
MySQL 192.168.10.13:3306 JS > 停止済みのインスタンスをグループから削除する場合は、メタデータは更新されるが、
VARIABLESとオプションファイル(my.cnf)等は必要に応じてマニュアル更新する必用あり。
●●

1) Group Replicationに以下のエラーが記録されるが、シングルマスターモードであればOK
group_replication_auto_increment_increment = 1
auto_increment_increment = 1
auto_increment_offset = 2
[ERROR] Plugin group_replication reported: 'Group contains 3 members which is greater than
group_replication_auto_increment_increment value of 1. This can lead to an higher rate of transactional aborts.'
2) MySQL 8.0では(Fixed on 8.0.4)廃止。 MySQL5.7では無視して問題無い。
22019-05-25T13:53:35.037485+09:00 0 [Warning] Plugin group_replication reported: 'The member with address ec2-db-
12:3306 has already sent the stable set. Therefore discarding the second message.'
●●

●●
ソフトウエアの更新&バグ関連情報✓
Bugデータベースの確認
https://bugs.mysql.com/
高可用性ソリューションサービスの活用
https://www.s-style.co.jp/products/mysql_ha_solution#ha05
MySQLのオフィシャルサーポートを活用
https://www.s-style.co.jp/products/mysql

モニタリング
●●

モニタリング
通常のMySQL
ステータスモニタリング
データ同期状態の確認
performance_schema.replication_group_member_stats
- COUNT_TRANSACTIONS_IN_QUEUE
- COUNT_TRANSACTIONS_ROWS_VALIDATING ★
●●

●●
Slave

参考： Additional Feature in MySQL8.0
WL#10379: Group Replication: consistent reads
https://dev.mysql.com/worklog/task/?id=10379
WL#11123: Group Replication: hold reads and writes when the new primary
has replication backlog to apply
WL#10378: Group Replication: group single/multi primary mode change and
primary election
Smart Style Blog about InnoDB Cluster
https://www.s-style.co.jp/blog/tag/mysql-innodb-cluster/
●●

サマリー
■ MySQL Nativeなプラグインで可用性を向上させる事が可能
■ データベース障害発生時の接続変更やレプリケーション組み直し等は不要
■ 自動的なリカバリーにより、システム障害発生時の機会損失を削減
■ バックアップはそれぞれの特性を理解して、環境にあった方法を選択
■ mysqlshのrescan; removeInstance; addInstance;等の手順確認をお勧め
■ 事前検証と確認。安定稼働までは、定期モニタリングをお勧め
■ COUNT_TRANSACTIONS_ROWS_VALIDATINGのモニタリングをお勧め
■ インスタンス登録はIPでも可能だが、ホスト名での登録をお勧め(要名前解決)
■ 必要に応じてノウハウが豊富なスマートスタイルさん等にご相談をお勧め
■ MySQL Enterprise版の無制限サポートは外部DBAとしてお勧め
●●

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

有難うございました
●●

Locondo 20190703@inno db_cluster

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Locondo 20190703@inno db_cluster

Similar to Locondo 20190703@inno db_cluster (20)

More from Shinya Sugiyama

More from Shinya Sugiyama (18)

Locondo 20190703@inno db_cluster