Linux 上の可用性グループに対して常に実行します。Operate Always On Availability Groups on Linux

このトピックに適用されますはいLinux に SQL ServerありませんAzure SQL DatabaseありませんAzure SQL Data Warehouseありません。並列データ ウェアハウスTHIS TOPIC APPLIES TO: yesSQL Server on LinuxnoAzure SQL DatabasenoAzure SQL Data WarehousenoParallel Data Warehouse

可用性グループをフェールオーバーする方法Fail over availability group

外部のクラスター マネージャーによって管理されている可用性グループにフェールオーバーするには、クラスター管理ツールを使用します。Use the cluster management tools to fail over an availability group managed by an external cluster manager. たとえば、ソリューションでは、Linux クラスターを管理するペースが使用されている場合を使用してpcsRHEL または Ubuntu に対して手動フェールオーバーを実行します。For example, if a solution uses Pacemaker to manage a Linux cluster, use pcs to perform manual failovers on RHEL or Ubuntu. Sles 使用crmです。On SLES use crm.

重要

通常の操作はフェールオーバーされません SSMS や PowerShell などの TRANSACT-SQL または SQL Server の管理ツール。Under normal operations, do not fail over with Transact-SQL or SQL Server management tools like SSMS or PowerShell. ときにCLUSTER_TYPE = EXTERNALにのみ使用できる値FAILOVER_MODEEXTERNALします。When CLUSTER_TYPE = EXTERNAL, the only acceptable value for FAILOVER_MODE is EXTERNAL. これらの設定では、すべてのアクションを手動または自動フェールオーバーは、外部のクラスター マネージャーで実行されます。With these settings, all manual or automatic failover actions are executed by the external cluster manager.

手動フェールオーバーの例Manual failover examples

外部のクラスター管理ツールを使用して可用性グループを手動でフェールオーバーします。Manually fail over the availability group with the external cluster management tools. 通常の操作では、TRANSACT-SQL でのフェールオーバーを開始できません。Under normal operations, do not initiate failover with Transact-SQL. 外部のクラスター管理ツールが応答しない場合は、フェールオーバーする可用性グループを強制できます。If the external cluster management tools do not respond, you can force the availability group to fail over. 手動フェールオーバーを強制する手順については、次を参照してください。手動移動クラスター ツールが応答性の高いです。For instructions to force the manual failover, see Manual move when cluster tools are not responsive.

2 つの手順で手動フェールオーバーを完了します。Complete the manual failover in two steps.

  1. 新しいノードにリソースを所有しているクラスター ノードから、可用性グループ リソースを移動します。Move the availability group resource from the cluster node that owns the resources to a new node.

    クラスター マネージャーでは、可用性グループ リソースを移動し、場所の制約を追加します。The cluster manager moves the availability group resource and adds a location constraint. この制約は、新しいノードで実行するリソースを構成します。This constraint configures the resource to run on the new node. いずれかの手動または自動フェールオーバー、将来を移動するために、この制約を削除する必要があります。You must remove this constraint in order to move either manually or automatically fail over in the future.

  2. 場所の制約を削除します。Remove the location constraint.

1.手動でフェールオーバーします。1. Manually fail over

という名前の可用性グループ リソースを手動でフェールオーバーするag_clusterという名前のクラスター ノードにnodeName2、お使いのディストリビューションに適切なコマンドを実行します。To manually fail over an availability group resource named ag_cluster to cluster node named nodeName2, run appropriate command for your distribution:

  • RHEL/Ubuntu 例RHEL/Ubuntu example

    sudo pcs resource move ag_cluster-master nodeName2 --master
    
  • SLES 例SLES example

    crm resource migrate ag_cluster nodeName2
    

重要

リソースを手動でフェールオーバーした後は、移動中に自動的に追加される場所の制約を削除する必要があります。After you manually fail over a resource, you need to remove a location constraint that is automatically added during the move.

2.場所の制約の削除2. Remove the location constraint

手動の移動中に、pcsコマンドmoveまたはcrmコマンドmigrateのリソースを新しいターゲット ノードに配置する場所の制約を追加します。During a manual move, the pcs command move or crm command migrate adds a location constraint for the resource to be placed on the new target node. 新しい制約を表示するには、リソースを手動で移動した後に次のコマンドを実行します。To see the new constraint, run the following command after manually moving the resource:

  • RHEL/Ubuntu 例RHEL/Ubuntu example

    sudo pcs constraint --full
    
  • SLES 例SLES example

    crm config show
    

