Percona Operator for MySQL based on Percona XtraDB Cluster 1.19.0（リリース日：2026年1月19日）

リリースハイライト

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

Percona XtraDB Cluster 8.4の保存データの暗号化によるデータセキュリティの確保

保存データの暗号化により、物理メディアが侵害された場合でも、ディスクに保存された機密情報が不正アクセスから保護されます。これは、現代のデータベース環境におけるコンプライアンス、信頼性、セキュリティの基盤となる保護手段です。

Operatorは、keyring_vaultプラグインを使用して、HashiCorp VaultによるMySQL 8.0の保存データ暗号化をサポートしています。また、keyring_vaultコンポーネントを活用して、MySQL 8.4の保存データ暗号化もサポートするようになりました。

この機能強化により、Percona XtraDB Cluster 8.4の最新メジャーバージョンの豊富な機能セットを活用しながら、機密データのセキュリティを確保できます。これにより、運用の複雑さを増すことなく、コンプライアンス要件を満たし、重要な情報を保護できます。その方法については、configure data at rest encryption for Percona XtraDB Cluster 8.4をご確認ください。

Percona XtraDB Cluster 8.4 が完全サポートされました

Percona XtraDB Cluster 8.4は完全にサポートされており、本番環境での導入に推奨されます。このリリース以降、これがOperatorを使用するすべての新しいデータベース クラスターのデプロイメントのデフォルトバージョンになります。このサポートにより、最新機能、パフォーマンス向上、強化されたセキュリティのメリットを享受できるようになります。

TLS検証に独自のCA証明書を使用する

あなたの組織のカスタム認証機関 (CA) を使用して、バックアップおよびリストア中にS3ストレージとのTLS通信を安全に検証できるようになりました。

設定は簡単です。カスタムCAとS3ストレージで認証する証明書を保存するSecretを作成します。次に、このSecretを参照し、Operator Custom ResourceのcaBundleオプションでCA証明書を指定します。Operatorは、これに対してTLS通信を検証します。

設定例を以下に示します：

storages:
　minio-s3:
　　type: s3
　　verifyTLS: true
　　s3:
　　　caBundle:
　　　　name: minio-ca-bundle
　　　　key: tls.crt

この改善により、以下のことが実現します：

• 妥協のないセキュリティ – アイデンティティチェックをバイパスする必要はもうありません。
• 社内標準との整合性 – 社内で既に信頼されているCAを使用します。
• バックアップとリストアのフローの信頼性 – すべてのS3のやり取りが適切に検証されます。

独自のCA証明書の使用に関する詳細は、弊社のドキュメントをご覧ください。

cert-managerによって発行される証明書の有効期間を設定する

デフォルトでは、cert-managerは90日間有効な証明書を生成します。証明書の有効期間をより細かく制御できるようになり、新しいクラスタを作成する時にカスタム期間を設定できるようになりました。これにより、組織のセキュリティおよびコンプライアンスポリシーに準拠できます。

証明書の有効期間を設定するためには、以下のCustom Resourceオプションを使用します：

• .spec.tls.certValidityDuration – 生成された証明書の有効期間
• .spec.tls.caValidityDuration – 認証機関 (CA) の有効期間

tls:
　enabled: true
　certValidityDuration: 2160h
　caValidityDuration: 26280h

Operatorは証明書に最小有効期間を適用することに注意してください：

• TLS証明書の場合 – 1時間
• CA証明書の場合 – 730時間

また、証明書生成の問題を防ぐため、有効期間を1時間ちょうどに設定することは推奨しません。証明書の有効期間設定に関するルールと制限事項の詳細については、弊社のドキュメントをご覧ください。

この改善により、クラスターのセキュリティと安定性を維持しながら、証明書の有効期間を微調整できるようになります。

ProxySQLサイドカーコンテナのセキュリティコンテキスト

OperatorでProxySQLサイドカーコンテナのセキュリティコンテキストを定義できるようになりました。これにより、セキュリティ保護されていないサイドカーがPodの制限を回避するリスクが軽減されます。この改善により、ユーザーID、権限、ファイルシステムへのアクセスを直接設定できるようになり、コンプライアンスを確保し、Podのセキュリティを強化できます。

カスタムリソースでセキュリティコンテキストを設定します。例：

spec:
　proxysql:
　　sidecars:
　　　securityContext:
　　　　privileged: false

