Konfigurowanie zawsze włączonej grupy dostępności programu SQL Server w systemach Windows i Linux (międzyplatformowych)

Artykuł
03/05/2025

Dotyczy: SQL Server 2017 (14.x) i nowszych

W tym artykule opisano kroki tworzenia zawsze włączonej grupy dostępności z jedną repliką na serwerze z systemem Windows i drugą repliką na serwerze z systemem Linux.

Ważny

Międzyplatformowe grupy dostępności programu SQL Server, które obejmują heterogeniczne repliki z pełną wysoką dostępnością i obsługą odzyskiwania po awarii, są dostępne w systemie DH2i DxEnterprise. Aby uzyskać więcej informacji, zobacz grupy dostępności programu SQL Server z mieszanymi systemami operacyjnymi.

Obejrzyj poniższy film wideo, aby dowiedzieć się o międzyplatformowych grupach dostępności z DH2i.

Ta konfiguracja jest międzyplatformowa, ponieważ repliki znajdują się w różnych systemach operacyjnych. Ta konfiguracja służy do migracji z jednej platformy do drugiej lub odzyskiwania po awarii (DR). Ta konfiguracja nie obsługuje wysokiej dostępności.

Diagram grupy dostępności z typem klastra None.

Przed kontynuowaniem należy zapoznać się z instalacją i konfiguracją wystąpień programu SQL Server w systemach Windows i Linux.

Scenariusz

W tym scenariuszu dwa serwery znajdują się w różnych systemach operacyjnych. System Windows Server 2022 o nazwie WinSQLInstance hostuje replikę podstawową. Serwer z systemem Linux o nazwie LinuxSQLInstance hostuje replikę pomocniczą.

Konfigurowanie grupy dostępności

Kroki tworzenia AG są takie same jak przy tworzeniu AG w przypadku obciążeń w skali odczytu . Typ grupy AG to NONE, ponieważ nie ma menedżera klastra.

W przypadku skryptów w tym artykule, nawiasy kątowe oznaczają < i > jako wartości, które należy zastąpić dla swojego środowiska. Nawiasy kątowe nie są wymagane dla skryptów.

Zainstaluj program SQL Server 2022 (16.x) w systemie Windows Server 2022, włącz Always On grupy dostępności w programie SQL Server Configuration Manager i ustaw uwierzytelnianie w trybie mieszanym.

Napiwek

Jeśli walidujesz to rozwiązanie na platformie Azure, umieść oba serwery w tym samym zestawie dostępności, aby upewnić się, że są one oddzielone w centrum danych.

włączanie grup dostępności

Aby uzyskać instrukcje, zobacz Włączanie lub wyłączanie funkcji zawsze włączonej grupy dostępności.

Program SQL Server Configuration Manager odnotowuje, że komputer nie jest węzłem w klastrze awaryjnym.

Po włączeniu grup dostępności uruchom ponownie program SQL Server.

ustawianie uwierzytelniania w trybie mieszanym

Aby uzyskać instrukcje, zobacz Zmienianie trybu uwierzytelniania serwera.
Zainstaluj program SQL Server 2022 (16.x) w systemie Linux. Aby uzyskać instrukcje, zobacz Wskazówki dotyczące instalacji programu SQL Server w systemie Linux. Włącz hadr przy użyciu mssql-conf.

Aby włączyć hadr za pomocą mssql-conf z wiersza poleceń, uruchom następujące polecenie:
```
sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1
```
Po włączeniu hadr, należy ponownie uruchomić wystąpienie programu SQL Server:
```
sudo systemctl restart mssql-server.service
```
Skonfiguruj plik hosts na obu serwerach lub zarejestruj nazwy serwerów w usłudze DNS.
Otwórz porty zapory dla protokołów TCP 1433 i 5022 w systemach Windows i Linux.
W repliki podstawowej utwórz nazwę logowania i hasło bazy danych.
```
CREATE LOGIN dbm_login
    WITH PASSWORD = '<password>';

CREATE USER dbm_user FOR LOGIN dbm_login;
GO
```
Ostrożność

