tencent cloud

TDSQL-C for MySQL

動向とお知らせ
製品アップデート
製品お知らせ
初心者ガイド
製品概要
プロダクト概要
製品の強み
適用シーン
製品アーキテクチャ
製品仕様
インスタンスタイプ
製品機能一覧
データベースのバージョン
リージョンとアベイラビリティゾーン
基本概念
利用制限
利用ガイドの推奨事項
自社開発カーネル
カーネル概要
カーネルバージョンのアップデート情報
カーネル最適化バージョン
機能特性
パフォーマンス関連機能
セキュリティカテゴリの機能
安定性機能
分析エンジン特性
カーネル問題のチェックと修復
購入ガイド
課金概要
製品価格
クラスタを作成する
構成変更説明
未払いについての説明
継続支払いの説明
返金ポリシー
従量課金から年/月単位サブスクリプションへの変換
従量課金からServerlessへの変換
付加価値サービスの課金説明
料金請求書の確認
クイックスタート
データベース監査
概要
監査インスタンス一覧
監査サービスを有効化する
監査ログの確認
ログ配信
事後アラーム設定
監査ルールの変更
監査サービスを変更する
監査サービスを停止する
監査ルールテンプレート
監査タスクの照会
サブユーザーへのデータベース監査利用権限付与
Serverlessサービス
Serverless入門
サーバーレス版クラスタの作成と管理
伸縮性スケーリング管理ツール
Serverlessリソースパック
マルチAZデプロイ
設定を変更する
よくあるご質問
Serverlessコスト見積ツール
操作ガイド
操作概要
コンソールでのクラスタページビューの切り替え
データベース接続
インスタンス管理
設定を変更する
インスタンス形態管理
クラスタ管理
読み取り専用インスタンス管理 
データベースプロキシ
アカウント管理
DMC
DMC(データベース管理ツール)
パラメータ設定
マルチAZデプロイ
グローバルデータベース
バックアップとリストア
操作ログ
データマイグレーション
パラレルクエリ
列ストレージインデックス CSI
分析エンジン
データベースセキュリティと暗号化
モニタリングとアラーム
SQLの基本操作
以下のコマンドを実行して、TDSQL-C for MySQLに接続してログインします
Tag
実践チュートリアル
TDSQL-C for MySQL データベース監査の等級保護実践
非InnoDBテーブル問題のワンクリック移行検出処理方法
DTSによるデータベースバージョンのアップグレード MySQL 5.7から8.0へ
TDSQL-C for MySQL 使用規範
新版コンソール
データベースプロキシの複数接続アドレスによる複数ROグループの実現
データベースプロキシのメリット
ストレージの課金モードの選び方
DTSによるリモートディザスタリカバリの構築
クラスタ用VPCの作成
データ復旧の方法
CPU使用率の高騰問題の解決方法
サブユーザーへの監視データ閲覧権限付与方法
ホワイトペーパー
セキュリティホワイトペーパー
性能ホワイトペーパー
トラブルシューティング
接続関連
性能関連
よくあるご質問
基本概念
購入と課金
サポートされるフォーマット
接続とネットワーク
機能特性
コンソールの操作
データベーステーブル
パフォーマンスとログ
データベース監査
TDSQL-C for MySQLとTencentDB for MySQLの違い
関連契約
SLA
利用規約
TDSQL-C ポリシー
プライバシーポリシー
データ処理と安全プロトコル
汎用参考
標準と認証
用語一覧
お問い合わせ

purge binlogの性能最適化

PDF
フォーカスモード
フォントサイズ
最終更新日: 2025-12-30 16:14:39

機能説明