この変更により、デプロイメント全体でより安全なデフォルトが適用され、Podレベルでのセキュリティギャップが解消されます。

ProxySQLスケジューラによる負荷分散の改善 (テクニカルプレビュー)

Operatorは、クエリルーティングを改善するために、外部ツール pxc_scheduler_handlerと統合されました。この機能は現在テクニカルプレビュー段階であるため、本番環境で使用する前に、テスト環境またはステージング環境で試してみることをお勧めします。

このスケジューラを使用すると、PXCクラスター内でSQLクエリをルーティングする方法をより細かく制御できます：

• SELECTクエリ（FOR UPDATEを使用しない）は、設定に応じて、すべてのPXCノード、またはライター以外のすべてのノードにインテリジェントに分散されます。
• SELECT以外のクエリとSELECT FOR UPDATEステートメントは、ライターノードにルーティングされます。
• ライターロールを細かく管理する必要はありません。スケジューラは、常に1つのライターだけがアクティブになることを自動的に保証します。

これにより、次のようなメリットが得られます：

• クエリ負荷の分散によるパフォーマンスとスループットの向上
• 単一障害点のない信頼性の向上
• レプリケーション遅延やノードの問題の早期検出によるクラスタの健全性の向上
• リソースとハードウェアのより効率的な利用
• データベースを使用するすべての人にとって、よりスムーズで予測可能なエクスペリエンス

スケジューラの動作と設定に関する詳細は、弊社のドキュメントをご覧ください。

以前の内部スケジューラは、下位互換性を維持するため、デフォルトで有効になっています。よりスマートなクエリ処理のメリットを享受する準備ができたら、新しいものに切り替えることができます。

HAProxyバックエンドのヘルスチェック間隔とフェイルオーバー動作のカスタマイズ

HAProxyがノード障害を検出して対応するまでの時間を制御できるようになりました。HAProxyがフェイルオーバーを実行する間、デフォルトの20秒間待機する代わりに、ヘルスチェックを調整して、それを数秒に短縮することができます。つまり、アプリケーションの復旧が速くなり、ノードがダウンしてもユーザーがセッションのハングに悩まされることがなくなります。

これを実現するためにHAProxyの設定全体をオーバーライドする必要はもうありません。Operatorは、Custom Resource仕様でシンプルで直接的なオプションを提供します：

haproxy:
　healthCheck:
　　interval: 10000
　　rise: 1
　　fall: 2

チェックの実行頻度と、ノードを「ダウン」または「アップ」とマークする失敗または成功の数を調整することで、フェイルオーバーが高速化され、クライアント処理がよりクリーンになり、アップグレードが安全で環境に合わせて調整された校正が容易になります。

実行時にHAProxyからProxySQLに切り替える

Percona XtraDB Clusterを再デプロイすることなく、HAProxyからProxySQLへ切り替えることができるようになりました。以前は、起動時にのみProxySQLを選択する必要がありました。現在は、ProxySQLにはデフォルトの認証プラグインとしてcaching_sha2_passwordがあり、HAProxyから始めて、後でニーズの変化に応じてProxySQLに移行できる柔軟性が得られます。

今回のリリースでは、ProxySQLに新しいスケジューラが追加され、SQL認識の強化、読み取り/書き込みの分割の自動化、フェイルオーバーのよりインテリジェントな処理が可能になりました。これにより、クエリの高速化、信頼性の向上、そしてクラスタリソースの効率的な利用が実現します。

どちらのプロキシを選ぶべきでしょうか？

• HAProxy: 最小限の設定で軽量なTCPレベルのロードバランサーが必要な場合は、HAProxyを選択してください。読み取り/書き込み分割のためには、クライアントはクエリタイプに基づいて異なるHAProxyポートに接続する必要があることに注意してください。
• ProxySQL: 組み込みの読み取り/書き込み分割、高度なクエリレベルの制御、そしてすぐに使える自動フェイルオーバーロジックが必要な場合は、ProxySQLを選択してください。

各プロキシには、独自のリソース要件と利点があります。環境に適したプロキシの選択に関する追加のガイダンスと、リソース計画とベストプラクティスに関する詳細な推奨事項を提供しています。これらをよく確認し、運用とパフォーマンスのニーズに合った選択を行ってください。