Hasło powinno być zgodne z domyślnymi zasadami haseł programu SQL Server. Domyślnie hasło musi mieć długość co najmniej ośmiu znaków i zawierać znaki z trzech z następujących czterech zestawów: wielkie litery, małe litery, cyfry podstawowe-10 i symbole. Hasła mogą mieć długość maksymalnie 128 znaków. Używaj haseł, które są tak długie i złożone, jak to możliwe.
W repliki podstawowej utwórz klucz główny i certyfikat, a następnie utwórz kopię zapasową certyfikatu przy użyciu klucza prywatnego.
```
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<master-key-password>';

CREATE CERTIFICATE dbm_certificate
    WITH SUBJECT = 'dbm';

BACKUP CERTIFICATE dbm_certificate TO FILE = 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\DATA\dbm_certificate.cer'
    WITH PRIVATE KEY (
         FILE = 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\DATA\dbm_certificate.pvk',
         ENCRYPTION BY PASSWORD = '<private-key-password>'
);
GO
```
Ostrożność

Hasło powinno być zgodne z domyślnymi zasadami haseł programu SQL Server. Domyślnie hasło musi mieć długość co najmniej ośmiu znaków i zawierać znaki z trzech z następujących czterech zestawów: wielkie litery, małe litery, cyfry podstawowe-10 i symbole. Hasła mogą mieć długość maksymalnie 128 znaków. Używaj haseł, które są tak długie i złożone, jak to możliwe.
Skopiuj certyfikat i klucz prywatny na serwer z systemem Linux (replika pomocnicza) w /var/opt/mssql/data. Możesz użyć pscp, aby skopiować pliki na serwer z systemem Linux.
Ustaw grupę i własność klucza prywatnego oraz certyfikat na mssql:mssql.

Poniższy skrypt ustawia grupę i własność plików.
```
sudo chown mssql:mssql /var/opt/mssql/data/dbm_certificate.pvk
sudo chown mssql:mssql /var/opt/mssql/data/dbm_certificate.cer
```
Na poniższym diagramie własność i grupa są poprawnie ustawiane dla certyfikatu i klucza.
W repliki pomocniczej utwórz nazwę logowania i hasło bazy danych i utwórz klucz główny.
```
CREATE LOGIN dbm_login
    WITH PASSWORD = '<password>';

CREATE USER dbm_user FOR LOGIN dbm_login;
GO

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<master-key-password>';
GO
```
Ostrożność

Hasło powinno być zgodne z domyślnymi zasadami haseł programu SQL Server. Domyślnie hasło musi mieć długość co najmniej ośmiu znaków i zawierać znaki z trzech z następujących czterech zestawów: wielkie litery, małe litery, cyfry podstawowe-10 i symbole. Hasła mogą mieć długość maksymalnie 128 znaków. Używaj haseł, które są tak długie i złożone, jak to możliwe.

W repliki pomocniczej przywróć skopiowany certyfikat do /var/opt/mssql/data.

CREATE CERTIFICATE dbm_certificate
    AUTHORIZATION dbm_user
    FROM FILE = '/var/opt/mssql/data/dbm_certificate.cer'
    WITH PRIVATE KEY (
        FILE = '/var/opt/mssql/data/dbm_certificate.pvk',
        DECRYPTION BY PASSWORD = '<private-key-password>'
);
GO

W poprzednim przykładzie zastąp <private-key-password> tym samym hasłem użytym podczas tworzenia certyfikatu w repliki podstawowej.

W repliki podstawowej utwórz punkt końcowy.

CREATE ENDPOINT [Hadr_endpoint]
    AS TCP
(
            LISTENER_IP = (0.0.0.0),
            LISTENER_PORT = 5022
)
    FOR DATABASE_MIRRORING
(
            ROLE = ALL,
            AUTHENTICATION = CERTIFICATE dbm_certificate,
            ENCRYPTION = REQUIRED ALGORITHM AES
);

ALTER ENDPOINT [Hadr_endpoint]
    STATE = STARTED;

GRANT CONNECT
    ON ENDPOINT::[Hadr_endpoint] TO [dbm_login];
GO

Ważny

Zapora musi być otwarta dla portu TCP odbiornika. W poprzednim skrypcie port to 5022. Użyj dowolnego dostępnego portu TCP.

