Percona Operator for MySQL based on Percona Server for MySQL 1.2.0（リリース日：2026年7月3日）

リリースハイライト

今回のリリースでは、クロスサイトレプリケーション、暗号化されたバックアップ、ストレージの自動サイズ変更といった主要機能が導入され、本番環境での利用に向けたOperatorの堅牢性が強化されました。さらに、Orchestrator API認証やVault暗号化シークレットの検証によってセキュリティが向上したほか、日常的な運用における数多くの改善も盛り込まれています。

Group Replicationクラスタのサイト間レプリケーション

これまで、Percona Server for MySQLクラスターはそれぞれが独立して存在していました。グループレプリケーションがクラスターノードを同期状態に保つクラスター内において、これは高可用性を実現する上で有効でした。しかし、災害復旧、移行、あるいは読み取り分散を目的としてMySQLを地理的に拡張・展開するためには、サイト間を接続してそれらの間でデータを複製するために、Operatorの外部で独自のツールを構築・保守する必要がありました。

クロスサイトレプリケーションは、Group ReplicationクラスターをMySQL InnoDB ClusterSetにリンクすることで、そのギャップを解消します。PerconaServerMySQLClusterSetという新しいCustom Resourceを使用して、Kubernetesでトポロジーを宣言的に管理します。このリソースでは、どのクラスターが参加するか、どれがプライマリとなるか、そしてレプリカがClusterSetに参加する時にどのようにデータを受け取るかを宣言します。

Operatorは、スタンドアロンのPercona Server for MySQLクラスターの場合と同様に、ClusterSetのプロビジョニングとライフサイクル管理を自動化します。ClusterSetのブートストラップ、レプリカクラスターの追加・削除、ステータスの更新、およびプライマリ変更時のスイッチオーバーを実行します。管理はMySQLプロトコルを介して行われるため、レプリカクラスターは、同一のKubernetesクラスター内、別のクラスター内、あるいはKubernetesの外部のいずれでも稼働可能です。

クロスサイトレプリケーションにより、以下のメリットが得られます：

• 迅速な復旧 - 障害発生時に、単にバックアップから復元するのではなく、別のリージョンにあるライブレプリカを昇格させる。
• リージョン読み取りスケーリング - 読み取りトラフィックはローカルで処理し、書き込みはプライマリで行う。
• 統合された運用 - 1つのCustom Resourceと、単一のクラスターに対して常に使用しているものと同じ宣言型モデル。

クロスクラスターレプリケーションのドキュメントで、ワークフロー、セットアップ、使用方法の詳細をご確認ください。

暗号化されたバックアップ

Percona Operator for MySQLを使用してバックアップデータを暗号化できるようになり、S3、GCS、またはAzureに保存されるバックアップファイルが保存時に保護されるようになりました。これにより、外部の暗号化ツールを追加したり、スケジュール実行やオンデマンド実行といったバックアップの実行方法を変更したりすることなく、コンプライアンス要件を満たすことができます。

Group Replicationおよび非同期レプリケーションのどちらのクラスタータイプでも、暗号化されたバックアップがサポートされています。

Operatorは、Percona XtraBackupのネイティブ暗号化を利用し、一連のワークフローを自動化します。ユーザーは暗号化キーを使用してKubernetes Secretを作成し、クラスターのCustom Resourceにおいて、グローバルレベルまたはストレージ単位でそのSecretを参照します。ストレージレベルの設定が優先されます。Operatorは、そのシークレットを使用して、バックアップ中にはバックアップストリームを暗号化し、同一クラスター上でのインプレースリストア中には自動的に復号します。

新しいクラスターや別のKubernetes環境での復元の場合は、復元リソースに同じ暗号化キーを指定してください。これは、OperatorがソースクラスターのSecretにアクセスできないためです。復元に使用されるキーは、バックアップの暗号化に使用したキーと一致している必要があります。キーを紛失した場合、バックアップを復元することはできません。

デフォルトの暗号化アルゴリズムはAES256です。セキュリティポリシーが別の暗号方式が求める場合や、パフォーマンスを調整したい場合は、containerOptions.args.xtrabackup内のPercona XtraBackupオプションを使用して、アルゴリズムや関連設定を上書きできます。

暗号化されたバックアップの詳細については、弊社ドキュメントをご覧ください。

ストレージの自動サイズ変更