プロキシを切り替えるためには、Custom Resourceを更新してhaproxy.enabledをfalseに、proxysql.enabledをtrueに設定します。変更を適用すると、Operatorは、関連するプロキシ Podを再起動して移行を処理します。

この改善により、実行時にプロキシの選択を制御できるようになり、ProxySQLにより、よりスマートなルーティングと回復力がOperatorに直接もたらされます。

ProxySQL 3のサポート

Percona Operator for MySQLを使用してProxySQL 3をデプロイできるようになりました。これにより、Kubernetes内でアプリケーションがMySQLに接続する方法をより柔軟に制御できるようになります。主なメリットは以下のとおりです：

• デュアルパスワードサポートにより、古いパスワードが有効な間に新しいパスワードを導入できます。そのため、ダウンタイムなしでパスワードをローテーションできます。
• イベントとクエリのログ機能が強化され、クエリの動作とアプリケーショントラフィックをリアルタイムで可視化できます。
• ProxySQLは、プリペアドステートメントにバインドされた実際の値をログに記録するようになりました。これにより、プレースホルダだけでなく渡されたデータも確認できるため、クエリをより効果的にデバッグできます。
• イベントログにProxySQLのバージョンと形式に関するメタデータが含まれるようになりました。これにより、Operator管理のデプロイメントにおけるアップグレード全体のログの追跡と監査が容易になります。

直接アクセスバックアップ：サイドカーによるパフォーマンスと信頼性の向上（テクニカルプレビュー）

デフォルトでは、OperatorはSST方式でバックアップを作成します。これにより、Percona XtraBackupを使用して別のバックアップPodが作成され、データベースノードはDonor状態になり、クライアント要求の処理が停止します。SSTバックアップは不可解なネットワークエラーによって失敗する可能性があり、根本原因の分析と復旧が困難になります。

バージョン 1.19.0以降では、XtraBackupサイドカーコンテナ経由でバックアップを作成できるようになりました。Operatorは、各Percona XtraDB Cluster Pod内にXtraBackupを含むサイドカーコンテナをデプロイします。このサイドカーコンテナはバックアップを作成し、リモートバックアップストレージにアップロードします。データベースPodは、その状態をDonorに変更せず、クライアント要求を受け入れ続けます。

サイドカー方式を使用すると、データに直接アクセスできるため、バックアップのパフォーマンスが向上します。サイドカーコンテナはデータベースPod内で常時実行されるため、ログやステータスに常にアクセスでき、トラブルシューティングが容易になります。

XtraBackupサイドカーコンテナバックアップ方式を有効にするためには、Operator DeploymentでPXCO_FEATURE_GATES=XtrabackupSidecar=true環境変数を設定してください。この機能はテクニカルプレビュー段階にあり、現在はクラウドストレージのみをサポートしています。テスト環境またはステージング環境でお試しいただき、フィードバックをお寄せください。

PVCボリュームのサポート、バックアップの暗号化、増分バックアップなどの機能強化は、今後のリリースで予定されています。

XtraBackupサイドカーコンテナバックアップ方式の詳細については、弊社のドキュメントをご覧ください。

バックアップ中は最新データのみを提供する

バックアップ中またはSST中にノードがデータを提供すると、ノードはDONOR状態になります。この時点で、ノードはクライアント接続を処理できなくなります。HAProxyの外部チェックは、DONORノードへの新規接続を正しくブロックしましたが、既存のセッションはアクティブなままになりました。それらの残留セッションでは、遅い結果や古い結果が返される可能性があります。

HAProxyのデフォルト設定に、on-marked-down shutdown-sessionsディレクティブが含まれるようになりました。HAProxyがノードをダウン状態とマークするとすぐに、すべてのアクティブな接続が直ちに閉じられ、クライアントは残りのアクティブなノードに再接続します。これにより、バックアップ中に最新のデータのみが提供されるようになります。

バックアップJobとリストアJobおよび関連するPodの自動クリーンアップ

Operatorは、バックアップおよびリストア操作ごとに専用のJobとPodを作成します。以前は、これらのJobとPodは操作が完了した後もクラスター内に残り、リソースを解放するために手動で削除する必要がありました。

今後は、このタスクをOperatorにオフロードできます。操作完了後のバックアップJodおよびリストアJodの有効期間 (TTL) を指定します。TTLが期限切れになると、OperatorはJodとそれに関連付けられたPodを自動的に削除します。