今後の移動 (自動フェールオーバーを含む) が正常に行われるためには、場所の制約を削除しておく必要があります。You need to remove the location constraint so future moves - including automatic failover - succeed.

次のコマンドを実行して、制約を削除します。To remove the constraint run the following command.

  • RHEL/Ubuntu 例RHEL/Ubuntu example

    この例ではag_cluster-master移動されたリソースの名前を指定します。In this example ag_cluster-master is the name of the resource that was moved.

    sudo pcs resource clear ag_cluster-master 
    
  • SLES 例SLES example

    この例ではag_cluster移動されたリソースの名前を指定します。In this example ag_cluster is the name of the resource that was moved.

    crm resource clear ag_cluster
    

または、次のコマンドを実行して場所の制約を削除することもできます。Alternatively, you can run the following command to remove the location constraint.

  • RHEL/Ubuntu 例RHEL/Ubuntu example

    次のコマンドで、cli-prefer-ag_cluster-master は削除が必要な制約の ID です。In the following command cli-prefer-ag_cluster-master is the ID of the constraint that needs to be removed. sudo pcs constraint --full によってこの ID が返されます。sudo pcs constraint --full returns this ID.

    sudo pcs constraint remove cli-prefer-ag_cluster-master  
    
  • SLES 例SLES example

    次のコマンドでcli-prefer-ms-ag_cluster制約の id を指定します。In the following command cli-prefer-ms-ag_cluster is the ID of the constraint. crm config show によってこの ID が返されます。crm config show returns this ID.

    crm configure
    delete cli-prefer-ms-ag_cluster 
    commit
    

注意

自動フェールオーバーでは場所の制約が追加されないため、削除は不要です。Automatic failover does not add a location constraint, so no cleanup is necessary.

詳細:For more information:

クラスター ツールの応答がありません手動移動します。Manual move when cluster tools are not responsive

極端な場合、ユーザーがクラスターと対話するためのクラスター管理ツールを使用できない場合 (つまり、クラスターが応答していない、クラスター管理ツールがある障害のある動作)、ユーザーが手動でフェールオーバーする必要があります外部クラスター マネージャーをバイパスします。In extreme cases, if a user cannot use the cluster management tools for interacting with the cluster (i.e. the cluster is unresponsive, cluster management tools have a faulty behavior), the user might have to fail over manually - bypassing the external cluster manager. これはお勧めできませんの定期的操作は、クラスター管理ツールを使用してフェールオーバー操作を実行するクラスターが失敗している場合内で使用する必要があります。This is not recommended for regular operations, and should be used within cases cluster is failing to execute the failover action using the cluster management tools.

クラスター管理ツールを使用して可用性グループをフェールオーバーすることはできない場合、は、SQL Server ツールからフェールオーバーをこれらの手順に従います。If you cannot fail over the availability group with the cluster management tools, follow these steps to fail over from SQL Server tools:

  1. かどうかを可用性グループ リソースをクラスターによって管理されませんを確認します。Verify that the availability group resource is not managed by the cluster any more.

    • リソースをアンマネージ モードに設定しようとしてください。Attempt to set the resource to unmanaged mode. これは、リソースの監視を停止するリソース エージェントと管理に通知します。This signals the resource agent to stop resource monitoring and management. 例:For example:

      sudo pcs resource unmanage <**resourceName**>
      
    • アンマネージ モードに、リソースのモードを設定しようとすると、失敗した場合、リソースを削除します。If the attempt to set the resource mode to unmanaged mode fails, delete the resource. 例:For example:

      sudo pcs resource delete <**resourceName**>
      

      注意

      リソースを削除するときにも削除すべての関連する制約です。When you delete a resource it also deletes all of the associated constraints.

  2. セッション コンテキストの変数を手動で設定external_clusterです。Manually set the session context variable external_cluster.

    EXEC sp_set_session_context @key = N'external_cluster', @value = N'yes';
    
  3. Transact SQL を使用した可用性グループのフェールオーバーは失敗します。Fail over the availability group with Transact-SQL. 置換次の例で<**MyAg**>可用性グループの名前に置き換えます。In the example below replace <**MyAg**> with the name of your availability group. 対象のセカンダリ レプリカをホストする SQL Server のインスタンスに接続し、次のコマンドを実行します。Connect to the instance of SQL Server that hosts the target secondary replica and run the following command:

    ALTER AVAILABILITY GROUP <**MyAg**> FAILOVER;
    
  4. クラスター リソースの監視と管理を再起動します。Restart cluster resource monitoring and management. 次のコマンドを実行します。Run the following command:

    sudo pcs resource manage <**resourceName**>
    sudo pcs resource cleanup <**resourceName**>
    

