Percona Operator for MySQL based on Percona XtraDB Cluster 1.20.0（リリース日：2026年6月5日）

新着情報一覧

• すべてのOperatorイメージでARM64を完全にサポート

セキュリティとコンプライアンス

• TLS証明書の自動ローテーション - ダウンタイムを最小限に抑え、Secret経由で更新

パフォーマンスと信頼性

• ストレージの自動リサイズ - ディスクがいっぱいになる前にPVCを拡張
• HAProxyのファイルディスクリプタ制限を設定 - ヘルスチェックがより高速かつ安定する
• バージョンに応じたjemallocパス選択 - PXCバージョンに応じた正しいライブラリパス
• Percona XtraDBクラスター8.4では、デフォルトでNUMAが無効になっている - Kubernetesでの警告が少なくなる

オペレーショナル・エクセレンス

• Operator Deploymentにおけるリーダー選出の設定が可能になりました - 不安定なネットワークにおける耐障害性を調整する

非推奨

• PMM2のサポートは非​​推奨となりました; PMM3への移行を計画（バージョン1.22.0で削除予定）。

その他

• 25件以上のバグ修正と安定性の向上

リリースハイライト

Percona Operator for MySQL based on Percona XtraDB Clusterの今回のリリースには、以下の新機能と改善点が含まれています：

ストレージの自動リサイズ

バージョン1.20.0以降、Operatorは、設定されたしきい値に基づいてPercona XtraDB Cluster PodのPersistent Volume Claims（PVC）のサイズを自動的に調整できます。Operatorはストレージ使用量を監視し、定義されたしきい値を超えると、最大ストレージサイズに達するまでサイズ変更をトリガーします。これにより、以下のメリットが得られます：

• 需要に応じてストレージが拡張されるため、ディスク容量不足による障害が減少
• キャパシティプランニングにおける推測の減少と、最終段階での修正作業の減少
• 開発者とプラットフォームエンジニアの運用負担を軽減
• 必要な時だけ拡張することでコストを管理
• より予測可能な環境により、チームは開発に集中できる

ストレージの自動リサイズを有効にするためには、Custom Resourceマニフェストを以下のように編集してください：

spec:
　storageScaling:
　　enableVolumeScaling: true
　　autoscaling:
　　　enabled: true
　　　triggerThresholdPercent: 80
　　　growthStep: 2Gi
　　　maxSize: "10Gi"

ワークフローとトラブルシューティングのヒントについては、弊社ドキュメントをご覧ください。

TLS証明書の自動ローテーション

Operatorが発行するTLS証明書を更新するための、時間のかかる手動の手順はもう必要ありません。今回のリリースでは、Operatorが証明書の更新を自動的に処理します。必要な作業は、新しいCA証明書、サーバー証明書、およびキー証明書をSecretオブジェクトを介してOperatorに提供することだけです。Operatorは更新をトリガーするために -newサフィックスを期待するため、Secretの名前は <既存のSecret>-newの形式にする必要があることに注意してください。次の調整ループで、Operatorは新しいTLS証明書を検出し、適切にそれらを更新します。

この自動化により、Percona XtraDB ClusterのTLS管理における運用上のオーバーヘッドの大きな原因が解消され、人為的ミスのリスクが大幅に軽減されます。

具体的な手順や内部構造については、弊社ドキュメントをご覧ください。

Operator Deploymentにおけるリーダー選出の設定が可能になりました

環境変数を使用して、Operator Deploymentのリーダー選出設定を調整できるようになりました。これは、例えばレイテンシが高いクラスタやリソースが限られたクラスタなどにおいて、Operatorがリーダー選出の失敗に遭遇した場合に役立ちます。

• 環境変数 PXCO_LEADER_ELECTION_LEASE_DURATION、PXCO_LEADER_ELECTION_RENEW_DEADLINE、PXCO_LEADER_ELECTION_RETRY_PERIODを使用して、リース取得と更新のタイミングを調整します。
• 環境変数 PXCO_LEADER_ELECTION_ENABLEDを使用して、シングルレプリカデプロイメントにおけるリーダー選出を有効または無効にします。
• 環境変数 PXCO_LEADER_ELECTION_LEASE_NAMEを使用して、リーダーロックにカスタムLeaseリソースを使用します。

