[db tech showcase Tokyo 2017] D21: ついに Red Hat Enterprise Linuxで SQL Serverが使...Insight Technology, Inc.
?
いよいよリリースが間近に迫ったSQL Server 2017 Linux版。SQL Serverの第一人者 Dr. Kこと熊澤 幸生がリリース版を待ちきれずにRed Hat Enterprise Linux上で検証してみました。
Windows版と Linux版で果たしてSQL Serverの処理性能に差があるのか?注目の検証結果をいち早くお知らせします。
Oracle Databaseの既存バージョンの10gや11gOracle Zero Data Loss Recovery Applianceの登場で、ますます重要な機能となってきたOracle Recovery Managerについて、OTN人気連載シリーズ「しばちょう先生の試して納得!DBAへの道」の執筆者が語ります。RMANバックアップの運用例から、高速増分バックアップの内部動作とチューニング方法まで、出し惜しみなく解説します。
Zero Data Loss Recovery Applianceによるデータベース保護のアーキテクチャオラクルエンジニア通信
?
データ量の増大、業務の24時間化に伴い、従来のバックアップ?ソリューションではデータ保護のニーズをすべて満たせなくなってきています。これを解消すべくOracle Databaseの保護に特化して設計されたエンジニアド?システム、Zero Data Loss Recovery Applianceが登場しました。これからの時代のデータ保護テクノロジーに関して、アーキテクチャを中心に紹介します。
Oracle Databaseの既存バージョンの10gや11gOracle Zero Data Loss Recovery Applianceの登場で、ますます重要な機能となってきたOracle Recovery Managerについて、OTN人気連載シリーズ「しばちょう先生の試して納得!DBAへの道」の執筆者が語ります。RMANバックアップの運用例から、高速増分バックアップの内部動作とチューニング方法まで、出し惜しみなく解説します。
Zero Data Loss Recovery Applianceによるデータベース保護のアーキテクチャオラクルエンジニア通信
?
データ量の増大、業務の24時間化に伴い、従来のバックアップ?ソリューションではデータ保護のニーズをすべて満たせなくなってきています。これを解消すべくOracle Databaseの保護に特化して設計されたエンジニアド?システム、Zero Data Loss Recovery Applianceが登場しました。これからの時代のデータ保護テクノロジーに関して、アーキテクチャを中心に紹介します。
4. ? 2021 Database Technology Inc. All Rights Reserved. 4
待望のMDS HA ??
l これまでMDSはシングル構成 もしくはHA構成のセカンダリとしてしか構築
できませんでした。
l ?可?性を求めるお客様に採?されるには中々?いハードル。
l この?きな弱点を埋めたのが MDS HA
5. ? 2021 Database Technology Inc. All Rights Reserved. 5
MDS HA 検証
l 構築?操作 について
l バックアップ?リストア
l スイッチオーバ?フェイルオーバ
l パフォーマンス
l 番外
l HeatWave 検証結果
l MDS サービスへの今後の期待
6. ? 2021 Database Technology Inc. All Rights Reserved. 6
構築?操作 について
7. ? 2021 Database Technology Inc. All Rights Reserved. 7
MDS HA 構築?操作について
l構築???簡単? 以上?
lスイッチオーバー操作???簡単? 以上?
8. ? 2021 Database Technology Inc. All Rights Reserved. 8
HA構築で利?できる構成
l ?可?性を選択した場合でも、拡張オプションにて構成変更可能。
例) MySQL.VM.Standard.E3.1.8GB を選択した場合
9. ? 2021 Database Technology Inc. All Rights Reserved. 9
HA構築で利?できるシェイプ構成 の違いについて
l デフォルトで選択できる 構成
l MySQL.VM.Standard.E3.<OCPU>.<MEMORY>GB.Standalone
l MySQL.VM.Standard.E3.<OCPU>.<MEMORY>GB.HA
(※OCPU,MEMORYは選択したシェイプタイプにより変動)
l 違いは2つ
l HAの?は「sql_require_primarykey」がON
l HAの?が同じシェイプタイプのstandalone構成と?べて
「innodb_buffer_pool_size」が ?さい
例)
10. ? 2021 Database Technology Inc. All Rights Reserved. 10
サブネットについての注意
l マルチADリージョンに限り次の注意が必要
l MDS HAを配置するサブネットは「リージョナル」で作成すること
l 「可?性ドメイン固有」サブネットの場合
各MDSインスタンスが各ADではなく サブネットの属する各FDに配置。
※「リージョナル」サブネット実装以前に作成したサブネットを利?する際は注意が必要。
※東京リージョンは 2021年5?現在 シングルADリージョンのため 気にする必要はなし。
11. ? 2021 Database Technology Inc. All Rights Reserved. 11
バックアップ?リストア
12. ? 2021 Database Technology Inc. All Rights Reserved. 12
MDS HA バックアップ?リストア
l WEBコンソールを利?したバックアップ?リストアは
シングル構成のMDSと
ほとんど 同じ
l リストア時、シングルではリカバリするADを選択するが、HAの場合にはプライマリ
ノードが稼働するADを選択できるという意味の違いのみ
13. ? 2021 Database Technology Inc. All Rights Reserved. 13
スイッチオーバー?フェイルオーバー
14. ? 2021 Database Technology Inc. All Rights Reserved. 14
スイッチオーバー
l 構成等
l クライアント
APサーバ想定で Jmeter を利?
l 次の3つの処理を実?
l コネクションプールを張りSQL発?繰り返し
l 「接続、SQL発?、切断、10ms待機」
を繰り返し
l MySQLコマンドにてホスト名取得 繰り返し
15. ? 2021 Database Technology Inc. All Rights Reserved. 15
スイッチオーバーにおける影響
l コネクションプール接続+SQL発?繰り返し処理
l 「接続、SQL発?、切断、10ms待機」繰り返し処理
→切断
→?時接続不可
※平均2秒程度 最?6秒程度の接続不可時間が存在
16. ? 2021 Database Technology Inc. All Rights Reserved. 16
フェイルオーバー
l 意図的障害発?について
概要?メモリ枯渇による意図的な障害を発?させる。
l HA構成は?番?さなシェイプ(E3.1.8)を利?
l 10GB程度のデータを?意
l 複数同時セッションによる データソート処理実?
l 並?してスイッチオーバー検証時と同様の3処理も実?
※挙動確認?
OOM Killer
17. ? 2021 Database Technology Inc. All Rights Reserved. 17
フェイルオーバーによる影響
l アプリ側 DB接続状況
①???検証開始 特に何も発?せず(2分間)
②???3分半、SQLレスポンスなしを確認
③???4分間、DB接続エラーを確認(コネクションプールはここで切断)
④???2分間、DB接続及びSQL応答を確認
⑤???2秒間 DB接続エラーを確認
⑥???DB接続が可能となり、SQL応答あり
※②、③の状況はスワップ等 応答に時間のかかる状況若しくは ネットワークのサ
チレーションが発?したと推察される(OracleMDSプロダクトマネージャ様?解)
フェイルオーバー発?
切断
18. ? 2021 Database Technology Inc. All Rights Reserved. 18
フェイルオーバー時のMDS HA復旧について
l 障害により切り替わった元プライマリノードについては
?動で復旧、?動でHA構成上に復帰。
l 今回はOOM Killer による障害だった為、復旧は再起動のみで良かったと思わ
れ、復旧まで数分しか掛からなかった。
19. ? 2021 Database Technology Inc. All Rights Reserved. 19
AP 実装の注意
l コネクションプールを利?する際、?動再接続する設定は必須
l コネクションプールの再接続時間(インターバル時間)はシステムに影響
を与えない最?の値を推奨
l フェイルオーバーの場合には数分間接続が途絶する可能性が有ることを認
識しておく
20. ? 2021 Database Technology Inc. All Rights Reserved. 20
パフォーマンス
21. ? 2021 Database Technology Inc. All Rights Reserved. 21
パフォーマンス検証 環境?仕様
l クライアント
l OCPU?48 Memory?768GB Disk?500GB
l MDS シングル/HA
l OCPU?16 Memory?256GB Disk?300GB
l 利?構成?「MySQL.VM.Standard.E3.16.256GB.HA」のカスタム
l max_connections?100000 max_prepared_stmt_count 1000000 に変更
l ベンチマークソフト
l Tpcc-mysql ?成データ量 約15GB
23. ? 2021 Database Technology Inc. All Rights Reserved. 23
スイッチオーバー等によるパフォーマンス変化
l スイッチオーバー等によるMDS HAの性能劣化は無し
l マルチADの場合にAPから?た性能は変わる可能性がある
l AP サーバとMDS HA プライマリノードが違うAD配置となった場合、同じADに配置され
た場合より性能が落ちる可能性がある(ネットワークが遠くなる影響)
l 切り替わり時ADを変更したくないのであれば同?AD内FDでのMDS HA構成
も有効(可?性ドメイン固有サブネット)
24. ? 2021 Database Technology Inc. All Rights Reserved. 24
MDS HA 検証まとめ
l 構築、利?は極めて簡単
l スイッチオーバー時間は短時間
l フェイルオーバ時 ?動復旧
l パフォーマンスはシングルノードより限界値が低い
26. ? 2021 Database Technology Inc. All Rights Reserved. 26
番外?HeatWave 検証
l 旧名? MySQL Database Service Analytics Engine
l 詳しい機能説明は 割愛します
l 早い早いと喧伝されているが 本当か??分の?で確かめる?
27. ? 2021 Database Technology Inc. All Rights Reserved. 27
番外?HeatWave 検証 構築?使い?
l 構築は?常に簡単
l 利??法
l HeatWaveを利?する際の作業
1.テーブルの設定変更(1回だけ)
ALTER TABLE <TABLE> SECONDARY_ENGINE=RAPID;
2.データをロードする(起動ごとに必要、データ同期は?動)
ALTER TABLE <TABLE> SECONDARY_LOAD;
28. ? 2021 Database Technology Inc. All Rights Reserved. 28
番外?HeatWave 検証 パフォーマンス
l スタースキーマベンチマークのデータ を利?し検証
l データは6億件、サイズ 240GB、13クエリ応答時間
29. ? 2021 Database Technology Inc. All Rights Reserved. 29
番外?MDSサービスへの期待
l 再起動なしのバージョンアップ実装
l 構成変更(シェイプ?ディスクサイズ)の容易さ
l HA構成の柔軟性追加
l セカンダリノードへの読み取り?マルチプライマリ構成
l トランザクションログ利?のリカバリ
30. ? 2021 Database Technology Inc. All Rights Reserved. 30
御清聴ありがとうございました