W repliki pomocniczej utwórz punkt końcowy. Powtórz powyższy skrypt w repliki pomocniczej, aby utworzyć punkt końcowy.
W repliki podstawowej utwórz grupę dostępności przy użyciu CLUSTER_TYPE = NONE. Przykładowy skrypt używa SEEDING_MODE = AUTOMATIC do utworzenia AG.

Notatka

Gdy wystąpienie SQL Server na Windows używa różnych ścieżek dla plików danych i logów, automatyczne inicjowanie nie udaje się na wystąpieniu SQL Server na Linuxie, ponieważ te ścieżki nie istnieją na replice pomocniczej. Aby użyć następującego skryptu dla wieloplatformowej grupy dostępności, baza danych wymaga, aby ścieżka dla plików danych i dzienników na serwerze Windows była taka sama. Alternatywnie, możesz zaktualizować skrypt, aby ustawić SEEDING_MODE = MANUAL, a następnie utworzyć kopię zapasową i przywrócić bazę danych za pomocą NORECOVERY, by zainicjować bazę danych.

To zachowanie dotyczy obrazów witryny Azure Marketplace.

Aby uzyskać więcej informacji na temat automatycznego zasiewania, zobacz Automatyczne Zasiewanie - Układ Dysku.

Przed uruchomieniem skryptu zaktualizuj wartości dla swoich AGs.
- Zastąp <WinSQLInstance> nazwą serwera podstawowego wystąpienia programu SQL Server repliki.
- Zastąp <LinuxSQLInstance> nazwą serwera repliki pomocniczego wystąpienia SQL Server.
Aby utworzyć grupę dostępności, zaktualizuj wartości i uruchom skrypt na replice podstawowej.
```
CREATE AVAILABILITY
GROUP [ag1]
WITH (CLUSTER_TYPE = NONE)
FOR REPLICA
    ON N'<WinSQLInstance>'
WITH (
    ENDPOINT_URL = N'tcp://<WinSQLInstance>:5022',
    AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
    SEEDING_MODE = AUTOMATIC,
    FAILOVER_MODE = MANUAL,
    SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL)
    ),
    N'<LinuxSQLInstance>'
WITH (
    ENDPOINT_URL = N'tcp://<LinuxSQLInstance>:5022',
    AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
    SEEDING_MODE = AUTOMATIC,
    FAILOVER_MODE = MANUAL,
    SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL);
    )
GO
```
Aby uzyskać więcej informacji, zobacz CREATE AVAILABILITY GROUP.

Na repliki pomocniczej dołącz do AG grupy dostępności.

ALTER AVAILABILITY GROUP [ag1] JOIN WITH (CLUSTER_TYPE = NONE);
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
GO

Utwórz bazę danych dla AG. W przykładowych krokach użyto bazy danych o nazwie TestDB. Jeśli używasz automatycznego rozmieszczania, ustaw tę samą ścieżkę zarówno dla danych, jak i plików dziennika.

Przed uruchomieniem skryptu zaktualizuj wartości bazy danych.
- Zastąp TestDB nazwą bazy danych.
- Zastąp <F:\Path> ścieżką dla plików bazy danych i dziennika. Użyj tej samej ścieżki dla bazy danych i plików dziennika.
Można również użyć ścieżek domyślnych.

Aby utworzyć bazę danych, uruchom skrypt.
```
CREATE DATABASE [TestDB] CONTAINMENT = NONE
    ON
    PRIMARY(NAME = N'TestDB', FILENAME = N'<F:\Path>\TestDB.mdf')
    LOG ON (NAME = N'TestDB_log', FILENAME = N'<F:\Path>\TestDB_log.ldf');
GO
```
Utwórz pełną kopię zapasową bazy danych.
Jeśli nie używasz automatycznego inicjowania, przywróć bazę danych na serwerze repliki pomocniczej (Linux). Migrowanie bazy danych programu SQL Server z systemu Windows do systemu Linux przy użyciu kopii zapasowej i przywracania. Przywróć bazę danych WITH NORECOVERY na repliki pomocniczej.
Dodaj bazę danych do grupy dostępności. Zaktualizuj przykładowy skrypt. Zastąp TestDB nazwą bazy danych. Na replice podstawowej uruchom zapytanie T-SQL, aby dodać bazę danych do grupy dostępności (AG).
```
ALTER AG [ag1] ADD DATABASE TestDB;
GO
```
Sprawdź, czy baza danych jest wypełniana w repliki pomocniczej.