利用可能な環境変数の詳細については、弊社ドキュメントを参照してください。

HAProxyのファイルディスクリプタ制限を設定

HAProxyは、外部のMySQLヘルスチェックを実行する時、チェックスクリプトを実行する前に、システム制限までのすべてのファイルディスクリプタ (FD) を閉じようとします。システムによってはこの制限が非常に高く設定されているため、HAProxyは数百万、あるいは数十億もの数値をループ処理することになります。これにより、CPU使用率の上昇、長時間の遅延、タイムアウトが発生します。

このリリースでは、HAProxyコンテナの起動前にエントリポイントスクリプトで安全なファイルディスクリプタ制限を設定します。デフォルトのFD制限値は1048576です。この制限は、環境変数 HA_RLIMIT_NOFILEを使用して変更できます。この値はチェックされ、無効な場合、Operatorはデフォルト値にフォールバックします。値が大きすぎる場合、Operatorはハードリミットのファイルディスクリプタ値を使用します。これにより、外部チェックが高速かつ安定し、予測可能になります。

HAProxy環境変数の設定方法については、ドキュメントを参照してください。

メモリ使用量を最適化するための、バージョンに応じたjemallocパス選択

Custom Resourceを使用してメモリ割り当てをjemallocに設定すると、OperatorはデプロイされたPercona XtraDB Clusterのバージョンに基づいて、jemalloc共有ライブラリへのパスを正しく設定します：

• バージョン8.4以降の場合、Operatorは/usr/lib64/libjemalloc.so.2を使用します。
• バージョン8.0の場合、jemallocへのパスは/usr/lib64/libjemalloc.so.1です。

Percona XtraDB Cluster 8.4は新規クラスタのデフォルトおよび推奨バージョンであるため、デフォルトのjemallocパスは/usr/lib64/libjemalloc.so.2に変更されます。

OperatorはイメージタグからPercona XtraDB Clusterのバージョンを判別します。Red Hat Container Registryやカスタムイメージなど、Percona XtraDB Clusterがsha256ダイジェストを使用して参照されているイメージをデプロイする場合、Operatorはバージョンを検出できず、デフォルトのjemallocパス /usr/lib64/libjemalloc.so.2にフォールバックします。これを回避するためには、Percona XtraDB Cluster 8.4へのアップグレードを検討するか、環境変数を使用してメモリアロケータを指定してください。

この変更により、メモリ割り当て設定が手動操作なしでスムーズに機能するようになります。

Percona XtraDBクラスター8.4では、デフォルトでNUMAが無効になっている

innodb_numa_interleaveは、複数のNUMA (Non Uniform Memory Access) ノードにメモリ割り当てを分散させるMySQLの設定変数です。MySQL 8.4では、特に大規模なInnoDBバッファプールを使用する場合に、NUMAアーキテクチャを採用したサーバーのパフォーマンスを向上させるため、この設定がデフォルトで有効になっています。

Kubernetesでは、一般的なセキュリティ制限により、コンテナがメモリ割り当てポリシーを変更することは許可されていません。MySQLがNUMAインターリーブを有効にしようとすると、Kubernetesは要求をブロックするため、警告や分かりにくいログメッセージが表示されることがあります。

Kubernetes用のクラウドサーバーのほとんどは、単一のNUMAノードしか持たないサーバーを使用しているため、このMySQL設定はコンテナ環境ではパフォーマンス上のメリットをもたらしません。MySQLの動作を予測可能にし、不要なノイズを削減するために、Operatorは、Percona XtraDB Cluster 8.4のデプロイ時に、デフォルトでinnodb_numa_interleaveをOFFに設定するようになりました。これにより誤報が減り、強化されたKubernetes環境でもMySQLがスムーズに動作することが保証されます。

Operator経由でカスタムMySQLオプションを渡すことによって、Percona XtraDB ClusterでNUMAインターリーブを有効にすることができます。ただし、これはNUMAポリシーを許可するKubernetes環境を必要とするため、その影響を十分に理解しておいてください。

OperatorはARM64アーキテクチャに完全対応しました

すべてのOperatorイメージがARM64に対応し、追加の設定なしでARMベースのクラスタをネイティブにサポートできるようになりました。

