高可用性、障害復旧のサポート

  • [アーティクル]

PHP ドライバーのダウンロード

このトピックでは、高可用性とディザスター リカバリーのための Microsoft SQL Server 用 Drivers for PHP のサポート (バージョン 3.0 で追加されています) について説明します。

Microsoft SQL Server 用 Drivers for PHP のバージョン 3.0 以降では、高可用性の可用性グループ リスナー、ディザスター リカバリーの可用性グループ、またはサーバーとしてのフェールオーバー クラスター インスタンスを、接続文字列の中で指定できます。

MultiSubnetFailover 接続プロパティを指定すると、アプリケーションが可用性グループまたはフェールオーバー クラスター インスタンスに配置され、ドライバーでは、すべての IP アドレスに対して接続を試行することで、プライマリ SQL Server インスタンス上のデータベースへの接続が試行されます。 SQL Server 可用性グループ リスナーまたは SQL Server フェールオーバー クラスター インスタンスに接続するときには、必ず MultiSubnetFailover=True を指定してください。 フェールオーバーが発生した Always On データベースにアプリケーションが接続されている場合、元の接続は切断され、アプリケーションではフェールオーバー後に処理を続行するために新しい接続を開く必要があります。

Always On 可用性グループの完全な詳細については、高可用性とディザスター リカバリーに関するドキュメントのページを参照してください。

透過的なネットワーク IP の解決 (TNIR)

透過的なネットワーク IP の解決 (TNIR) は、既存の MultiSubnetFailover 機能の改訂です。 ホスト名の解決された最初の IP が応答せず、ホスト名に複数の IP が関連付けられている場合、ドライバーの接続シーケンスに影響を及ぼします。 対応する接続オプションは TransparentNetworkIPResolution です。 MultiSubnetFailover と共に、次の 4 つの接続シーケンスが提供されています。

  • TNIR が有効かつ MultiSubnetFailover が無効になっている: 1 つの IP が試行され、その後にすべての IP が並列で試行されます
  • TNIR が有効かつ MultiSubnetFailover が有効になっている: すべての IP が並列で試行されます
  • TNIR が無効かつ MultiSubnetFailover が無効になっている: すべての IP が 1 つずつ試行されます
  • TNIR が無効かつ MultiSubnetFailover が有効になっている: すべての IP が並列で試行されます

TNIR は既定で有効になっており、MultiSubnetFailover は既定で無効になっています。

次に、PDO_SQLSRV ドライバーを使用して、TNIR と MultiSubnetFailover の両方を有効にする例を示します。

<?php
$serverName = "yourservername";
$username = "yourusername";
$password = "yourpassword";
$connectionString = "sqlsrv:Server=$serverName; TransparentNetworkIPResolution=Enabled; MultiSubnetFailover=yes";
try {
    $conn = new PDO($connectionString, $username, $password, array(PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION));
    // your code 
    // more of your code
    // when done, close the connection
    unset($conn);
} catch(PDOException $e) {
    print_r($e->errorInfo);
}
?>

データベース ミラーリングから複数のサブネット クラスターを使用するためのアップグレード

接続文字列に MultiSubnetFailover および Failover_Partner の接続キーワードが存在する場合、接続エラーが発生します。 また、MultiSubnetFailover が使用されており、データベース ミラーリング ペアに属していることを示すフェールオーバー パートナーの応答が SQL Server から返された場合にも、エラーが発生します。

現在データベース ミラーリングを使用している PHP アプリケーションをマルチサブネットのシナリオにアップグレードする場合は、Failover_Partner 接続プロパティを削除して True に設定した MultiSubnetFailover に置き換え、接続文字列内のサーバー名を可用性グループ リスナーに置き換えます。 接続文字列で Failover_Partner および MultiSubnetFailover=true が使用されている場合、ドライバーでエラーが発生します。 ただし、接続文字列に Failover_Partner と MultiSubnetFailover=false (または ApplicationIntent=ReadWrite) が使用されている場合、アプリケーションではデータベース ミラーリングが使用されます。

AG のプライマリ データベースでデータベース ミラーリングが使用されている場合、および可用性グループ リスナーではなく、プライマリ データベースに接続する接続文字列内で MultiSubnetFailover=true が使用されている場合、ドライバーではエラーが返されます。

アプリケーションの意図を指定する

接続文字列内にキーワード ApplicationIntent を指定できます。 割り当て可能な値は ReadWrite (既定値) または ReadOnly です。

ApplicationIntent=ReadOnly を設定すると、接続時にクライアントによって読み取りワークロードが要求されます。 サーバーでは、接続時と USE データベース ステートメントの実行時にこの意図が適用されます。

ApplicationIntent キーワードは、従来型の読み取り専用データベースに対しては動作しません。

ReadOnly のターゲット

接続で ReadOnly が選択された場合、その接続は、データベースに存在する可能性のある次の特別な構成のいずれかに割り当てられます。

  • Always On。 データベースでは、対象の可用性グループ データベースのワークロードの読み取りを許可または禁止できます。 この選択は、PRIMARY_ROLE および SECONDARY_ROLE Transact-SQL ステートメントの ALLOW_CONNECTIONS 句を使用して制御できます。

  • geo レプリケーション

  • 読み取りスケールアウト

これらの特別なターゲットがいずれも使用できない場合は、通常のデータベースから読み取られます。

ApplicationIntent キーワードを使用すると、"読み取り専用ルーティング" が有効になります。

読み取り専用ルーティング

読み取り専用ルーティングは、データベースの読み取り専用レプリカの可用性を実現する機能です。 読み取り専用ルーティングを有効にするには、次のすべてを適用します。

  • Always On 可用性グループ リスナーに接続する必要があります。

  • ApplicationIntent 接続文字列キーワードを ReadOnly に設定する必要があります。

  • データベース管理者は、読み取り専用ルーティングを有効にするように可用性グループを構成する必要があります。

複数の接続でそれぞれに読み取り専用ルーティングが使用されている場合、すべてが同じ読み取り専用レプリカに接続されるとは限りません。 データベースの同期変更またはサーバーのルーティング構成の変更は、異なる読み取り専用のレプリカに対するクライアントの接続につながることがあります。

Server 接続文字列キーワードに可用性グループ リスナーを渡さ "ない" ことにより、すべての読み取り専用要求が同じ読み取り専用レプリカに接続されるようにすることができます。 代わりに、読み取り専用のインスタンスの名前を指定します。

読み取り専用ルーティングには、プライマリへの接続よりも時間がかかることがあります。 これは、読み取り専用ルーティングではまずプライマリに接続し、次に使用できる最善の読み取り可能なセカンダリを検索するためです。 このような複数のステップがあるため、login タイムアウトを少なくとも 30 秒に増やす必要があります。

参照

サーバーへの接続