Przełącz replikę podstawową na przełączenie awaryjne

Każda grupa dostępności ma tylko jedną replikę podstawową. Replika podstawowa umożliwia odczyty i zapisy. Aby zmienić replikę podstawową, możesz przejść w tryb failover. W typowej grupie dostępności menedżer klastra automatyzuje proces przełączania awaryjnego. W grupie dostępności z typem klastra NONE proces failover jest przeprowadzany ręcznie.

Istnieją dwa sposoby przełączania repliki podstawowej w tryb failover w grupie dostępności z typem klastra NONE:

Ręczne przechodzenie w tryb failover bez utraty danych
Wymuszone ręczne przejście w tryb failover z utratą danych

Ręczne przełączenie awaryjne bez utraty danych

Użyj tej metody, gdy jest dostępna replika podstawowa, ale musisz tymczasowo lub trwale zmienić wystąpienie, które hostuje replikę podstawową. Aby uniknąć potencjalnej utraty danych, przed wydaniem ręcznego przełączenia awaryjnego upewnij się, że docelowa replika wtórna jest aktualna.

Aby ręcznie przejść w tryb failover bez utraty danych:

Zamień bieżącą replikę podstawową na replikę pomocniczą i docelową replikę docelową na główną SYNCHRONOUS_COMMIT.
```
ALTER AVAILABILITY GROUP [AGRScale] 
     MODIFY REPLICA ON N'<node2>' 
     WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);
```
Aby zidentyfikować, że aktywne transakcje są zatwierdzane w repliki podstawowej i co najmniej jednej synchronicznej repliki pomocniczej, uruchom następujące zapytanie:
```
SELECT ag.name, 
   drs.database_id, 
   drs.group_id, 
   drs.replica_id, 
   drs.synchronization_state_desc, 
   ag.sequence_number
FROM sys.dm_hadr_database_replica_states drs, sys.availability_groups ag
WHERE drs.group_id = ag.group_id; 
```
Replika pomocnicza jest synchronizowana, gdy synchronization_state_desc jest SYNCHRONIZED.
Zaktualizuj REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT na 1.

Poniższy skrypt ustawia REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT na 1 w grupie dostępności o nazwie ag1. Przed uruchomieniem następującego skryptu zastąp ag1 nazwą grupy dostępności:
```
ALTER AVAILABILITY GROUP [AGRScale] 
     SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 1);
```
To ustawienie zapewnia, że każda aktywna transakcja jest zatwierdzona do repliki podstawowej i co najmniej jednej synchronicznej repliki pomocniczej.

Notatka

To ustawienie nie jest specyficzne dla trybu failover i powinno być ustawione na podstawie wymagań środowiska.
Aby przygotować się do zmiany roli, ustaw replikę podstawową oraz repliki pomocnicze, które nie uczestniczą w przełączeniu awaryjnym, w tryb offline.
```
ALTER AVAILABILITY GROUP [AGRScale] OFFLINE
```

Przekształć docelową replikę pomocniczą w podstawową.

ALTER AVAILABILITY GROUP AGRScale FORCE_FAILOVER_ALLOW_DATA_LOSS;

Aktualizuj rolę starego serwera podstawowego i innych serwerów pomocniczych na SECONDARY, uruchom następujące polecenie w instancji programu SQL Server, która hostuje starą replikę podstawową:
```
ALTER AVAILABILITY GROUP [AGRScale] 
     SET (ROLE = SECONDARY); 
```
Notatka