ベースバックアップ後のポイントインタイムリカバリにおけるバイナリログ可用性検証の改善

このリリース以降、Operatorはポイントインタイムリカバリ処理中にストレージにバイナリログが存在するかどうかを確認します。

クラスタをリストアし、新しいフルバックアップをベースラインとして取得してから、データベースに新しいデータが書き込まれる前にポイントインタイムリカバリを実行するという状況では、データベースにはまだバイナリログは存在しません。この場合のポイントインタイムリカバリの結果は、選択したpitr.typeによって異なります：

• latest - リストアは成功し、データベースはベースバックアップ自体によって取得された状態に戻されます。ポイントインタイムリカバリジョブはすべてのバイナリログをスキップし、このイベントをログに記録して正常に完了します。
• date - 要求された日時までロールフォワードするためのバイナリログがストレージに存在しないため、リストアは失敗します。
• transactionまたはskip - 指定されたGTIDを適用するためのバイナリログがストレージに存在しないため、リストアは失敗します。

ポイントインタイムリカバリの詳細については、ドキュメントを参照してください。

非推奨、名称変更、削除

PMM2のサポートは非推奨になりました

Operatorは、PMM2のサポートを非推奨にします。PMM2がサポート終了段階に入ったためです。PMM2は引き続き利用可能ですので、このバージョンを使用してデータベースの状態を監視することはできます。ただし、PMM3で提供されるすべての機能と修正を享受するために、PMM3への移行を計画することをお勧めします。手順については、PMM upgradeドキュメントを参照してください。

PMM2のサポートは、Operatorのリリース 1.22.0で終了します。

変更履歴

新機能

• K8SPXC-1076 - ディスク容量不足時のデータベースダウンタイムを防ぐため、PVCの自動リサイズ機能を追加しました。Operatorは、ユーザー定義のストレージ使用率しきい値を監視し、対応するCSIボリュームプラグインで自動的にサイズ拡張をトリガーします。
• K8SPXC-1389 - ユーザー管理などの操作コマンド実行時の接続再試行回数に制限を設けました。この最適化により、Operatorがデータベース接続の最大数を使い果たし、一時的な障害発生時にアプリケーションの可用性に影響を与えることを防ぎます。
• K8SPXC-1619 - 状態スナップショット転送（SST）の連続再試行回数を制限するための設定可能なしきい値を追加しました。この機能は、無限再起動ループが継続的に過剰なクラスタネットワーク帯域幅を消費し、ドナーノードのパフォーマンスを低下させることを防ぎます。
• K8SPXC-1728 - ARM64アーキテクチャ上のすべてのOperatorイメージを完全にサポートしました。これにより、ユーザーはコスト効率の高いARMベースのクラウドインスタンスおよびインフラストラクチャ上に高可用性データベースクラスタをデプロイできるようになります。
• K8SPXC-1754 - データベースクラスタのダウンタイムを必要とせずに、TLS証明書の自動かつシームレスなローテーションを有効化しました。Operatorは、クライアント接続やレプリケーショントラフィックを中断することなく、TLSシークレットの更新をスムーズに調整するようになりました。
• K8SPXC-1789 - データベースおよびユーティリティコンテナ内で、カスタムログローテーション設定のサポートを追加しました。これにより、ユーザーはログの保持ポリシー、ファイルサイズ、ローテーションスケジュールを正確に制御し、ストレージ使用量を効果的に管理できます。

改善点