バージョン1.2.0以降、Operatorは設定された閾値に基づき、Percona Server for MySQL PodのPersistent Volume Claim（PVC）のサイズを自動的に変更できるようになります。Operatorはストレージの使用量を監視し、定義された閾値を超えると、最大ストレージサイズに達するまでサイズ変更を実行します。

この改善により、以下のメリットが得られます：

• 需要に応じてストレージが拡張されるため、ディスク容量不足による停止が減少する
• キャパシティプランニングにおける推測に頼る場面を減らし、土壇場での修正を削減する
• 開発者やプラットフォームエンジニアの運用負荷を軽減する
• 必要な時のみ拡張を行うことによるコスト管理
• チームがデリバリーに集中できるよう、より予測可能な環境

ストレージの自動サイズ変更を有効にするためには、Custom Resourceのマニフェストを次のように編集します：

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

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

PVCのサイズ変更を外部のオートスケーラーに委任する

Operator独自のサイズ変更ロジックの代わりに、外部のストレージオートスケーラーを使用するようにOperatorを設定できるようになりました。この機能は、一元管理されたスケーリングポリシー、高度なスケーリングポリシー、またはアプリケーションをまたぐスケーリングポリシーを必要とする組織にとって有用な場合があります。

外部オートスケーラーを使用するためには、Custom Resourceのマニフェストでspec.storageScaling.enableExternalAutoscalingオプションをtrueに設定します。

spec:
　storageScaling:
　　enableExternalAutoscaling: true

ユーザーSecretで公開される接続詳細情報

アプリケーションをクラスターに接続する時、ServiceやSecretにまたがってエンドポイントや認証情報を探し回る必要はもうありません。今回のリリースでは、Operatorがルートユーザー用の専用Secretを作成・メンテナンスするため、アプリケーション開発者や管理者は、信頼できる単一の接続情報源を利用できるようになります。このSecretの名称は、-psuser-rootという形式になります（デフォルトは、ps-cluster1-psuser-root）。

SecretはOperatorによって管理され、リコンシリエーションの度に更新されるため、手動でのメンテナンスなしに常に最新の値を取得できます。host、port、uriの各フィールドはMySQLのプライマリServiceを直接指しており、フェイルオーバーによってプライマリが別のPodに移動した時には自動的に更新されます。

HAProxyまたはMySQL Routerを有効にしている場合、Secretにはproxy-host、proxy-port、proxy-uriの値も含まれるため、アプリケーションは追加の設定なしでプロキシ経由の接続が可能になります。これらのフィールドは汎用的なものであり、どのプロキシ技術が使用されているかは示されません。

LoadBalancer Serviceタイプでプロキシを公開し、外部IPが割り当てられると、Secretは、クラスター外からの接続用に、proxy-external-host、proxy-external-port、proxy-external-uriを追加します。

このSecretを、アプリケーションのPodにマウントしたり、CI/CDパイプラインで参照したり、あるいは、External Secretsと組み合わせて使用​​したりすることが可能です。現在どのような方法で認証情報を利用しているかに関わらず、今後はすべてを1か所で管理できるようになります。

Point-in-Time Recovery用のRestoreオブジェクトでのbinlog設定

新しいクラスターへのポイントインタイムリカバリを実行する時、PerconaServerMySQLRestoreオブジェクト内で直接binlogストレージを指定できるようになりました。ソース環境のバイナリログをリプレイするためだけにターゲットクラスター上でBinlog Serverを設定するのではなく、既存のbackupSource設定と併せてbinlogの場所を定義します。これにより、単一のリストアマニフェストに操作に必要なすべての情報が含まれるようになり、クラスター間でのポイントインタイムリカバリの設定が簡素化されます。

復元を開始すると、Operatorはそれらの設定で一時的なBinlog Serverを起動し、それを使用してオブジェクトストレージから必要なバイナリログを特定・取得します。そして、復元が完了すると、それを削除します。

この改善により、リストアの手順が簡素化されます。ソースクラスターでのバイナリログの収集と、ターゲットでのリストア中のバイナリログへのアクセスを分離することで、Operatorはディザスタリカバリや移行シナリオの計画・実行を大幅に容易にします。

ポイントインタイムリカバリは、引き続きテクニカルプレビュー機能です。現時点では本番環境での使用は推奨されませんが、ステージング環境やテストクラスターでこのワークフローを試し、フィードバックをお寄せいただくことをお勧めします。