次のようにCustom Resourceを変更します：

backup:
　image: perconalab/percona-xtradb-cluster-operator:main-pxc8.0-backup
　ttlSecondsAfterFinished: 3600

この設定はグローバルです。すべてのオンデマンドバックアップおよびスケジュールバックアップ、そしてすべてのリストアに適用されます。

Operatorは信頼性も確保します。
バックアップまたはリストアが設定されたTTLよりも長くかかる場合、internal.percona.com/keep-jobファイナライザーを適用して操作を完了させます。操作がSucceededまたはFailedステータスで完了すると、ファイナライザーは削除され、Jobはクリーンアップされます。

この改善により、手動メンテナンスのオーバーヘッドが削減され、デバッグや監査の目的でプロセスの有効期間を制御できるようになり、クラスターの健全性と効率性を維持されます。不要なリソースの蓄積を減らすことで、運用がよりスムーズになり、メンテナンスのオーバーヘッドが削減され、本番環境での信頼性が向上します。

ポイントインタイムリカバリの準備のためのバックアップ識別の改善

バックアップにバイナリログギャップが含まれている場合、Operatorはバックアップストレージに.pitr-not-readyファイルを作成するようになりました。このファイルを使用すると、ストレージ内とバックアップオブジェクトの一覧表示時の両方で、ポイントインタイムリカバリに適したバックアップを簡単に識別できます。

リストアを開始する前に、Operatorはこのマーカーファイルをチェックし、安全でないリストアをブロックすることで、不完全なリカバリの試行からユーザーを保護します。必要に応じて、percona.com/unsafe-pitrアノテーションをRestoreオブジェクトに追加することで、この保護機能をオーバーライドできます。これは安全ではない設定であるため、このオーバーライドは注意して使用してください。

アプリケーションとデータベースクラスター間での共有データアクセスのために外部PVCをアタッチする

場合によっては、データベースには独自の内部ストレージ以上のものが必要になることがあります。例えば、参照ファイル、共有設定ファイル、またはデータベース外部で生成されたルックアップテーブルにアクセスする必要がありますが、クエリとプロシージャには依然として不可欠です。

Custom Resourceを使用して、既存の補助PVCをアタッチし、その外部データをクリーンかつ宣言的な方法でデータベース、ProxySQL、またはHAProxyポッドに直接マウントできるようになりました。

この設定例は、XtraDB Cluster Podに外部PVCをアタッチする方法を示しています：

pxc:
　extraPVCs:
　　- name: extra-data-volume
　　　claimName: my-extra-storage
　　　mountPath: /var/lib/mysql-extra
　　　readOnly: false

この改善により、内部データベースストレージを外部ドメインデータから分離し、共有データセットを個別に更新しながらも、Operatorの自動化と回復力のメリットを享受できる信頼性の高い方法が得られます。

Operatorによるパスワード生成のカスタマイズ

デフォルトでは、Operatorは英数字と特殊記号を使用してユーザーパスワードを生成します。MySQL Prometheus Exporterやmysqlshなどの一部のツールは特定の記号をサポートしていないため、それらのパスワードは無効になる可能性があります。

互換性とユーザーエクスペリエンスを向上させるために、Custom Resourceでパスワード生成パラメータをカスタマイズできるようになりました：

spec:
　passwordGenerationOptions:
　　symbols: "!#$%&()*+,-.<=>?@[]^_{}~"
　　maxLength: 20
　　minLength: 16

この機能強化により、自動パスワード生成の利便性を維持しながら、Operatorと統合するツールや環境へのコンプライアンスを確保できます。

Operatorでのメモリアロケータの設定

デフォルトでは、Percona Operator for XtraDB Clusterはシステムアロケータ (libc) を使用してメモリを管理します。これはほとんどの場合で機能しますが、jemallocやtcmallocなどの代替アロケータを使用すると、高トラフィックのワークロードにおけるパフォーマンスが向上し、断片化を軽減できます。

柔軟性を高めるために、Custom Resourceでメモリアロケータを直接設定できるようになりました：

spec:
　pxc:
　　mysqlAllocator: jemalloc

サポートされる値は次のとおりです：

• jemalloc
• tcmalloc
• libc (デフォルト、値が設定されていない場合に使用されます)

環境変数経由でメモリアロケータをすでに設定している場合、Operatorはその設定を尊重し、Custom Resource値の代わりにそれを使用します。