• K8SPXC-804 - ログコンテナ出力においてPXCコンテナの再起動をマークすることで、ログの視認性を向上させました。
• K8SPXC-1318 - データベース復元ワークフローを開始する前に、ポイントインタイムリカバリターゲットの検証を追加しました。Operatorは、要求されたタイムスタンプが既存のバイナリログからアクセス可能であることを確認することで、リカバリーパスの失敗による不要なデータベースのダウンタイムを防ぎます。
• K8SPXC-1634 - Custom Resource定義のpitr.type設定パラメータに対する事前検証を導入しました。早期の構造検証により、復元プロセス中に指定された型の不一致が原因でクラスタが回復不能状態または破損状態に陥ることを防止します。
• K8SPXC-1635 - ポイントインタイムリカバリルーチンを実行する前に、pitr.gtidフィールドの検証を追加しました。この構造的な保護機能により、検証されていないGTIDターゲットまたは破損したGTIDターゲットがクラスタのリカバリステップを破損させたり、不要なアプリケーションのダウンタイムを引き起こしたりするのを防ぎます。
• K8SPXC-1679 - バックアップストレージの設定オプションを改善しました。このバックエンドの改良により、高度なバケットオプションの宣言がより明確かつ信頼性の高いものになりました。
• K8SPXC-1751 - ポイントインタイムリカバリ時に特定のバイナリログソースノードの選択に関してログの詳細度と可視性を向上させました。これらの追加の診断メッセージにより、クラスタ管理者はリカバリ操作中のログ同期の状態をより簡単に監視および監査できます。
• K8SPXC-1793 - すべてのポイントインタイムリカバリターゲットに対して、包括的なカスタムリソース定義（CRD）レベルの検証を追加しました。これは、誤ったターゲット日付や無効なフォーマットの指定を防ぎ、時間を節約し、データ状態の一貫性を維持します。
• K8SPXC-1805 - 不安定なネットワークにおける耐障害性を強化するために、Operatorのリーダー選出パラメータを完全に設定可能にしました。管理者は、リース期間と更新期限をカスタマイズして、意図しないOperatorのフェイルオーバーや一時的なAPIサーバーのクラッシュを防ぐことができます。
• K8SPXC-1828 - 突然の同時ノード電源オフによるデータ損失を防ぐために、自動化されたクラスタ全体のクラッシュリカバリメカニズムを強化しました。洗練されたロジックにより、最も大きくかつ最も正確なシーケンス番号を持つノードが、安全なプライマリブートストラップソースとして自動的に選択されます。
• K8SPXC-1834 - HAProxyエントリポイントにおけるファイルディスクリプタの管理方法を最適化し、パフォーマンスのボトルネックを回避しました。この修正により、HAProxyがヘルスチェック中に数千個の未使用ファイルディスクリプタを閉じようとするのを防ぎます。
• K8SPXC-1851 - 特定のデータベース復元シナリオにおいて、nilポインタの参照解除が発生する可能性のあるコードの脆弱性を修正しました。getStorageType処理ロジックが修正され、ストレージタイプの属性を評価する前に、ストレージタイプを安全に検証・確認するようになりました。これにより、実行時のパニックの発生が防止されます。
• K8SPXC-1862 - logrotateスクリプトにPercona XtraDB Cluster 8.4の監査ログコンポーネントのサポートを追加しました。これにより、バージョン8.4で監査ログ機能が正しく動作するようになります。
• K8SPXC-1873 - 柔軟なバックアップ設定を可能にするため、バケットの存在確認をオプションとしました。
• K8SPXC-1817 - プラグイン/コンポーネントの設定に関するドキュメントを作成しました。

バグ修正

