MySQL 8.0 リファレンスマニュアル MySQL NDB Cluster 8.0 を含む
このページは機械翻訳したものです。
ALTER INSTANCEinstance_action
instance_action
: { | {ENABLE|DISABLE} INNODB REDO_LOG | ROTATE INNODB MASTER KEY | ROTATE BINLOG MASTER KEY | RELOAD TLS [FOR CHANNEL {mysql_main | mysql_admin}] [NO ROLLBACK ON ERROR] }
ALTER INSTANCE
は、MySQL サーバーインスタンスに適用可能なアクションを定義します。 このステートメントでは、次のアクションがサポートされています:
ALTER INSTANCE {ENABLE | DISABLE} INNODB REDO_LOG
このアクションは、InnoDB
redo ロギングを有効または無効にします。 redo ロギングはデフォルトで有効になっています。 この機能は、新しい MySQL インスタンスへのデータのロードのみを目的としています。 ステートメントはバイナリログに書き込まれません。 MySQL 8.0.21 で導入されました。
本番システムで redo ロギングを無効にしないでください。 redo ロギングが無効になっているときにサーバーを停止して再起動することは許可されていますが、redo ロギングが無効になっているときに予期しないサーバー停止ページが発生すると、データが失われ、インスタンスが破損する可能性があります。
ALTER INSTANCE [ENABLE|DISABLE] INNODB REDO_LOG
操作には排他的バックアップロックが必要で、これにより他の ALTER INSTANCE
操作が同時に実行されなくなります。 その他の ALTER INSTANCE
操作は、ロックが解放されるまで待機してから実行する必要があります。
詳細は、redo ロギングの無効化を参照してください。
ALTER INSTANCE ROTATE INNODB MASTER KEY
このアクションにより、InnoDB
テーブルスペースの暗号化に使用されるマスター暗号化キーがローテーションされます。 キーローテーションには、ENCRYPTION_KEY_ADMIN
または SUPER
権限が必要です。 このアクションを実行するには、キーリングプラグインをインストールして構成する必要があります。 その手順は、セクション6.4.4「MySQL キーリング」を参照してください。
ALTER INSTANCE ROTATE INNODB MASTER KEY
では、同時 DML がサポートされます。 ただし、CREATE TABLE ... ENCRYPTION
または ALTER TABLE ... ENCRYPTION
操作と同時に実行することはできず、これらのステートメントの同時実行によって発生する可能性のある競合を防ぐためにロックが取得されます。 競合するステートメントのいずれかが実行されている場合、別のステートメントを続行する前に完了する必要があります。
ALTER INSTANCE ROTATE INNODB MASTER KEY
ステートメントは、レプリケートされたサーバーで実行できるようにバイナリログに書き込まれます。
ALTER INSTANCE ROTATE INNODB MASTER KEY
の使用方法の詳細は、セクション15.13「InnoDB 保存データ暗号化」 を参照してください。
ALTER INSTANCE ROTATE BINLOG MASTER KEY
このアクションは、バイナリログの暗号化に使用されるバイナリログマスターキーをローテーションします。 バイナリログマスターキーの鍵ローテーションには、BINLOG_ENCRYPTION_ADMIN
または SUPER
権限が必要です。 binlog_encryption
システム変数が OFF
に設定されている場合、このステートメントは使用できません。 このアクションを実行するには、キーリングプラグインをインストールして構成する必要があります。 その手順は、セクション6.4.4「MySQL キーリング」を参照してください。
ALTER INSTANCE ROTATE BINLOG MASTER KEY
アクションはバイナリログに書き込まれず、レプリカでは実行されません。 したがって、バイナリログマスターキーローテーションは、MySQL バージョンの混在を含むレプリケーション環境で実行できます。 適用可能なすべてのソースサーバーおよびレプリカサーバーでバイナリログマスターキーの定期ローテーションをスケジュールするには、各サーバーで MySQL イベントスケジューラを有効にし、CREATE EVENT
ステートメントを使用して ALTER INSTANCE ROTATE BINLOG MASTER KEY
ステートメントを発行します。 現在または以前のバイナリログマスターキーのいずれかが危険にさらされている可能性があるためにバイナリログマスターキーをローテーションした場合は、該当するすべてのソースおよびレプリカサーバーでステートメントを発行して、即時のコンプライアンスを検証できます。
プロセスが正しく完了しない場合や、予期しないサーバー停止によって中断された場合の対処方法など、ALTER INSTANCE ROTATE BINLOG MASTER KEY
の追加の使用方法については、セクション17.3.2「バイナリログファイルとリレーログファイルの暗号化」 を参照してください。
このアクションは、コンテキストを定義するシステム変数の現在の値から TLS コンテキストを再構成します。 また、アクティブなコンテキスト値を反映するステータス変数も更新されます。 このアクションには、CONNECTION_ADMIN
権限が必要です。 TLS コンテキストの再構成の詳細 (コンテキスト関連のシステム変数やステータス変数など) は、サーバー側のランタイム構成および暗号化された接続の監視 を参照してください。
デフォルトでは、ステートメントはメイン接続インタフェースの TLS コンテキストをリロードします。 (MySQL 8.0.21 で使用可能な) FOR CHANNEL
句が指定されている場合、ステートメントは指定されたチャネルの TLS コンテキストをリロード: メイン接続インタフェースの場合は mysql_main
、管理接続インタフェースの場合は mysql_admin
。 様々なインタフェースの詳細は、セクション5.1.12.1「接続インタフェース」 を参照してください。 更新された TLS コンテキストプロパティーは、パフォーマンススキーマ tls_channel_status
テーブルで公開されます。 セクション27.12.19.11「tls_channel_status テーブル」を参照してください。
メインインタフェースの TLS コンテキストを更新すると、そのインタフェースにデフォルト以外の TLS 値が構成されていないかぎり、メインインタフェースと同じ TLS コンテキストが使用されるため、管理インタフェースにも影響する可能性があります。
デフォルトでは、RELOAD TLS
アクションはエラーでロールバックされ、構成値で新しい TLS コンテキストの作成が許可されていない場合は影響しません。 以前のコンテキスト値は、引き続き新しい接続に使用されます。 オプションの NO ROLLBACK ON ERROR
句が指定され、新しいコンテキストを作成できない場合、ロールバックは発生しません。 代わりに、警告が生成され、ステートメントが適用されるインタフェース上の新しい接続の暗号化が無効になります。
ALTER INSTANCE RELOAD TLS
ステートメントはバイナリログに書き込まれません (したがってレプリケートされません)。 TLS 構成はローカルであり、関係するすべてのサーバーに必ずしも存在するわけではありません。