この機能強化により、既存の設定との互換性を維持しながら、クラスターのメモリ管理を微調整できます。

非推奨、名称変更、および削除

1.19.0で削除：

• proxysql.readinessDelaySec and proxysql.livenessDelaySec fields are removed as redundant

非推奨 (1.22.0で削除予定)：

• pxc.livenessDelaySec. Use pxc.livenessProbes.initialDelaySeconds
• pxc.readinessDelaySec. Use pxc.readinessProbes.initialDelaySeconds
• haproxy.livenessDelaySec. Use haproxy.livenessProbes.initialDelaySeconds
• haproxy.readinessDelaySec. Use haproxy.readinessProbes.initialDelaySeconds

変更履歴

新機能

• K8SPXC-1332 - S3ストレージへのバックアップ操作用にカスタムSSL証明書をロードする機能を追加しました。これにより、あなたの会社が承認・信頼する証明書を使用して、S3対応ストレージとの安全な通信が可能になります。
• K8SPXC-1494 - cert-managerによって作成されたTLS証明書の有効期間を設定する機能を追加しました。これにより、ユーザーは証明書のライフサイクルをカスタマイズし、特定のセキュリティ要件を満たすことができます。
• K8SPXC-1576 - バックアップの作成にSSTではなくXtraBackupサイドカーコンテナを使用する機能を追加しました。これにより、代替の、潜在的に効率的なバックアップ方法が提供されます。
• K8SPXC-1688 - 既存の補助PVCをデータベースおよびプロキシポッドのボリュームとしてマウントする機能を追加しました。これにより、外部データおよびストレージリソースとの統合が容易になります。
• K8SPXC-1733 - Custom Resourceを介して、長さや文字セットなどのパスワード生成パラメータをカスタマイズできるようになりました。これにより、パスワードに対する特定の要件を持つツールのスムーズな操作が保証され、Operatorの自動パスワード生成が活用されます。
• K8SPXC-1734 - 設定全体を上書きせずに調整できる、設定可能なHAProxyバックエンドヘルスチェックパラメータを導入しました。これにより、高可用性設定のパフォーマンスチューニングが簡素化されます。

改善点