Aby usunąć grupę dostępności, użyj DROP AVAILABILITY GROUP. Aby uzyskać grupę dostępności utworzoną z typem klastra NONE lub EXTERNAL, wykonaj polecenie na wszystkich replikach należących do tej grupy dostępności.
Wznów przenoszenie danych, uruchom następujące polecenie dla każdej bazy danych w grupie dostępności na instancji programu SQL Server, która hostuje replikę podstawową:
```
ALTER DATABASE [db1]
     SET HADR RESUME
```
Utwórz ponownie każdy odbiornik, który został utworzony na potrzeby skalowania odczytu i który nie jest zarządzany przez menedżera klastra. Jeśli oryginalny odbiornik wskazuje stary element podstawowy, usuń go i utwórz go ponownie, aby wskazać nowy element podstawowy.

Wymuszone ręczne przejście w tryb failover z utratą danych

Jeśli replika podstawowa jest niedostępna i nie można jej od razu odzyskać, musisz wymusić przejście w tryb failover do repliki pomocniczej z utratą danych. Jeśli jednak oryginalna replika podstawowa powróci do działania po failoverze, przyjmie rolę podstawową. Aby uniknąć sytuacji, w której każda replika jest w innym stanie, usuń oryginalną replikę główną z grupy dostępności po wymuszonym przełączeniu awaryjnym z utratą danych. Gdy oryginalny serwer podstawowy wróci do trybu online, usuń z niego całkowicie grupę dostępności.

Aby wymusić ręczne przejście w tryb failover z powodu utraty danych z repliki podstawowej N1 do repliki pomocniczej N2, wykonaj następujące kroki:

W repliki pomocniczej (N2) zainicjuj wymuszony tryb failover:

ALTER AVAILABILITY GROUP [AGRScale] FORCE_FAILOVER_ALLOW_DATA_LOSS;

W nowej repliki podstawowej (N2) usuń oryginalną replikę podstawową (N1):
```
ALTER AVAILABILITY GROUP [AGRScale]
REMOVE REPLICA ON N'N1';
```
Sprawdź, czy cały ruch aplikacji jest kierowany do obiektu nasłuchującego i/lub nowej repliki podstawowej.
Jeśli oryginalny serwer główny (N1) jest dostępny online, natychmiast wyłącz grupę dostępności AGRScale jako offline na oryginalnym serwerze głównym (N1):
```
ALTER AVAILABILITY GROUP [AGRScale] OFFLINE
```
Jeśli istnieją dane lub zmiany niezsynchronizowane, zachowaj te dane za pomocą kopii zapasowych lub innych opcji replikowania danych odpowiadających potrzebom biznesowym.
Następnie usuń grupę dostępności z oryginalnego głównego serwera (N1):
```
DROP AVAILABILITY GROUP [AGRScale];
```
Usuń bazę danych grupy dostępności na oryginalnej replice podstawowej (N1).
```
USE [master]
GO
DROP DATABASE [AGDBRScale]
GO
```
(Opcjonalnie) W razie potrzeby można teraz dodać N1 z powrotem jako nową replikę pomocniczą do grupy dostępności AGRScale.

W tym artykule przedstawiono kroki tworzenia wieloplatformowej grupy dostępności w celu obsługi obciążeń migracyjnych lub skalowania odczytu. Może służyć do ręcznego odzyskiwania po awarii. Wyjaśniono również, jak przełączyć grupę dostępności w tryb awaryjny. Międzyplatformowa grupa dostępności używa NONE typu klastra i nie obsługuje wysokiej dostępności.

Udostępnij za pośrednictwem

Konfigurowanie zawsze włączonej grupy dostępności programu SQL Server w systemach Windows i Linux (międzyplatformowych)

Scenariusz

Konfigurowanie grupy dostępności

Przełącz replikę podstawową na przełączenie awaryjne

Ręczne przełączenie awaryjne bez utraty danych

Wymuszone ręczne przejście w tryb failover z utratą danych

Opinia

Dodatkowe zasoby

Udostępnij za pośrednictwem

Konfigurowanie zawsze włączonej grupy dostępności programu SQL Server w systemach Windows i Linux (międzyplatformowych)

Scenariusz

Konfigurowanie grupy dostępności

Przełącz replikę podstawową na przełączenie awaryjne

Ręczne przełączenie awaryjne bez utraty danych

Wymuszone ręczne przejście w tryb failover z utratą danych

Powiązana zawartość

Opinia

Dodatkowe zasoby