ポイントインタイムリカバリおよび新しいクラスターへの復元については、弊社ドキュメントをご覧ください。

LoadBalancer ServicesにおけるNodePort割り当ての無効化

デフォルトでは、基盤となるロードバランサーがNodePortを必要としない場合であっても、KubernetesはすべてのLoadBalancer Serviceに対してNodePortを割り当てます。

今回のリリースにより、Operatorが作成するLoadBalancer Servicesにおいて、NodePortの割り当てを無効にできるようになりました。クラスターのCustom Resourceを以下の設定で更新してください：

spec:
　expose:
　　type: LoadBalancer
　　allocateLoadBalancerNodePorts: false

この設定は、LoadBalancer Serviceの動作をそのまま維持しつつ、KubernetesによるNodePortの確保を防ぎます。以下のような場合に役立ちます：

• ロードバランサーの実装がNodePortに依存していない
• 意図しないノードレベルでの公開を回避することによって攻撃対象領域を縮小したい
• 多数のLoadBalancerサービスを運用し、ポート枯渇を回避したい

HAProxyサイドカーコンテナの独立したリソース設定

HAProxy Podは、MySQLエンドポイントを監視する軽量なDNSポーリングコンテナである、mysql-monitサイドカーを含みます。それは、以前は、メインのHAProxyコンテナのリソース要求と制限を継承しました。しかし、サイドカーはHAProxy本体に比べてはるかに少ないリソースしか必要としないため、リソースが過剰に割り当てられている状態でした。

現在は、各HAProxyサイドカーコンテナのリソース要求と制限を個別に設定できるようになりました。Custom Resource内のspec.proxy.haproxy.sidecarResourcesサブセクションを使用し、各サイドカーに必要な値を指定します：

proxy:
　haproxy:
　　sidecarResources:
　　　mysql-monit:
　　　　requests:
　　　　　cpu: 50m
　　　　　memory: 64Mi
　　　　limits:
　　　　　cpu: 100m
　　　　　memory: 128Mi

この改善により、クラスターリソースをより効率的に利用し、それによってインフラストラクチャのコストを削減できるようになります。

Vault暗号化シークレットの検証

HashiCorp Vaultを使用した保存データの暗号化を有効にすると、OperatorはVault Secretを検証するようになりました。Secretが存在しない、あるいは無効である場合、クラスターのステータスに即座に明確なエラーが表示されるため、Podのログを詳細に調べることなく設定を修正できます。

この検証により、Helm統合チャートを使用するなどして、Vaultとデータベースクラスターを組み合わせてデプロイできるようになりました。Secretへの参照を事前に定義しておき、Secretが存在しかつ有効な状態になるまでOperatorに待機させてから、クラスターのセットアップを続行することができます。

詳しくは、configuring data-at-rest encryption with Vaultをお読みください。

クラスターの並列リコンシリエーションのサポートにより、運用効率を向上させる

リコンシリエーションは、クラスターをそのあるべき状態と同期させるためのKubernetesの仕組みです。以前は、Operatorは一度に1つのリコンシリエーションループしか実行しませんでした。この逐次処理では、同じOperatorによって管理されている他のクラスターは、更新を受信する前に現在のリコンシリエーションが完了するまで待機する必要がありました。

今回のリリースにより、Operatorは並列のリコンサイルをサポートし、複数のクラスターを同時に処理できるようになりました。Operatorのデプロイメントにおいて、環境変数 MAX_CONCURRENT_RECONCILESを使用して、並列リコンサイルの最大数を定義できます。

この機能強化により、特にマルチクラスター環境におけるスケーラビリティと応答性が大幅に向上します。

Operator接続用の設定可能なDNSサフィック

Operatorがサービス名を生成する時に使用するカスタムDNSサフィックスを指定できるようになりました。これは、OperatorがvclusterやカスタムDNS設定が適用されたクラスター内で実行する時に役立ちます。そのような構成では、デフォルトのcluster.localサフィックスが原因でドメイン名の解決が正しく行われず、その結果、PMMなどの外部サービスへの接続に失敗することがあります。Custom ResourceのclusterServiceDNSSuffixにクラスターのDNSサフィックスを設定することで、OperatorはDNS設定に適合したホスト名を生成します。これにより、サービスの検出可能性と、ワークロード間の適切な通信が確保されます。