• K8SPXC-735 - SQL対応ルーティングと効果的な読み取り/書き込み分割を実現するpxc_scheduler_handler ProxySQLスケジューラのサポートを追加しました。これにより、読み取り専用トラフィックをクラスター全体に分散し、書き込みリクエストを書き込みノードにのみルーティングすることで、リソースをより効率的に活用できます。
• K8SPXC-992 - 異なるコレクター間の潜在的な衝突を防ぐため、バイナリログの命名規則を改善しました。この更新された命名規則により、ストレージ内のバイナリログファイルの一意かつ一貫した識別が保証されます。
• K8SPXC-1144 - バイナリログのギャップが検出された場合、S3バックアップをPITR未対応としてマークするメカニズムを導入しました。これにより、ユーザーが不整合なバックアップを使用して無効なポイントインタイムリカバリを試行することを防ぎます。
• K8SPXC-1214 - 完了したバックアップジョブおよびリストアジョブとそれらに関連するポッドを自動的にクリーンアップするオプションを追加しました。この改善により、古いリソースを削除することでKubernetes APIへの負荷を軽減できます。
• K8SPXC-1319 - オペレーターが拡張され、異なるクラスターの複数のバックアップリストアを並行して実行できるようになりました。これにより、環境全体での同時リストア操作をブロックしていた以前の制限が解消されました。
• K8SPXC-1327 - MySQLのメモリアロケータを変更し、メモリ管理効率を向上する機能が追加されました。この変更により、PXCポッドの全体的なメモリフットプリントが最適化されます。
• K8SPXC-1373 - コアダンプ処理が改善され、SST後にクラッシュしたインスタンスがより確実に復旧できるようになりました。この機能強化は、予期しないサーバー障害の診断と復旧に役立ちます。
• K8SPXC-1431 - オンデマンドバックアップPVCの削除を正しく処理できるように、バックアップ削除ファイナライザーロジックが改善されました。
• K8SPXC-1470 - 既存のクラスター内でHAProxyとProxySQLを切り替える機能が追加されました。これにより、ユーザーはニーズの変化に合わせて負荷分散ソリューションをより柔軟に変更できるようになります。
• K8SPXC-1511 - キーリングボールトコンポーネントを介したPercona XtraDB Cluster 8.4の保存データの暗号化のサポートが追加されました。この変更により、MySQL 8.4の最新セキュリティアーキテクチャとの互換性が確保されます。
• K8SPXC-1525 - より一貫性のあるライブネスプローブパラメータを優先するため、pxc.livenessDelaySecオプションは非推奨になりました。Operatorは、Podのライフサイクル管理において標準プローブ設定を優先するようになりました。
• K8SPXC-1568 - Operatorのパスワード生成ロジックを更新し、最初の文字として「*」文字が使用されないようにしました。これにより、特定の認証プラグインやコマンドラインツールで発生する可能性のある問題を回避できます。
• K8SPXC-1594 - 操作中にコントローラーがブロックされないように、データベースアップグレードロジックを改善しました。これにより、アップグレードの実行中でもOperatorが他のクラスターの変更に応答し続けることが保証されます。
• K8SPXC-1628 - PXCイメージの代替メモリアロケータとしてtcmallocのサポートを追加しました。これにより、ユーザーはデータベースワークロードのメモリフットプリントを調整および削減するための追加オプションを利用できるようになります。
• K8SPXC-1647 - 様々な障害シナリオに対してより適切な診断情報を提供するために、garbdの拡張終了コードを実装しました。これにより、SSTおよび参加の問題の根本原因をより迅速に特定できるようになります。
• K8SPXC-1668 - ProxySQL 3のサポートを追加しました。これにより、ユーザーはロードバランサーの最新機能とパフォーマンス向上を利用できるようになります。
• K8SPXC-1683 - スマートアップデートテストをPXC 8.4およびPMM 3まで拡張し、最新バージョンへの安定したアップグレードパスを確保しました。
• K8SPXC-1703 - generateEmbeddedObjectMetaオプションのサポートを追加しました。これにより、サイドカーおよび追加PVCのテンプレート処理が改善されました。
• K8SPXC-1748 - 不要なGalera TOI (Total Order Isolation) イベントを回避するために、PITRコレクター内のランタイムCREATE FUNCTIONステートメントを削除しました。これにより、PITRサイドカーの起動時または再起動時にクラスターのパフォーマンスへの影響が軽減されます。

修正されたバグ

• K8SPXC-926 - マルチクラスター環境で、あるクラスターでのスマートアップデートの失敗により、Operatorが他のクラスターを管理できなくなる問題を修正しました。コントローラーは、独立したリソースに影響を与えることなく、アップデートの失敗をより適切に処理できるようになりました。
• K8SPXC-1379 - ProxySQLポッドの監視コンテナリソース値がPXCクラスター定義で指定された値を正しく反映しない問題を修正しました。Operatorは、ProxySQLリソース属性が監視サイドカーコンテナに適切に適用されるようにしました。
• K8SPXC-1424 - TLSシークレット内のCA証明書が、サーバー証明書の更新前に期限切れになる可能性がある証明書更新の問題を解決しました。cert-managerを使用する際に、CA証明書とサーバー証明書の更新間隔を揃えるようにOperatorロジックが更新されました。
• K8SPXC-1581 - リストア準備ジョブのオプションの順序を修正し、--defaults-fileがxtrabackupの最初のオプションとして渡されるようにしました。この修正により、リストアプロセス中にカスタム設定ファイルが正しく優先順位付けされるようになります。
• K8SPXC-1617 - ポイントインタイムリカバリ（PITR）における、繰り返されるテスト失敗の原因となっていたバイナリログギャップの問題を修正しました。データの整合性を確保し、ギャップを防ぐために、PITRリストアごとに完全バックアップを実行することがユーザーに推奨されるようになりました。
• K8SPXC-1632 - ポッドのセキュリティを強化するために、ProxySQLサイドカーコンテナに不足していたSecurityContext設定を追加しました。この変更により、すべてのサイドカーがクラスターの定義されたセキュリティ標準に準拠するようになります。
• K8SPXC-1655 - RHEL9ベースのPercona XtraDB ClusterイメージでLZ4圧縮を使用する時に発生するxtrabackupのエラーを修正しました。この修正は、オペレーティングシステム環境における最新の圧縮ライブラリとの互換性の問題に対処しています。
• K8SPXC-1686 - 無効なPercona XtraBackupイメージを提供すると失敗ステータスになるように、バックアップエラー処理が改善されました。バックアップオブジェクトが開始状態で無期限にハングアップするのを防ぐために、新しいタイムアウトフィールドが導入されました。
• K8SPXC-1687 - S3またはAzureに保存されたクラウドベースのバックアップを正しく処理およびコピーするように、copy-backup.shスクリプトを修正しました。これにより、サポートされているすべてのストレージタイプでユーティリティスクリプトが一貫して動作するようになります。
• K8SPXC-1701 - MySQL設定がリストア準備ジョブに正しくマウントされるようにしました。
  この修正により、リストアプロセスでクラスターで定義されたカスタムMySQL設定を使用できるようになります。
