[db tech showcase Tokyo 2016] D24: データベース環境における検証結果から理解する失敗しないフラッシュ活用法 第三章 ~デ...Insight Technology, Inc.
フラッシュのGB単価はHDDと並び、オールフラッシュ導入が加速化する一方、インラインでの重複排除、圧縮機能のオーバーヘッド、メンテナンス / 障害時の影響など、気をつけなければいけない事は沢山あります。本セッションでは、オールフラッシュ製品(Pure Storage)上でOracle Databaseを稼働させた検証結果と生のデモンストレーションをベースに、DB on Pure Storageならではの活用法を考えます。
[db tech showcase Tokyo 2016] D32: SPARCサーバ + Pure Storage DB仮想化のすべらない話 〜 Exa...Insight Technology, Inc.
NTTぷらら様は、「柔軟に増減設できるDB基盤」と「コスト最適化」をキーワードに、DB仮想化をSPARCサーバ + Pure Storageの組み合わせで実現しました。更に現在、理想のDB基盤を実現するために、Exadata環境のリプレースも進めています。本セッションでは、検証結果や生のデモンストレーションに、スライドには書けない生々しい話を加え、理想のDB環境実現までの道のりをご紹介します。
Now a days, thousands of database are supporting many kind of Rakuten's services. and it is hard to manage many databases well. especially, backup and restore.
so, we are progressing new backup system for our databases.
I am going to share some know-hows and experiences that have been acquired with you
Oracle Databaseの既存バージョンの10gや11gOracle Zero Data Loss Recovery Applianceの登場で、ますます重要な機能となってきたOracle Recovery Managerについて、OTN人気連載シリーズ「しばちょう先生の試して納得!DBAへの道」の執筆者が語ります。RMANバックアップの運用例から、高速増分バックアップの内部動作とチューニング方法まで、出し惜しみなく解説します。
[db tech showcase Tokyo 2016] D24: データベース環境における検証結果から理解する失敗しないフラッシュ活用法 第三章 ~デ...Insight Technology, Inc.
フラッシュのGB単価はHDDと並び、オールフラッシュ導入が加速化する一方、インラインでの重複排除、圧縮機能のオーバーヘッド、メンテナンス / 障害時の影響など、気をつけなければいけない事は沢山あります。本セッションでは、オールフラッシュ製品(Pure Storage)上でOracle Databaseを稼働させた検証結果と生のデモンストレーションをベースに、DB on Pure Storageならではの活用法を考えます。
[db tech showcase Tokyo 2016] D32: SPARCサーバ + Pure Storage DB仮想化のすべらない話 〜 Exa...Insight Technology, Inc.
NTTぷらら様は、「柔軟に増減設できるDB基盤」と「コスト最適化」をキーワードに、DB仮想化をSPARCサーバ + Pure Storageの組み合わせで実現しました。更に現在、理想のDB基盤を実現するために、Exadata環境のリプレースも進めています。本セッションでは、検証結果や生のデモンストレーションに、スライドには書けない生々しい話を加え、理想のDB環境実現までの道のりをご紹介します。
Now a days, thousands of database are supporting many kind of Rakuten's services. and it is hard to manage many databases well. especially, backup and restore.
so, we are progressing new backup system for our databases.
I am going to share some know-hows and experiences that have been acquired with you
Oracle Databaseの既存バージョンの10gや11gOracle Zero Data Loss Recovery Applianceの登場で、ますます重要な機能となってきたOracle Recovery Managerについて、OTN人気連載シリーズ「しばちょう先生の試して納得!DBAへの道」の執筆者が語ります。RMANバックアップの運用例から、高速増分バックアップの内部動作とチューニング方法まで、出し惜しみなく解説します。
This presentation was used for Japan Container Days 2018.
I explained the important point to use the k8s on Production environment for Japanese Audience.
[db tech showcase Tokyo 2015] D33:Superdome X 上の SQL Server 2014 OLTP 検証結果と S...Insight Technology, Inc.
Windows Server 2012 R2 と SQL Server 2014 の Superdome X 上の正式サポートを前に、OLTP 検証ツールを用いて、ブレード数を、1、2、4、8 枚と順次増加させ、最大 16 NUMA Node 240 物理コア CPU 4TB メモリー上でスケールアップ性能検証を実施しました。このサイズでの検証は、米国本社でも実績がなく、検証過程で発生した問題点を、米国 Windows Server / SQL Server 開発チームにフィードバックを行うことが出来ました。このスケールアップ検証結果を発表します。現在、米国本社 SQL Server 開発チームでは、vNext (SQL Server 2016) の開発が進んでおり、この中でのインメモリー活用処理とクエリー・ストアー機能に関しての最新情報をお知らせします。
18. 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 |
+----------------------------------+--------+
Copyrights LOCONDO,Inc. All Rights Reserved.
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アップグレードに伴う対応
●●
19. 振り返り:5.7アップグレード後の残作業
Copyrights LOCONDO,Inc. All Rights Reserved.
[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 |
+----+-------------+----------------+------------+------+----------------------------------------+------------------------+---------+-------+------+----------+-------+
●●
20. Copyrights LOCONDO,Inc. All Rights Reserved.
参照: https://www.s-style.co.jp/jirei/case049.html
●●
Search: ElasticSearch
Cache: Redis
マルチマスター構成・シングルマスター構成を選択可能
今回はアプリケーション側の処理を考えシングルマスター構成を選択
PHASE2: InnoDB Cluster構成
Slave
21. Copyrights LOCONDO,Inc. All Rights Reserved.
●●
障害発生時も自動的に切り替え、
Tomcat等の再起動は不要で対応工数 “0”
データベースは障害発生時にグループ内で自動的にフェールオーバー
メンバーは自動的にPRIMARYを切り替え & 対応工数 “0”で機会損失を最小限に抑える
Slave
22. Copyrights LOCONDO,Inc. All Rights Reserved.
●●
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ノードでのロックは正直気にしていなかった。
24. Copyrights LOCONDO,Inc. All Rights Reserved.
●●
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
25. Copyrights LOCONDO,Inc. All Rights Reserved.
●●
Bug #89247 Deadlock with MTS when slave_preserve_commit_order = ON.
https://bugs.mysql.com/bug.php?id=89247
Bug #86078 Bad Write Set tracking with UNIQUE KEY on a DELETE followed by an INSERT.
https://bugs.mysql.com/bug.php?id=86078
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
27. MySQL Router
Copyrights LOCONDO,Inc. All Rights Reserved.
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;から接続情報を作成
28. MySQL Router: when Rebooting the Instance.
Copyrights LOCONDO,Inc. All Rights Reserved.
[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
2019-06-10 16:37:54 metadata_cache WARNING [7f47e2bfd700]
Member ec2-db-12:3306 (d6021b8b-81f2-11e9-8932-010113880060) defined in metadata not found in actual replicaset
2019-06-10 16:37:59 metadata_cache WARNING [7f47e2bfd700]
Member ec2-db-12:3306 (d6021b8b-81f2-11e9-8932-010113880060) defined in metadata not found in actual replicaset
再起動時は自動的に割り振りから外してくれ、
上記のようなログが記録される。
長期間起動しない、若しくは永続的に停止する場合は
ログの生成を止める為にも、removeInstance()で
該当インスタンスを外す事も検討。
●●
29. Copyrights LOCONDO,Inc. All Rights Reserved.
●●
Bug #94057 EMPTY cluster-metadata-servers in state.json
https://bugs.mysql.com/bug.php?id=94057
{
"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.
31. Copyrights LOCONDO,Inc. All Rights Reserved.
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)等は必要に応じてマニュアル更新する必用あり。
●●
その他、留意事項
32. Copyrights LOCONDO,Inc. All Rights Reserved.
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では無視して問題無い。
https://bugs.mysql.com/bug.php?id=87892
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.'
●●
その他、留意事項
33. Copyrights LOCONDO,Inc. All Rights Reserved.
●●
ソフトウエアの更新&バグ関連情報✓
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
37. 参考: 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
https://dev.mysql.com/worklog/task/?id=11123
WL#10378: Group Replication: group single/multi primary mode change and
primary election
https://dev.mysql.com/worklog/task/?id=10378
Smart Style Blog about InnoDB Cluster
https://www.s-style.co.jp/blog/tag/mysql-innodb-cluster/
Copyrights LOCONDO,Inc. All Rights Reserved.
●●
38. サマリー
■ MySQL Nativeなプラグインで可用性を向上させる事が可能
■ データベース障害発生時の接続変更やレプリケーション組み直し等は不要
■ 自動的なリカバリーにより、システム障害発生時の機会損失を削減
■ バックアップはそれぞれの特性を理解して、環境にあった方法を選択
■ mysqlshのrescan; removeInstance; addInstance;等の手順確認をお勧め
■ 事前検証と確認。安定稼働までは、定期モニタリングをお勧め
■ COUNT_TRANSACTIONS_ROWS_VALIDATINGのモニタリングをお勧め
■ インスタンス登録はIPでも可能だが、ホスト名での登録をお勧め(要名前解決)
■ 必要に応じてノウハウが豊富なスマートスタイルさん等にご相談をお勧め
■ MySQL Enterprise版の無制限サポートは外部DBAとしてお勧め
Copyrights LOCONDO,Inc. All Rights Reserved.
●●