認証によるOrchestrator APIアクセスの保護

Orchestrator HTTP APIは、非同期レプリケーションを使用するMySQLクラスターのコントロールプレーンです。フェイルオーバーやトポロジ変更、その他の重要な操作を処理します。

今回のリリースより、Orchestrator APIでは認証が必要になります。クライアントは接続時に有効なユーザー資格情報を提示する必要があり、認証されていないリクエストは拒否されます。

Operatorは、マウントされたSecretから認証情報を読み取り、自身のAPI呼び出しに対する認証を自動的に処理します。そのため、日常的なクラスター管理はこれまで通り継続して行えます。Orchestrator APIを直接呼び出すカスタム統合やスクリプトを使用する場合は、適切な認証情報を含める必要があります。

この変更は、承認された呼び出し元のみがフェイルオーバーやトポロジ操作を開始できるようにすることで、デプロイメントの堅牢性を高めます。その結果、MySQLクラスターに対する偶発的または悪意のある中断に対して、より強力な保護が実現します。

Orchestratorのフェイルオーバー動作を微調整する

これまでは、Operatorのデフォルトを超えてOrchestratorの動作を調整することはできませんでした。今回のリリースで、spec.orchestrator.configurationフィールドが有効になったため、Custom Resource内で直接クラスターごとにフェイルオーバー設定を調整できるようになりました。

OrchestratorのオプションはJSON文字列として指定します。
例えば、FailMasterPromotionOnLagMinutesオプションを使用すると、レプリケーションが遅延している場合にOrchestratorが新しいプライマリを昇格するまでの待機時間を制御できます。RecoveryPeriodBlockSecondsオプションを使用すると、フェイルオーバー後にリカバリをブロックする時間を指定できます。

spec:
　orchestrator:
　　enabled: true
　　configuration: '{"FailMasterPromotionOnLagMinutes": 30, "RecoveryPeriodBlockSeconds": 300}'

Operatorは、ユーザーの設定をOrchestratorの設定に統合します。spec.orchestrator.configurationフィールドを変更すると、Orchestrator Podは新しい設定を適用するためにローリング方式で再起動します。

Raftトポロジ、トポロジTLS、HTTP認証、フェイルオーバーフック、エイリアス検出クエリ、ストレージパスなど、Operatorが自律的に管理するオプションは予約されており、それらを設定しても無視されるため、クラスターの自動化は引き続き確実に動作します。

PMMにおけるマルチリージョンデプロイメントまたはマルチネームスペースデプロイメントのクラスタ監視の強化

異なるデータセンターにデプロイされたクラスターに対して、カスタム名を定義できるようになりました。この名前は、Percona Management and Monitoring (PMM) Serverがクラスターを接続済みとして正しく認識し、それらを単一のデプロイメントとして監視するのに役立ちます。同様に、PMM Serverは異なる名前空間に同じ名前でデプロイされたクラスターを個別のクラスターとして識別し、ダッシュボード上でパフォーマンスメトリクスを正しく表示します。

カスタム名を割り当てるためには、クラスターのCustom Resourceマニフェストで以下の設定を定義します：

spec:
　pmm:
　　customClusterName: testClusterName

Percona Server for MySQL 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 Server for MySQL 8.4をデプロイする時、デフォルトでinnodb_numa_interleaveをOFFに設定するようになりました。これにより、誤ったアラートが減少し、セキュリティが強化されたKubernetes環境でもMySQLが円滑に動作するようになります。

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

ドキュメントの更新

利用可能なすべてのオプションを含むように、HelmチャートのREADMEを更新しました。

非推奨、名称変更、削除

非推奨のオプション

spec.enableVolumeExpansionオプションは非推奨となりました。後方互換性のために引き続き機能しますが、バージョン 1.5.0で削除される予定です。代わりに、spec.storageScaling.enableVolumeScalingオプションを使用してください。

既知の制限

Binlog Serverイメージの互換性に関する通知

今回のリリースに含まれる新しいバージョンのBinlog Serverイメージは、以前のバージョンと互換性がありません。

Binlog Serverをアップグレードするためには、バイナリログの収集を新規に開始する必要があります。手順は以下の通りです：