• K8SPXC-1438 - 容量を汎用的な「G」単位で宣言するCSIストレージドライバーを使用する際、Operatorが不要なストレージサイズ変更を試みてしまう問題を修正しました。更新されたサイズ解析は、生の値を標準化されたKubernetes表記へ正確に変換することで、k3dなどのプラットフォームにおいて誤ったリサイズ処理が実行されるのを防ぎます。
• K8SPXC-1589 - APIサーバーとの通信が一時的に途絶えた時に、Operatorプロセスがスタックトレースを伴い予期せずクラッシュする問題を修正しました。円滑な自動リカバリを保証するために、リーダー選出の処理フローに、再接続時の追加検証および再試行処理が組み込まれました。
• K8SPXC-1626 - 指定したinternalTrafficPolicyパラメータが、生成されるKubernetes Serviceに適用されない問題を解決しました。Operatorはこの設定を考慮するようになり、クラスターエンドポイントに対して最適なリージョン間ネットワークルーティングが可能になりました。
• K8SPXC-1648 - 要求された値を切り上げた結果、現在のボリュームと同じ整数のGiB値になる場合に、ストレージ拡張処理がエラー状態になるバグを修正しました。Operatorは切り上げ後の値が同一であることを適切に検出し、StatefulSet仕様の無効な更新によるエラーを防止するようになりました。
• K8SPXC-1685 - 自動ボリューム拡張の検証が、基盤となるストレージクラスの機能と整合していなかった問題を修正しました。システムは、バックエンドのストレージインフラストラクチャへの変更を要求する前に、明示的なボリューム拡張設定を尊重するようになりました。
• K8SPXC-1700 - 新規生成されたTLS証明書の有効期限が、Operatorの初期化時刻に誤って関連付けられていた問題を修正しました。予期せぬ早期の有効期限切れを防ぐため、有効期限に関するメトリクスは、証明書の正確な作成日から適切に算出されるようになりました。
• K8SPXC-1724 - 大規模なデータベースデプロイメントにおいて、OperatorがアクティブなState Snapshot Transfer (SST) プロセスを早期に終了させてしまう競合状態を解決しました。タイムアウトの延長と実行チェックの強化により、1TBを超えるデータクローン操作が中断されることなく完了するようになりました。
• K8SPXC-1737 - CompareMySQLVersion検証ステップ中に発生する、リコンシリエーションルーチン内でのパニックを修正しました。バージョンチェックロジックを強化し、非構造化されたリリース識別子をエラーを発生させることなくスムーズに処理できるようにしました。
• K8SPXC-1784 - cert-managerバージョン1.18.0がインストールされている環境で発生していたローリング再起動の失敗を修正しました。シームレスなローテーション動作を確保するため、cert-managerの更新されたデフォルトの証明書ローテーションポリシーに円滑に適合するよう、Operatorが適用されました。
• K8SPXC-1796 - xtrabackupサイドカー経由でスケジュールされたバックアップからネイティブ圧縮オプションが除外されてしまうバグを修正しました。これにより、ストレージを節約するためのパラメータがバックアップ実行エンジンに確実に渡されるようになります。
• K8SPXC-1800 - 復元コンテキストにおいて一致するユーザーSecretトークンが存在しない場合に、ポイントインタイムリカバリ処理が失敗する不具合を修正しました。Operatorは、すべての認可コンポーネントを検証するため、事前に適切な検証および準備ジョブを実行するようになりました。
• K8SPXC-1821 - cronパッケージのバイナリ依存関係が解決されていないために、ARM64プラットフォームにおいてlogrotateプロセスがクラッシュし、コンテナが失敗する問題を修正しました。マルチアーキテクチャへの対応を確保し、ログローテーション処理においてランタイムユーティリティを安定して利用できるようにするため、コンテナの構成が書き直されました。
• K8SPXC-1822 - ポイントインタイムリカバリにおいて、単一のトランザクションが複数のファイルにまたがっている場合に、バイナリログコレクタが誤ってバックアップのギャップを報告する問題を修正しました。ログ解析プロセスが改善され、断片化されたトランザクションを正しく結合・認識できるようになり、誤ったギャップアラートや検証エラーを防げるようになりました。
• K8SPXC-1829 - MySQL 8.4でNUMAインターリーブがデフォルトで有効になっていたことにより、セキュリティが強化されたポリシー下でコンテナのデプロイエラーが発生していた問題を修正しました。Operatorは、Podの初期化の安定性を確保するため、MPOL_INTERLEAVEの制限が有効であるホストVM内において、このオプションを適切に制限するようになりました。
• K8SPXC-1830 - PMM 3.5およびMySQL 8.4のコンポーネントと併用する時にProxySQLのメトリック収集が失敗し、監視機能が停止していた問題を修正しました。シームレスなサービス監視のため、内部認証処理が更新され、caching_sha2_passwordのルールに完全対応しました。
• K8SPXC-1831 - メモリアロケータが古いバージョンのライブラリを探索しようとして起動に失敗していた問題を修正しました。OperatorはMySQLのバージョンを検出し、メモリアロケータライブラリへの正しいパスを使用します。
• K8SPXC-1847 - cert-managerによる自動CA証明書ローテーションによって既存のすべてのリーフ証明書が無効化され、クラスタのTLSが機能しなくなるバグを修正しました。OperatorはCA証明書のローテーションを能動的に検知し、依存するすべてのリーフTLS証明書を自動的に再発行することで、クラスター接続の失敗を防止します。
• K8SPXC-1861 - ポイントインタイムリカバリの処理において、不整合または不一致のあるGTID追跡カタログが生成されるデータ不整合のバグを解決しました。マスターレプリケーションのマッピング構築時にトランザクションの線形順序を維持できるように、ステートファイルアセンブリコードが強化されました。
• K8SPXC-1870 - 複数のレプリカでOperatorを実行した時に、webhookのTLS検証が断続的に失敗するバグを修正しました。Operatorは、最初の発行時に自己署名CAと証明書マテリアルをpxc-webhook-ssl Secretに永続化するようになりました。これにより、すべてのレプリカPodが起動時に競合する認証局を個別に生成するのではなく、同一の証明書データを再利用します。
• K8SPXC-1872 - latestオプションを使用してポイントインタイムリカバリを開始した時に、古いタイムラインの古いトランザクション履歴が誤ってリプレイされる可能性があったバグを修正しました。バイナリログフィルタの生成時にアクティブなクラスタのタイムライン名を明示的に評価するようにリストアジョブの設定を修正し、現在のバイナリログのみがリプレイされるようにしました。
• K8SPXC-1877 - ホスト間でログローテーションの粒度が異なることが原因で、バイナリログのソースノードを切り替える時に誤ったギャップ検出アラームが発生する問題を修正しました。コレクションコーディネーターは、ノードの移行中のクラッシュを防ぐために、ファイルインデックスではなくグローバルクラスタのGTIDステータスを確認するようになりました。
• K8SPXC-1892 - 同一のKubernetes名前空間内に複数の独立したデータベースクラスタが存在する場合にlatestRestorableTimeプロパティが誤って評価されるバグを修正しました。タイムスタンプのクロスコンタミネーションを防ぐため、個別のクラスタ名フィールドに基づいてバックアップクエリを明確に分離できるように、追跡フィルタが更新されました。