データベース レベルの監視とフェールオーバーのトリガーDatabase level monitoring and failover trigger

CLUSTER_TYPE=EXTERNAL、フェイル オーバー トリガー セマンティクスは次のさまざまな WSFC と比較します。For CLUSTER_TYPE=EXTERNAL, the failover trigger semantics are different compared to WSFC. Wsfc では、SQL Server のインスタンスに可用性グループがある場合は、out の遷移ONLINEデータベースにより、エラーを報告する可用性グループのヘルスの状態します。When the availability group is on an instance of SQL Server in a WSFC, transitioning out of ONLINE state for the database causes the availability group health to report a fault. フェールオーバー アクションをトリガーする、クラスター マネージャーを通知これすます。This will signal the cluster manager to trigger a failover action. Linux では、SQL Server のインスタンスは、クラスターと通信できません。On Linux, the SQL Server instance cannot communicate with the cluster. データベース ヘルスの監視は、「外部で」行われます。Monitoring for database health is done "outside-in". かどうかのユーザーを選択してデータベース レベルのフェールオーバーの監視とフェールオーバー (オプションを設定してDB_FAILOVER=ON、可用性グループを作成するとき)、クラスターは、データベースの状態が確認ONLINEと監視のアクションを実行するたびにします。If user opted in for database level failover monitoring and failover (by setting the option DB_FAILOVER=ON when creating the availability group), the cluster will check if the database state is ONLINE every time when it runs a monitoring action. クラスター内の状態を照会するsys.databasesです。The cluster queries the state in sys.databases. いずれかの状態とは異なるONLINE、自動的に (自動フェールオーバーの条件が満たされた場合)、フェールオーバーがトリガーされます。For any state different than ONLINE, it will trigger a failover automatically (if automatic failover conditions are met). フェイル オーバーの実際の時間は、sys.databases で更新されているデータベースの状態と同様に、監視操作の頻度に依存します。The actual time of the failover depends on the frequency of the monitoring action as well as the database state being updated in sys.databases.

可用性グループをアップグレードします。Upgrade availability group

可用性グループをアップグレードする前に、ベスト プラクティスを確認で可用性グループのレプリカ インスタンスをアップグレードするです。Before you upgrade an availability group, review the best practices at Upgrading availability group replica instances.

次のセクションでは、可用性グループを含む Linux 上の SQL Server インスタンスでローリング アップグレードを実行する方法を説明します。The following sections explain how to perform a rolling upgrade with SQL Server instances on Linux with availability groups.

Linux 上のアップグレード手順Upgrade steps on Linux