1. ポイントインタイムリカバリのバイナリログ収集を停止する
2. 新しいフルバックアップを作成する
3. クラスター設定でバイナリログの保存先設定を変更する。新しいバケット、または既存バケット内の新しいプレフィックスを指定できます
4. Binlog Serverイメージを更新する
5. ポイントインタイムリカバリを再度有効にする

OpenShift 4.22 を使用する際の考慮事項

OpenShift 4.22以降、DockerHubとRed Hat Marketplaceで同じリポジトリ名を共有するリポジトリについて、完全修飾名ではない名前を持つイメージのプル方法が変更されました。デフォルトでは、タグはRed Hat Marketplaceからプルされます。完全修飾名ではないイメージ名を指定すると、ImagePullBackOffエラーが発生する可能性があります。

• OLMインストール：イメージは完全修飾名で提供され、Red Hat Marketplace／DockerHubレジストリからプルされます
• デフォルトのマニフェストを使用した手動インストール／アップデート：DockerHubのpercona-server-mysql-operatorリポジトリから確実にダウンロードできるように、イメージにはdocker.ioレジストリプレフィックスを使用する必要があります。

手動でのインストールまたは更新を行う場合は、以下の手順に従ってください：

1. Operatorリポジトリをクローンします：

   git clone -b v1.2.0 https://github.com/percona/percona-server-mysql-operator
   cd percona-server-mysql-operator

2. deploy/bundle.yamlファイルを編集します。
   ・OperatorのDeploymentカスタムリソースを特定します。
   ・spec.imageフィールドを以下のように更新します

   docker.io/percona/percona-server-mysql-operator:1.2.0

3. 更新されたdeploy/bundle.yamlファイルを適用します：

   oc apply --server-side -f deploy/bundle.yaml

4. Percona Server for MySQLをインストールします：

   oc create -f deploy/cr.yaml

アップグレードの手順については、アップデートに関するドキュメントに従ってください。

CRDの変更

• 新しいCRD PerconaServerMySQLClusterSetが追加されました

変更履歴

新機能

• K8SPS-127 - PVCの使用量を監視し、使用量が設定した閾値を超えた時にサイズ変更をトリガーする、自動ストレージスケーリングを追加しました。これにより、ディスク容量不足による停止を防ぎ、必要な時にのみストレージを拡張することにより手動での容量計画にかかる手間を削減できます。
• K8SPS-409 - S3、GCS、またはAzureに保存されるバックアップデータが、顧客管理キーによって保存時に保護されるように、暗号化バックアップを追加しました。
• K8SPS-496 - ロードバランサーがNodePortを必要としない場合に、Operatorによって作成されるLoadBalancer Servicesに対してNodePortの割り当てを無効にする機能を追加しました。
• K8SPS-508 - 新しいPerconaServerMySQLClusterSet Custom Resourceを介して、Kubernetesからの宣言的なトポロジ管理を伴うGroup Replicationクラスター間のクロスサイトレプリケーションを追加しました。
• K8SPS-512 - クラスターステータスにHAProxyのバージョン報告を追加し、クラスターのライフサイクルの初期段階からプロキシのバージョン情報を確認できるようにしました。これにより、テレメトリおよび監視との統合において、空の値ではなく正確なHAProxyのバージョンデータが確実に受け取れるようになります。
• K8SPS-627 - pmm.customClusterNameオプションが追加され、Percona Monitoring and Management (PMM) で監視されるクラスターにカスタム名を割り当てられるようになりました。PMMは、リージョンや名前空間をまたぐソースクラスターとレプリカクラスターを、ダッシュボード上で単一のデプロイメントとして、適切にグループ化できるようになります。
• K8SPS-689 - クラスターの接続詳細情報をOperatorが管理する単一のリソースとして公開する、専用のルートユーザーSecretを追加しました。

改善点

