Статьи

Драйвер SQL Server для параметров подключения PHP: Failover_Partner

Одна из лучших вещей в написании этой серии о вариантах подключения для драйвера SQL Server для PHP заключается в том, что я узнал о многих интересных возможностях SQL Server. На этот раз опция подключения Failover_Partner заставила меня немного поработать над  зеркалированием базы данных . Коротко говоря, как разработчик приложения вам не нужно много разбираться в зеркалировании базы данных … это проблема DBA. Конечно, если вы и разработчик приложений, и администратор баз данных, и вам нужна база данных для отработки отказа, вы, возможно, захотите потратить некоторое время на то, чтобы больше узнать о зеркалировании, чем я расскажу (документация MSDN начинается здесь.). В этом посте я представлю введение в зеркалирование и, надеюсь, предоставлю достаточно информации о параметре Failover_Partner, чтобы вы могли отправить своему администратору базы данных интеллектуальное электронное письмо на случай, если что-то пойдет не так.

Зеркальное отображение базы данных — это прежде всего программное решение для повышения доступности базы данных. По сути, вы настраиваете два сервера, один из которых выступает в качестве основного сервера для данной базы данных, а другой — в качестве «зеркала» в случае сбоя основного сервера. Когда приложение PHP подключается к основному серверу, параметр подключения Failover_Partner указывает имя сервера, к которому должно подключаться приложение, если основной сервер недоступен. Если я подключусь, как показано здесь …

$serverName = "Server_A";
$connectionInfo = array( "Database"=>"ExampleDB"
                         , "UID"=>"UserName"
                         , "PWD"=>"Password"
                         , "Failover_Partner" => "Server_B");
$conn = sqlsrv_connect( $serverName, $connectionInfo);

 

… Тогда мой PHP-клиент сначала попытается подключиться к Server_A . Если сервер недоступен, то он будет пытаться подключиться к Server_B с предположением о том , что резервное копирование ExampleDB (на Server_A ) существует на Server_B . Если Server_B недоступен, он будет снова пытаться Server_A … и так будет поочередно, пока один из серверов не ответит или пока не будет достигнут предел времени ожидания соединения. Конечно, чтобы этот сценарий работал, вам необходимо настроить Server_A и Server_B для зеркалирования.

Примечание . Экспресс-версии SQL Server 2005, 2008 и 2008 R2 не поддерживают зеркалирование. Полный список поддерживаемых функций и версий поддерживается на следующих страницах: Функции, поддерживаемые выпусками SQL Server 2005 , Функции, поддерживаемые выпусками SQL Server 2008 , и Функции, поддерживаемые выпусками SQL Server 2008 R2 .

Как видите, разработчику приложения не о чем беспокоиться, кроме * a * неудовлетворительного соединения. С точки зрения разработчика, не имеет значения, какой сервер не отвечает, нужно просто планировать возможность сбоя соединения (что может означать маловероятный случай недоступности обоих серверов).

С точки зрения администратора баз данных (или точки зрения приложения в целом), есть несколько вещей, которые следует учитывать. Во-первых, нужно ли вообще зеркалировать ваше приложение. По сути, это сводится к тому, чтобы решить, насколько важна доступность для вашего приложения: настройка зеркалирования добавляет страховку к доступности вашего приложения, когда это необходимо. Если вы решите, что эта страховка необходима, то вы должны принять решение, чтобы сбалансировать производительность и целостность данных. Существует два основных варианта настройки зеркалирования: асинхронный режим и синхронный режим :

  1. Настройка зеркального отображения в асинхронном режиме обеспечивает лучшую производительность, но не гарантирует целостность данных. В этом режиме Server_A отправляет журналы транзакций на Server_B, но не ожидает подтверждения получения этих журналов, прежде чем ответить клиенту. Это позволяет Server_A быстро отвечать клиенту, но в случае отработки отказа Server_B может не иметь всех журналов транзакций для создания копии базы данных до последней секунды, поэтому некоторые данные могут быть потеряны. (Обратите внимание, что я несколько упрощаю. Полная информация здесь: Асинхронное зеркальное отображение базы данных (высокопроизводительный режим) ).
  2. Настройка зеркального отображения в синхронном режиме обеспечивает очень высокую степень целостности данных, но за счет некоторой производительности. В этом режиме Server_A отправляет журналы транзакций на Server_B, а затем ждет, пока Server_B подтвердит, что журналы были записаны на диск, прежде чем ответить клиенту. Это позволяет Server_B создавать копию базы данных с точностью до последней секунды в случае отработки отказа, но это влияет на производительность, поскольку Server_A должен ждать Server_B . (Опять же, я упрощаю. Полная информация здесь: Синхронное зеркальное отображение базы данных (режим высокой безопасности) ).

Очевидно, что как только вы определитесь с режимом зеркалирования, вам нужно ответить на многие другие вопросы (включая вопросы о настройке зеркальных серверов). Документация по SQL Server должна подробно ответить на эти вопросы: Зеркальное отображение базы данных . Если вы обнаружите, что эти документы не отвечают на ваши вопросы, дайте мне знать, и я сделаю еще домашнюю работу.

Спасибо.

-Брайан