MySQL 8.0 リファレンスマニュアル


MySQL 8.0 リファレンスマニュアル  /  ...  /  サーバーの停止プロセス

5.1.19 サーバーの停止プロセス

サーバーのシャットダウンプロセスは、次のように実行されます。

  1. シャットダウンプロセスが開始されます。

    これはいくつかの方法で開始できます。 たとえば、SHUTDOWN 権限を持つユーザーは mysqladmin shutdown コマンドを実行できます。mysqladmin は、MySQL によってサポートされているすべてのプラットフォーム上で使用できます。 オペレーティングシステムに固有のほかのシャットダウン開始方式も使用可能で、Unix ではサーバーが SIGTERM シグナルを受け取るとサーバーがシャットダウンします。 Windows 上でサービスとして実行中のサーバーは、サービスマネージャーからシャットダウンを指示されるとシャットダウンします。

  2. サーバーは必要に応じてシャットダウンスレッドを作成します。

    シャットダウンが開始された方法によっては、シャットダウンプロセスを処理するためのスレッドをサーバーが作成することがあります。 シャットダウンがクライアントによってリクエストされた場合、シャットダウンスレッドが作成されます。 シャットダウンが SIGTERM を受信したことによるものである場合、シグナルスレッドそれ自体がシャットダウンを処理したり、処理を行うための別のスレッドを作成したりすることがあります。 サーバーがシャットダウンスレッドを作成しようとしたが作成できない場合 (メモリーが不足する場合など)、診断メッセージが発行されてエラーログに示されます。

    Error: Can't create thread to kill server
  3. サーバーは新しい接続の受け入れを停止します。

    シャットダウン中に新しいアクティビティーが開始されるのを防ぐために、サーバーは通常、接続を listen するネットワークインタフェースのハンドラを閉じて新しいクライアント接続の受け入れを停止します。接続には TCP/IP ポート、Unix ソケットファイル、Windows 名前付きパイプ、および Windows の共有メモリーがあります。

  4. サーバーは現在のアクティビティーを終了します。

    クライアント接続に関連付けられている各スレッドについて、サーバーはクライアントへの接続を切断し、スレッドに強制終了のマークを付けます。 スレッドは、そのようなマークを付けられたことが通知されると終了します。 アイドル状態の接続のスレッドは、ただちに終了します。 ステートメントを現在処理中のスレッドは、その状態を定期的に検査するため、終了するのに時間がかかります。 スレッド終了についての追加情報について、特に、MyISAM テーブルで強制終了された REPAIR TABLE または OPTIMIZE TABLE 操作に関する指示については、セクション13.7.8.4「KILL ステートメント」を参照してください。

    オープン中のトランザクションがあるスレッドでは、トランザクションがロールバックされます。 スレッドが非トランザクションテーブルを更新している場合、複数行の UPDATEINSERT などの操作は完了前に終了する可能性があるため、テーブルを部分的に更新したままにしておくことができます。

    サーバーがレプリケーションソースサーバーの場合、現在接続されているレプリカに関連付けられているスレッドはほかのクライアントスレッドと同様に扱われます。 つまり、それぞれに強制終了のマークを付け、その状態を次回検査するときに終了します。

    サーバーがレプリカサーバーの場合、クライアントスレッドを強制終了としてマークする前に、レプリケーション I/O および SQL スレッドがアクティブであれば停止します。 SQL スレッドは、(レプリケーションの問題を起こすことを防ぐために) 現在のステートメントを完了することが可能で、そのあとで終了します。 SQL スレッドがこの時点でトランザクションの途中である場合、サーバーは現在のレプリケーションイベントグループ (ある場合) が実行を完了するか、ユーザーが KILL QUERY または KILL CONNECTION ステートメントを発行するまで待機します。 セクション13.4.2.10「STOP SLAVE | REPLICA ステートメント」も参照してください。 非トランザクションステートメントはロールバックできないため、クラッシュに対する安全性を持つレプリケーションを保証するにはトランザクションテーブルのみを使用してください。

    注記

    レプリカのクラッシュの安全性を保証するには、--relay-log-recovery を有効にしてレプリカを実行する必要があります。

    セクション17.2.4「リレーログおよびレプリケーションメタデータリポジトリ」も参照してください。)

  5. サーバーはシャットダウンするかストレージエンジンを閉じます。

    この段階で、サーバーはテーブルキャッシュをフラッシュして、オープン中のすべてのテーブルを閉じます。

    各ストレージエンジンは、管理するテーブルに必要なすべての動作を実行します。 InnoDB はバッファープールをディスクにフラッシュし (innodb_fast_shutdown が 2 である場合を除く)、現在の LSN をテーブルスペースに書き込み、その独自の内部スレッドを終了します。 MyISAM は、テーブルの保留中のインデックス書き込みをフラッシュします。

  6. サーバーが終了します。

管理プロセスに情報を提供するために、サーバーは次のリストに示す終了コードのいずれかを返します。 カッコ内のフレーズは、systemd がサーバーの管理に使用されるプラットフォームについて、systemd がコードに応答して実行するアクションを示します。

  • 0 = 正常終了 (再起動は行われません)

  • 1 = 正常に終了しませんでした (再起動は行われません)

  • 2 = 正常に終了しませんでした (再起動完了)


関連キーワード:  サーバー, 終了, 変数, 接続, 停止, プロセス, テーブル, リファレンス, 作成, 実行