• K8SPS-19 - Orchestrator HTTP APIの認証を有効にし、承認されたクライアントのみがフェイルオーバーやトポロジ変更を開始できるようにしました。Operatorは自身の呼び出しにおいて認証情報を自動的に処理しますが、APIに直接アクセスするカスタムスクリプトでは、有効な認証情報を提供する必要があります。
• K8SPS-434 - アップグレードの進行中であってもOperatorが他のクラスターのリコンサイルを継続できるように、環境変数によって同時リコンサイルの最大数を設定する機能を導入します。これにより、長時間にわたるアップグレードが以前は他のすべてのリコンシリエーション作業を停滞させていたようなマルチクラスター環境において、応答性が向上します。
• K8SPS-46 - Operatorのデフォルトを変更することなく、カスタムのOrchestrator設定をOperatorに渡せる機能を追加しました。
• K8SPS-487 - 保存データの暗号化が有効な場合にSecretを検証し、それが欠落または無効な場合には明確なステータスエラーを報告するようにすることで、Vaultの暗号化Secret処理を改善しました。これにより、Vaultとデータベースクラスターを一緒にデプロイし、Podのログを詳細に調査することなく、設定上の問題を即座に把握できるようになります。
• K8SPS-497 - エントリーポイントスクリプトでSIGTERMを処理することによって、pt-heartbeatサイドカーのグレースフルシャットダウンを改善しました。MySQL Podは、削除やローリングアップデート中、ハートビートが継続している状態で終了猶予期間の満了を待つことなく、より迅速に終了するようになりました。
• K8SPS-503 - group_replication_clone_thresholdがクローンベースリカバリを必要とする場合にそれを反映するようにGroup Replicationのブートストラップログが改善されました。
  ブートストラップログが実際のリカバリ方法と整合するようになり、ユーザーにとってトラブルシューティングが分かりやすくなりました。
• K8SPS-525 - バックアップに失敗したPodのログにタイムスタンプを追加しました。これにより、ログエントリが、失敗したバックアップジョブのものか、それとも以前の実行時のものかを見分けることができるようになります。これにより、Podやサイドカーのログを確認する時に、バックアップの失敗を適切な試行と関連付けやすくなります。
• K8SPS-716 - PerconaServerMySQLRestoreオブジェクトのbackupSourceフィールドで、バイナリログストレージを指定する機能が追加されました。ターゲットクラスター上で事前にバイナリログストレージを設定することなく、単一のリストアマニフェストから新しいクラスターへのポイントインタイムリカバリを設定できます。
• K8SPS-742 - spec.proxy.haproxy.sidecarResourcesを介して、HAProxy Pod内のmysql-monitサイドカーコンテナに対する個別のリソース設定を追加しました。軽量な監視用サイドカーに対して、過剰なリソース割り当てを行うことなく適切なCPUおよびメモリの制限を設定でき、インフラコストを削減できます。

バグ修正