• K8SPXC-1702 - バックアップジョブのタイムゾーンをオーバーライドする機能を追加しました。これにより、タイムゾーン定義がないために時間に依存する操作が失敗する問題が解決されます。
• K8SPXC-1721 - コンテナの再起動時にCPU使用率が急上昇するのを防ぐために、リカバリループにスリープ間隔を追加しました。
• K8SPXC-1725 - HAProxyのデフォルト設定にon-marked-downシャットダウンセッションディレクティブを追加することで、バックアップまたは SST操作中にクラスターが停止したデータを返す可能性がある状況を修正しました。これにより、バックアップ中に最新のデータのみが提供されるようになります。
• K8SPXC-1726 - PMM 3クライアントの非互換性によって発生していた、Helm経由のOperator バージョン 1.18.0でのデプロイメントの破損を解決しました。この修正により、PMMの新しいバージョンに移行するユーザーにとって、よりスムーズなアップグレードパスが確保されます。
• K8SPXC-1760 - HelmチャートテンプレートのcrVersionフィールドの処理を修正しました。Operatorは、クラスター設定を生成する時に、values.yamlで定義されたバージョンを正しく考慮するようになりました。
• K8SPXC-1771 - クラスターの準備が完了していないためにバックアップが一時停止または再開された時に、バックアップコントローラーによって過剰なログが記録される問題を修正しました。これにより、ログの可読性が向上し、不要な診断ノイズが削減されます。
• K8SPXC-1772 - 一時停止されていないバックアップが‘Running’状態に移行せずに‘Starting’から‘Succeeded’に直接遷移する可能性がある状態遷移バグを修正しました。これにより、バックアッププロセスのステータスを正確に追跡し、可視化できるようになります。

ドキュメント改善

• K8SPXC-1747 - クラスターコンポーネントとOperatorで利用可能な環境変数に関する情報を含むドキュメントが改善されました。バックアップ削除のスロットリングを可能にするためのS3_WORKERS_LIMIT環境変数についてドキュメントを追加しました。
• K8SPXC-1661 - PMM 3がAPIキーではなくサービスアカウントを使用することを反映するようにOperatorドキュメントを更新しました。これにより、ユーザーは最新バージョンのPMMとの監視統合を正しく設定できるようになります。
• K8SPXC-1663 - ポイントインタイムリカバリ手順に関するドキュメントを改善しました。更新されたドキュメントでは、リカバリ手順が適切に区切られ、順序付けされているため、読みやすさが向上しています。

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

Operatorは、以下のソフトウェアを使用して開発およびテストされています：

• Percona XtraDB Cluster バージョン 8.4.7-7.1、8.0.44-35.1、および 5.7.44-31.65
• Percona XtraBackup バージョン 8.4.0-5.1、8.0.35-34.1、および 2.4.29
• HAProxy 2.8.17
• ProxySQL 2.7.3-1.2、3.0.1-1.2
• fluent-bit 4.0.1-1ベースのLogCollector
• PMM Client 2.44.1-1 および 3.5.0

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

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

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

• Google Kubernetes Engine (GKE) 1.31 - 1.33
• Amazon Elastic Container Service for Kubernetes (EKS) 1.32 - 1.34
• Azure Kubernetes Service (AKS) 1.32 - 1.34
• OpenShift 4.17 - 4.20
• Kubernetes 1.34.0ベースのMinikube 1.37.0

このリストには、リリースプロセスの一環として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.19.0 リリースノート（Percona社ウェブサイト）：
https://docs.percona.com/percona-operator-for-mysql/pxc/ReleaseNotes/Kubernetes-Operator-for-PXC-RN1.19.0.html

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

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