HammerDB 4.0がリリースされていた - リリースノートチェック - なからなLife
HammerDB 4.0がリリースされていた - 環境構築 - なからなLife
HammerDB 4.0がリリースされていた - 設定まわりの変化 - なからなLife
HammerDB 4.0がリリースされていた - ワークロードの実行 - なからなLife
HammerDB 4.0がリリースされていた - 複数インスタンスへの接続・負荷試験 その１ - なからなLife
の続きです。
HammerDB4.0のMySQL-OLTP（TPC-C）にバグがあった
前回のエントリの通り、GitHubにIssue上げたらソッコーで中の人が対処してくれて、v4.1には入ってきそうな勢いです。
どこをどう修正するかははっきりしていて範囲も狭いので、実際にソース直して試してみます。
さっそく試験。
条件は前回記述したものと同です。
なお、分散負荷を有効にした場合、このような出力になります。
- user1がモニタリングセッション。マスター（mysqlcpool.xmlではなくdictで指定した接続先）に接続して情報を取得し、結果を表示。
- 「CLIENT SIDE TPM」
- vuごと、各プロシージャの実行量を表示。
Vuser 1:Test complete, Taking end Transaction Count. Vuser 1:4 Active Virtual Users configured Vuser 1:TEST RESULT : System achieved 7674 NOPM from 23008 MySQL TPM Vuser 5:VU5 processed neworder 13622 payment 13602 delivery 1331 stocklevel 1392 orderstatus 1341 transactions Vuser 5:FINISHED SUCCESS Vuser 4:VU4 processed neworder 13572 payment 13755 delivery 1315 stocklevel 1321 orderstatus 1329 transactions Vuser 2:VU2 processed neworder 13734 payment 13631 delivery 1345 stocklevel 1377 orderstatus 1401 transactions Vuser 4:FINISHED SUCCESS Vuser 2:FINISHED SUCCESS Vuser 3:VU3 processed neworder 13699 payment 13592 delivery 1348 stocklevel 1325 orderstatus 1364 transactions Vuser 3:FINISHED SUCCESS Vuser 1:CLIENT SIDE TPM : neworder 7803 payment 7797 delivery 762 stocklevel 773 orderstatus 776 Vuser 1:FINISHED SUCCESS
（1）MySQL ソース1：レプリカ1構成
(1-1)すべてソース側に振る構成（レプリカへの接続設定は入れつつ、リクエストを投げない）
(1-2)参照のみはすべてリードレプリカ、更新ありはソース側に振る構成
(1-3)参照のみはソースとレプリカの2台に、更新ありはソース側に振る構成
(1-4)更新も双方に（エラーになるはず）
を試します。
Aurora MySQL マルチマスター（2台）構成
(2-1)更新も参照も全台に
を試します。
それ以外は、上記で済んでるはずなので。
結果
(1-1)すべてソース側に振る構成（レプリカへの接続設定は入れつつ、リクエストを投げない）
想定通り、ソース側にのみリクエストが飛んできます。
レプリカ側には、設定したvu数のセッションが貼られますが、リクエストは来ません。
(1-2)参照のみはすべてリードレプリカ、更新ありはソース側に振る構成
参照系の負荷を発生させるストアドプロシージャOSTATとSLEVが、リードレプリカ側だけに飛んできていることが、General Logから確認できました。
もちろん、更新系の処理はソース側のみに飛んできていました。
(1-3)参照のみはソースとレプリカの2台に、更新ありはソース側に振る構成
参照系の負荷を発生させるストアドプロシージャOSTATとSLEVが、ソースとリードレプリカの両方に飛んできていることが、General Logから確認できました。
もちろん、更新系の処理はソース側のみに飛んできていました。
(1-4)更新も双方に（エラーになるはず）
リードレプリカにも更新リクエストを投げていますので、想定通り、
Vuser 2:mysqlexec/db server: The MySQL server is running with the --read-only option so it cannot execute this statement
が大量に出力されます。
なお、「エラーで即終了＋リトライ」を繰り返すので、トータル処理回数はエラーがないときよりも大きな数字が報告されます。
(1-1)から(１-4)は、こんな感じです。
上2段：CloudWatch Logs Insightsで、ソースとレプリカに飛んできたリクエストのGeneral Logから、「OSTAT」「SLEV」ストアドプロシージャ（＝参照負荷）をCALLしているログを抽出した結果の件数推移
下1段：CloudWatch Metricsで、ソースとレプリカのCPU使用率、DB接続数の推移
４つの山になっているのが、順に試験（1-1）～（1-4）になっています。
(2-1)更新も参照も全台に
たしかに双方に更新参照両方のリクエストが届いていて、処理はされているのですが、だからこそ、デッドロック出まくりました。。。
ページレベルで競合するとデッドロックが検出されることは、Auroraのドキュメントにもはっきり書いてあるので、当然といえば当然。。。
まとめ
- HammerDB4.0の対MySQL用OLTPワークロードのクラスター対応にはバグがあるので、4.1？が出るまではソースを直接書き換えで対応が必要
- （修正版では）、コネクションプール設定で更新・参照ワークロードの向き先を設定可能。期待通りに動いた！
- Auroraマルチマスターに対して、２台のマスターに負荷をかけることはできたが、デッドロック頻発で意味のある数字は取れないと考えて良さそう。
PostgreSQL用はバグがないのがわかっていたし、あと試してみたいのはOracle RAC/ActiveDataGuardかなあ。
直近では検証する時間がなさそうですので、HammerDB4.0についての記事はいったんここで一区切りとします。