• K8SPS-296 - 非同期レプリケーションクラスターでのパスワード変更時に発生していた、未処理のエラーやスタックトレースに関するログ出力動作を改善しました。Operatorログに不要なリコンサイラーエラーが記録されることなく、パスワードローテーションが正常に完了するようになりました。
• K8SPS-454 - マイナーバージョンのアップグレード後、MySQLクラスタのプライマリ選出に失敗し、すべてのインスタンスがプライマリ不在のまま読み取り専用状態になってしまう問題を修正しました。Operatorはアップグレード後のトポロジ復旧を適切に処理するようになったため、クラスターは書き込み可能なプライマリを回復します。
• K8SPS-607 - PerconaServerMySQLRestoreオブジェクトを削除した後、Operatorのログに大量に出力されていたリコンサイラーエラーを修正しました。リストアリソースが削除されると、リストアコントローラーは適切にリコンサイルを停止するようになりました。
• K8SPS-638 - spec.mysql.clusterTypeがasyncに設定されている場合でもGroup Replicationプラグインと関連設定が読み込まれてしまう問題を修正しました。非同期クラスターにおいて、要求されていないGroup Replication設定がPodの仕様、ログ、または設定に表示されることはなくなりました。
• K8SPS-680 - クラスターの削除時に、mysql-0 Podが終了猶予期間が満了するまでTerminating状態で停止したままになる場合がある問題を修正しました。現在は、影響を受けるプラットフォームにおいてクラスターの削除が迅速に完了します。
• K8SPS-682 - MySQL 8.4において、NUMAインターリービングがデフォルトで有効になっていたことにより、セキュリティが強化されたポリシー下でコンテナのデプロイエラーが発生していた問題を修正しました。Operatorは、Podの初期化の安定性を確保するために、MPOL_INTERLEAVEの制限がアクティブなホストVM内では、このオプションを適切に制限するようになりました。
• K8SPS-683 - SmartUpdateの動作を修正し、OperatorがプライマリPodを直接削除するのではなく、明示的にスイッチオーバーを実行してからプライマリPodを更新するようにしました。これは、Group Replicationと非同期レプリケーションの両方に適用され、ローリングアップグレード中の中断を低減します。
• K8SPS-686 - unsafeFlags.backupNonReadyClusterを有効にしてリストアを行った後、クラスターがまだ初期化中であるにもかかわらず、スケジュールされたバックアップが開始する可能性があった問題を修正しました。現在、バックアップは、リストア完了後にデータベースの準備が整うまで待ちます。
• K8SPS-699 - 復元チェーンの構築時に増分チャンクの完全性を検証することによって、失敗したバックアップがチェーン内に存在する時の増分バックアップ復元を修正しました。復元を確実に成功させるために、失敗または不完全な増分バックアップはスキップされるようになりました。
• K8SPS-707 - spec.incrementalBaseBackupNameフィールドのバリデーションを強化し、増分バックアップをベースバックアップとして指定できないようにしました。Operatorは、サポートされていないネストされた増分チェーンを作成する代わりに、無効なベースバックアップの参照を拒否するようになります。
• K8SPS-709 - S3互換バケットに長期間の運用で大量のオブジェクトが蓄積された時に、binlogサーバーがクラッシュする問題を修正しました。Operatorは大量のbinlogをより確実に処理するため、ポイントインタイムリカバリはバケットの手動クリーンアップやPodの再作成を必要としません。
• K8SPS-739 - パスワード伝播の確認において、HAProxy.Sizeの代わりにRouter.Sizeを使用することにより、MySQL Routerクラスターのパスワード伝播を修正しました。ルーターベースのデプロイメントは、意図した通り、すべてのデータベースPodで認証情報を取得できるようになりました。
• K8SPS-741 - 不足しているシステムユーザーのパスワードを自動生成する前に、一部が事前作成されたユーザーSecretによって、Operatorが不完全な認証情報を内部Secretにコピーしてしまうという競合状態を修正しました。ユーザーが提供したSecretに必要なキーの一部しか含まれていない場合でも、MySQL Podが確実に起動するようになりました。
• K8SPS-744 - ブートストラップ中に、クラスター設定のカスタムreplica_parallel_workers値がデフォルト値で上書きされてしまう問題を修正しました。Operatorは、設定した並列アプライヤースレッド数をデフォルト値にリセットするのではなく、維持するようになりました。
• K8SPS-751 - Custom Resourceでspec.upgradeOptions.applyが設定されていない時に発生していたVersion Serviceのリクエストエラーを修正しました。テレメトリが有効なクラスターにおいて、リコンサイルループの度にバージョンチェック用エンドポイントに対してHTTP 500エラーが繰り返し発生することはなくなりました。
• K8SPS-755 - クラスター全体のクラッシュ前に別のPodがGroup Replicationのプライマリであった場合でも、Operatorが最初にmysql-0をブートストラップしないよう、AutoRecoveryのブートストラップ順序を修正しました。復旧において適切なメンバー順序が考慮されるようになり、クォーラム喪失後のデータ損失が回避されます。
• K8SPS-760 - spec.backupがCustom Resourceから完全に省略された時に発生していたOperatorのパニックを修正しました。backupセクションを持たないクラスターでも、コントローラーがクラッシュすることなく正常にリコンサイルが行われるようになります。

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

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

• Percona Server for MySQL 8.4.10-10.1
• Percona Server for MySQL 8.0.46-37.1
• XtraBackup 8.4.0-6.1
• XtraBackup 8.0.35-36.1
• MySQL Router 8.4.10
• MySQL Router 8.0.46
• HAProxy 2.8.18-1
• Orchestrator 3.2.6-22
• Percona Toolkit 3.7.1-4
• PMM Client 3.8.1
• Cert Manager 1.20.2
• Percona Binlog Server 0.3.1

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

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

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

• Google Kubernetes Engine (GKE) 1.33 - 1.35
• Amazon Elastic Kubernetes Service (EKS) 1.33 - 1.36
• OpenShift 4.18 - 4.22
• Minikube 1.38.1 with Kubernetes v1.35.1

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

Percona認定イメージ

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

Percona Operator for MySQL based on Percona Server for MySQL 1.2.0 リリースノート（Percona社ウェブサイト）：
https://docs.percona.com/percona-operator-for-mysql/1.2.0/ReleaseNotes/Kubernetes-Operator-for-PS-RN1.2.0.html

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

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