可用性グループのレプリカが Linux での SQL Server のインスタンス上にある場合は、可用性グループのクラスターの種類はEXTERNALまたはNONEです。When availability group replicas are on instances of SQL Server in Linux, the cluster type of the availability group is either EXTERNAL or NONE. さらには、Windows Server フェールオーバー クラスター (WSFC) クラスター マネージャーで管理されている可用性グループEXTERNALです。An availability group that is managed by a cluster manager besides Windows Server Failover Cluster (WSFC) is EXTERNAL. Corosync とペースでは、外部のクラスター マネージャーの例を示します。Pacemaker with Corosync is an example of an external cluster manager. クラスター マネージャーがありませんがある可用性グループがクラスターの種類NONEアップグレード手順は、こちらは、クラスターの種類の可用性グループの特定EXTERNALまたはNONEです。An availability group with no cluster manager has cluster type NONE The upgrade steps outlined here are specific for availability groups of cluster type EXTERNAL or NONE.

  1. 開始する前に、各データベースをバックアップします。Before you begin, backup each database.
  2. セカンダリ レプリカをホストする SQL Server のインスタンスをアップグレードします。Upgrade instances of SQL Server that host secondary replicas.

    a.a. 非同期のセカンダリ レプリカを最初にアップグレードします。Upgrade asynchronous secondary replicas first.

    b.b. 同期セカンダリ レプリカをアップグレードします。Upgrade synchronous secondary replicas.

    注意

    のみの場合、可用性グループ非同期レプリカ - をデータの損失を回避するのには 1 つのレプリカを同期に変更しが同期されるまでを待ちます。If an availability group only has asynchronous replicas - to avoid any data loss change one replica to synchronous and wait until it is synchronized. このレプリカをアップグレードします。Then upgrade this replica.

    b.1.b.1. アップグレードの対象となるセカンダリ レプリカをホストしているノード上のリソースを停止します。Stop the resource on the node hosting the secondary replica targeted for upgrade

    アップグレード コマンドを実行する前に、クラスターを監視し、は、不必要に失敗するように、リソースを停止します。Before running the upgrade command, stop the resource so the cluster will not monitor it and fail it unnecessarily. 次の例では、停止するためのリソースに原因となるノードの場所の制約を追加します。The following example adds a location constraint on the node that will result on the resource to be stopped. 更新ag_cluster-masterリソース名を持つとnodeName1アップグレードの対象となるレプリカをホストしているノードにします。Update ag_cluster-master with the resource name and nodeName1 with the node hosting the replica targeted for upgrade.

    pcs constraint location ag_cluster-master avoids nodeName1
    

    b.2.b.2. セカンダリ レプリカで SQL Server をアップグレードします。Upgrade SQL Server on the secondary replica

    次の例のアップグレードmssql-servermssql-server-haパッケージです。The following example upgrades mssql-server and mssql-server-ha packages.

    sudo yum update mssql-server
    sudo yum update mssql-server-ha
    

    b.3.b.3. 場所の制約の削除Remove the location constraint

    アップグレード コマンドを実行する前に、クラスターを監視し、は、不必要に失敗するように、リソースを停止します。Before running the upgrade command, stop the resource so the cluster will not monitor it and fail it unnecessarily. 次の例では、停止するためのリソースに原因となるノードの場所の制約を追加します。The following example adds a location constraint on the node that will result on the resource to be stopped. 更新ag_cluster-masterリソース名を持つとnodeName1アップグレードの対象となるレプリカをホストしているノードにします。Update ag_cluster-master with the resource name and nodeName1 with the node hosting the replica targeted for upgrade.

    pcs constraint remove location-ag_cluster-master-rhel1--INFINITY
    

    ベスト プラクティスとして、リソースが開始されたことを確認します (を使用してpcs statusコマンド)、セカンダリ レプリカが接続されているし、アップグレード後に状態が同期されているとします。As a best practice, ensure the resource is started (using pcs status command) and the secondary replica is connected and synchronized state after upgrade.

  3. すべてのセカンダリ レプリカをアップグレードした後に手動でフェールオーバー同期セカンダリ レプリカのいずれか。After all secondary replicas are upgraded, manually fail over to one of the synchronous secondary replicas.

    可用性グループをEXTERNALタイプのクラスターをクラスター管理ツールを使用して、失敗を over; の可用性グループをNONEクラスターの種類は、TRANSACT-SQL を使用してフェールオーバーする必要があります。For availability groups with EXTERNAL cluster type, use the cluster management tools to fail over; availability groups with NONE cluster type should use Transact-SQL to fail over. 次の例は、クラスター管理ツールを使用して可用性グループのフェールオーバーが失敗します。The following example fails over an availability group with the cluster management tools. 置き換える<targetReplicaName>プライマリとなる同期セカンダリ レプリカの名前に置き換えます。Replace <targetReplicaName> with the name of the synchronous secondary replica that will become primary:

    sudo pcs resource move ag_cluster-master <targetReplicaName> --master  
    

    重要

    次の手順は、クラスター マネージャーがない可用性グループにのみ適用されます。The following steps only apply to availability groups that do not have a cluster manager.
    可用性グループのクラスターの種類が場合NONEを手動でフェールオーバーします。If the availability group cluster type is NONE, manually fail over. 次の手順を実行します。Complete the following steps in order:

    a.a. 次のコマンドは、プライマリ レプリカをセカンダリに設定します。The following command sets the primary replica to secondary. 置き換えるAG1可用性グループの名前に置き換えます。Replace AG1 with the name of your availability group. プライマリ レプリカをホストする SQL Server のインスタンスで TRANSACT-SQL コマンドを実行します。Run the Transact-SQL command on the instance of SQL Server that hosts the primary replica.

    ALTER AVAILABILITY GROUP [ag1] SET (ROLE = SECONDARY);
    

    b.b. 次のコマンドは、同期セカンダリ レプリカをプライマリに設定します。The following command sets a synchronous secondary replica to primary. 同期セカンダリ レプリカをホストする SQL Server のインスタンスのターゲット インスタンスで、次の TRANSACT-SQL コマンドを実行します。Run the following Transact-SQL command on the target instance of SQL Server - the instance that hosts the synchronous secondary replica.

    ALTER AVAILABILITY GROUP [ag1] FAILOVER;
    
  4. フェールオーバー後は、b.1 b.3 上記の手順で説明されている同じ手順を繰り返して、古いプライマリ レプリカで SQL Server をアップグレードします。After failover, upgrade SQL Server on the old primary replica by repeating the same procedure described in steps b.1-b.3 above.

    次の例のアップグレードmssql-servermssql-server-haパッケージです。The following example upgrades mssql-server and mssql-server-ha packages.

    # add constraint for the resource to stop on the upgraded node
    # replace 'nodename2' with the name of the cluster node targeted for upgrade
    pcs constraint location ag_cluster-master avoids nodeName2
    sudo yum update mssql-server
    sudo yum update mssql-server-ha
    
    # upgrade mssql-server and mssql-server-ha packages
    sudo yum update mssql-server
    sudo yum update mssql-server-ha
    
    # remove the constraint; make sure the resource is started and replica is connected and synchronized
    pcs constraint remove location-ag_cluster-master-rhel1--INFINITY
    
  5. 外部のクラスターで、可用性グループ マネージャー - クラスターの入力場所は外部、クリーンアップ、手動フェールオーバーが発生した場所の制約条件です。For an availability groups with an external cluster manager - where cluster type is EXTERNAL, cleanup the location constraint that was caused by the manual failover.

    sudo pcs constraint remove cli-prefer-ag_cluster-master  
    
  6. 新たにアップグレードされたセカンダリ レプリカの元のプライマリ レプリカのデータ移動を再開します。Resume data movement for the newly upgraded secondary replica - the former primary replica. これは、機能は、SQL Server の上位バージョンのインスタンスが可用性グループに下位バージョンのインスタンスにログ ブロックを転送するときに必要です。This is required when a higher version instance of SQL Server is transferring log blocks to a lower version instance in an availability group. 新しいセカンダリ レプリカ (元のプライマリ レプリカ) で、次のコマンドを実行します。Run the following command on the new secondary replica (the previous primary replica).

    ALTER DATABASE database_name SET HADR RESUME;
    

