Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
W tym temacie omówiono sterowniki firmy Microsoft dla języka PHP dla obsługi programu SQL Server (dodane w wersji 3.0) na potrzeby wysokiej dostępności i odzyskiwania po awarii.
Począwszy od wersji 3.0 sterowników firmy Microsoft dla języka PHP dla programu SQL Server, można określić odbiornik grupy dostępności wysokiej dostępności, grupy dostępności odzyskiwania po awarii lub wystąpienia klastra trybu failover jako serwera w parametrach połączenia.
Ustaw parametr MultiSubnetFailover=True, jeśli elementem docelowym jest Azure SQL Database, Azure SQL Managed Instance, baza danych SQL w usłudze Microsoft Fabric, detektor grupy dostępności lub wystąpienie klastra trybu failover. Sterownik próbuje nawiązać połączenia TCP ze wszystkimi ustalonymi adresami IP równolegle i wykorzystuje pierwsze połączenie, które zostanie nawiązane pomyślnie. Jeśli aplikacja jest połączona z bazą danych, która ulegnie przełączeniu awaryjnemu, dotychczasowe połączenie zostanie przerwane i aplikacja musi otworzyć nowe połączenie, aby kontynuować działanie po przełączeniu awaryjnym.
Gdy DNS zwraca jeden adres, MultiSubnetFailover=True nie powoduje dodatkowych równoległych prób połączenia, więc można go bezpiecznie stosować w przypadku elementów docelowych z jednym adresem IP.
Sterowniki akceptują True, 1 lub Yes w każdym przypadku i przekazują opcję do podstawowego sterownika ODBC. Każdą inną wartość traktują jako Fałszywą bez zgłaszania błędu, więc błędnie napisana wartość po cichu wyłącza tę opcję.
MultiSubnetFailover ma następujące ograniczenia:
Nie możesz używać go przez inny protokół niż TCP.
Połączenie z instancją SQL Server skonfigurowaną z ponad 64 adresami IP kończy się niepowodzeniem.
Nie da się jej używać z mirroringiem bazy danych. Nie ustawiaj tego, gdy parametry połączenia zawierają również Failover_Partner albo gdy nawiązujesz połączenie z repliką podstawową zamiast z listenerem grupy dostępności. Więcej informacji można znaleźć w artykule Upgrading to Use Multi-Subnet Clusters w Database Mirroring.
Dla serwerless Azure SQL Database z włączoną automatyczną pauzą, jeśli ustawisz LoginTimeout, użyj co najmniej 60 sekund. Automatycznie wstrzymana baza danych wznawia się przy pierwszej próbie połączenia, a ta próba może zakończyć się błędem 40613, podczas gdy baza się wznawia, więc aplikacja musi spróbować ponownie. Więcej informacji znajdziesz w sekcji Automatyczne wstrzymywanie i automatyczne wznawianie.
Więcej informacji o grupach dostępności Always On znajdziesz w artykule Co to jest Always On Availability Group?.
Przezroczyste rozpoznawanie adresów IP sieci (TNIR)
Transparent Network IP Resolution (TNIR) to starszy mechanizm awaryjny sterownika ODBC dla wielu adresów IP, sterowany za pomocą opcji połączenia TransparentNetworkIPResolution i domyślnie włączony.
Postępuj zgodnie z wytycznymi z poprzedniej sekcji i ustaw MultiSubnetFailover=True dla celów wymienionych tam. Gdy MultiSubnetFailover=True, sterownik próbuje równolegle nawiązać połączenia TCP ze wszystkimi ustalonymi adresami IP. Opcja TransparentNetworkIPResolution nie wpływa na sekwencję połączenia, więc nie musisz jej ustawiać ani uwzględniać w parametry połączenia.
Pełne informacje na temat interakcji między TNIR a MultiSubnetFailover można znaleźć w artykule Using Transparent Network IP Resolution with the ODBC Driver.
Aktualizacja do korzystania z klastrów wielopodsieciowych z mirroringu baz danych
Wystąpi błąd połączenia, jeśli w ciągu połączenia występują słowa kluczowe MultiSubnetFailover i Failover_Partner. Błąd wystąpi również, jeśli użyto MultiSubnetFailover, a program SQL Server zwróci odpowiedź partnera przełączenia awaryjnego wskazującą, że należy on do pary dublowania bazy danych.
Podczas aktualizacji aplikacji PHP, która obecnie korzysta z mirroringu baz danych, do scenariusza wielopodsieciowego, usuń właściwość połączenia Failover_Partner i zastąp ją MultiSubnetFailover ustawioną na True. Zastąp nazwę serwera w parametry połączenia na nasłuchiwacz grupy dostępności. Jeśli parametr połączenia zawiera Failover_Partner i MultiSubnetFailover=True, sterownik zgłasza błąd. Jednak jeśli ciąg połączenia zawiera Failover_Partner i MultiSubnetFailover=False (lub ApplicationIntent=ReadWrite), aplikacja korzysta z dublowania bazy danych.
Sterownik zwraca błąd, jeśli używasz dublowania bazy danych na replice głównej w grupie dostępności oraz jeśli używasz parametru MultiSubnetFailover=True w ciągu połączenia służącym do łączenia z repliką główną zamiast z listenerem grupy dostępności.
Określ intencję aplikacji
Możesz podać słowo kluczowe ApplicationIntent w parametrach połączenia. Przypisywalne wartości to ReadWrite (domyślne) lub ReadOnly.
Po ustawieniu ApplicationIntent=ReadOnly klient żąda obciążenia odczytowego podczas nawiązywania połączenia. Serwer wymusza to zamierzenie w momencie nawiązywania połączenia oraz podczas instrukcji bazy danych USE.
Słowo kluczowe ApplicationIntent nie działa ze starszego typu bazami danych tylko do odczytu.
Cele tylko do odczytu
Gdy połączenie wybierze ReadOnly, połączenie jest przypisywane do jednej z następujących specjalnych konfiguracji, które mogą istnieć dla bazy danych:
Zawsze włączony. Baza danych może zezwalać na obciążenia związane z odczytem lub nie zezwalać na nie w bazie danych docelowej grupy dostępności. Ten wybór jest kontrolowany za pomocą klauzuli
ALLOW_CONNECTIONSinstrukcjiPRIMARY_ROLEiSECONDARY_ROLEjęzyka Transact-SQL.
Jeśli żaden z tych specjalnych celów nie jest dostępny, odczyt odbywa się ze zwykłej bazy danych.
Słowo kluczowe ApplicationIntent umożliwia routing tylko do odczytu.
Rutowanie tylko odczytu
Trasowanie połączeń tylko do odczytu to funkcja, która może zapewnić dostępność repliki tylko do odczytu bazy danych. Aby umożliwić routing tylko do odczytu, obowiązują wszystkie następujące zasady:
Musisz połączyć się z odbiornikiem grupy dostępności Always On.
Słowo kluczowe
ApplicationIntentw parametrze połączenia musi być ustawione doReadOnly.Administrator bazy danych musi skonfigurować grupę dostępności, aby umożliwić routowanie tylko do odczytu.
Wiele połączeń, z których każde korzysta z routingu tylko do odczytu, może nie wszystkie łączyć się z tą samą repliką tylko do odczytu. Zmiany synchronizacji bazy danych lub zmiany konfiguracji routingu serwera mogą spowodować połączenia klientów z różnymi replikami tylko do odczytu.
Możesz zapewnić, że wszystkie żądania tylko do odczytu łączą się z tą samą repliką tylko do odczytu, nie przekazując nasłuchiwacza grupy dostępności do Server słowa kluczowego ciągu połączeń. Zamiast tego określ nazwę wystąpienia tylko do odczytu.
Routing tylko do odczytu może zająć więcej czasu niż połączenie z głównym serwerem. Wynika to z faktu, że routing tylko do odczytu najpierw łączy się z repliką podstawową, a następnie szuka najlepszej dostępnej repliki pomocniczej dostępnej do odczytu. Ze względu na te liczne kroki należy zwiększyć limit czasu login do co najmniej 30 sekund.