データベースにおいて、binlogはデータベース操作を記録するために使用されるログファイルであり、データベースの追加、削除、更新操作などを含みます。時間の経過とともに、binlogファイルはますます増加し、大量のディスクスペースを占有します。したがって、定期的なクリーンアップが必要であり、つまりpurge binlog操作です。しかし、purge binlogと通常のrotateおよび書き込みトランザクションが競合します。特に、binlogファイルの数が多い場合、purge binlog操作時にパフォーマンスの揺らぎを容易に引き起こす可能性があります。Tencent Cloudカーネルチームは、binlogファイルのクリーンアップシナリオの分析を通じて、purge binlogのパフォーマンスを最適化しました。
purge binlogとrotate binlogのLOCK_index競合を最適化し、rotate binlogがロックを取得できずにbinlogの書き込みを続けられないのを防ぎます。
現在、purge binlogがindex lockを保持している期間中に、binlogが256Mに達した後、rotate binlogが必要な時にロックを読み取れず、書き込みが停止します。index lockを取得するまで続けられません。上記の問題に対して、主な最適化は、rotate binlogがindex lockを読み取れない場合、rotate binlogを行わず、現在のbinlogファイルにbinlogを書き続けることです。その後、index lockを取得しようと試み続け、index lockを読み取るまでrotate binlogを行いません。
パージが必要なbinlogファイルの読み取り量を削減し、それによりロックを減らします。
purge binlogプロセスでは、パージが必要なすべてのbinlog内のGtid情報を読み取り、それをmysql.gtid executedテーブルに書き込む必要があります。そのため、パージ期間中はgtidの排他ロックを保持し続け、通常のトランザクションがgtidロックを取得できなくなることがあります。上記の問題に対し、主な最適化として、binlogリスト内の最後のbinlogファイルのgtidのみを読み取るように変更しました。これにより、gtidロックの保持時間を短縮し、通常のトランザクションへの影響を軽減します。
binlogの単一ファイル上限を10Gに引き上げ、それによりrotate binlogの回数を大幅に削減します
デフォルトのbinlogサイズは256MBです。5000QPSの負荷下では、約1.4秒ごとにローテートが発生し、各ローテートに10~20msかかります。現在、max_binlog_sizeは256MBから10G(オープンソースMySQLは最大1Gをサポート)まで拡張可能です。同じ負荷条件下では、56秒に1回のローテートとなり、indexロックの取得頻度を削減します。現在の戦略は1Gに設定されていますが、業務負荷の必要性に応じてmax_binlog_sizeのパラメータ値をさらに調整できます。

サポートバージョン

カーネルバージョン TDSQL-C for MySQL 8.0 3.1.12 以上。
カーネルバージョン TDSQL-C for MySQL 5.7 2.1.12 以上。

適用シーン

binlogファイルの数が多い場合、purge binlog操作を実行するとロック競合が発生し、業務用binlogの書き込みがブロックされるシナリオです。

使用説明

txsql_binlog_rotate_try_lock_index および txsql_binlog_rotate_try_lock_log パラメータを ON に設定し、txsql_binlog_purge_check_file_count パラメータの値を10に設定することで、本機能を使用できます。詳細なパラメータ説明は以下の通りです:
名称
グローバル設定の有効範囲
タイプ
デフォルト
値の範囲
説明
txsql_binlog_rotate_try_lock_index
グローバル
bool
ON
ON/OFF
ONに設定した後、binlog rotateを実行する際にindexファイルのロックを取得できない場合、今回のrotateを放棄します。
txsql_binlog_rotate_try_lock_log
グローバル
bool
ON
ON/OFF
ONに設定した後、binlog rotateを実行する際にbinlogロックを取得できない場合、今回のrotateを放棄します。
txsql_binlog_purge_check_file_count
グローバル
ulonglong
10
0-UINT64_MAX
purge binlogを実行すると、binlog indexファイルからbinlogファイル名を取得します。binlogの数が多い場合、この操作には時間がかかりますが、通常は1つのbinlogファイル名を取得するだけで目的を達成できます。このパラメータは取得するファイル名の数を制御し、0は制限なしを意味します。通常は10に設定すれば十分です。

ヘルプとサポート

この記事はお役に立ちましたか?

フィードバック