すべてのサーバーをアップグレードすると、フェールバック - できますスイッチ_バック - 元のプライマリに必要な場合です。After upgrading all servers, you can failback - fail over back to the original primary - if necessary.

可用性グループを削除します。Drop an availability group

可用性グループを削除するには実行DROP AVAILABILITY GROUPです。To delete an availability group, run DROP AVAILABILITY GROUP. クラスターの種類が場合EXTERNALまたはNONEレプリカをホストする SQL Server のすべてのインスタンスでのコマンドを実行します。If the cluster type is EXTERNAL or NONE run the command on every instance of SQL Server that hosts a replica. たとえば、という名前の可用性グループを削除するgroup_name次のコマンドを実行します。For example, to drop an availability group named group_name run the following command:

DROP AVAILABILITY GROUP group_name

次の手順Next steps

SQL Server 可用性グループのクラスター リソースの Red Hat Enterprise Linux クラスターを構成します。Configure Red Hat Enterprise Linux Cluster for SQL Server Availability Group Cluster Resources

SQL Server 可用性グループのクラスター リソースの SUSE Linux Enterprise Server クラスターを構成します。Configure SUSE Linux Enterprise Server Cluster for SQL Server Availability Group Cluster Resources

Ubuntu クラスターは、SQL Server 可用性グループのクラスター リソースを構成します。Configure Ubuntu Cluster for SQL Server Availability Group Cluster Resources