ドキュメントの改善

• Helmを使用してカスタマイズされたパラメータでOperatorをインストールする方法や、リリース名を上書きする方法に関する手順を追加しました。
• プラグインやコンポーネントを使用してMySQLを拡張する方法（概要および具体的な設定例を含む）を解説する新しい章をドキュメントに追加しました。

サポートされているソフトウェア

Operatorは、以下のソフトウェアを使用して開発およびテストが行​​われました：

• Percona XtraDB Cluster バージョン 8.4.8-8.1、8.0.45-36.1、5.7.44-31.65
• Percona XtraBackup バージョン 8.4.0-5.1、8.0.35-35.1、2.4.29
• HAProxy 2.8.18-1
• ProxySQL 2.7.3-1.3、3.0.6
• fluent-bit 5.0.6ベースのLogCollector
• PMM Client 2.44.1-1、3.8.0
• cert-manager 1.20.2

他のオプションでも動作する可能性がありますが、テストは行われていません。

サポートされているプラットフォーム

Percona Operatorは、CNCF認定の全てのKubernetesディストリビューションとの互換性を考慮して設計されています。リリースプロセスには、主要なクラウドプロバイダープラットフォームとOpenShiftを対象としたテストと検証が含まれています。詳細は以下をご覧ください：

• Google Kubernetes Engine (GKE) 1.33 - 1.35
• Amazon Elastic Container Service for Kubernetes (EKS) 1.33 - 1.35
• Azure Kubernetes Service (AKS) 1.33 - 1.36
• OpenShift 4.18 - 4.21
• Kubernetes 1.35.1ベースのMinikube 1.38.1

このリストには、リリースプロセスの一環としてPercona Operatorが具体的にテストされているプラ​​ットフォームのみが含まれています。その他のKubernetesのフレーバーおよびバージョンは、Kubernetes自体が提供する後方互換性に依存します。

Percona認定イメージ

以下の表で、Percona Operator for MySQL based on Percona XtraDB Clusterで使用できるPerconaの認定Dockerイメージをご確認ください。

Percona Operator for MySQL based on Percona XtraDB Cluster 1.20.0 リリースノート（Percona社ウェブサイト）：
https://docs.percona.com/percona-operator-for-mysql/pxc/ReleaseNotes/Kubernetes-Operator-for-PXC-RN1.20.0.html

Perconaサポート・コンサルティング

Perconaサポート・コンサルティングサービスはPercona Serverをご利用頂いているお客様が安心してお使い頂くために専門的なサポートを提供するサービスです。