Delen via

Sql Server AlwaysOn-beschikbaarheidsgroep configureren voor hoge beschikbaarheid in Linux

  • Artikel

van toepassing op:SQL Server- - Linux

In dit artikel wordt beschreven hoe u een SQL Server AlwaysOn-beschikbaarheidsgroep (AG) maakt voor hoge beschikbaarheid in Linux. Er zijn twee configuratietypen voor AG's. Een hoge beschikbaarheid configuratie maakt gebruik van een clusterbeheerder om bedrijfscontinuïteit te bieden. Deze configuratie kan ook lezerschaal-replica's bevatten. In dit document wordt uitgelegd hoe u de AG voor hoge beschikbaarheid maakt.

U kunt ook een AG maken zonder clusterbeheer voor leesschaal. De AG voor leesschaal biedt alleen-lezen replica's voor het uitschalen van prestaties. Het zorgt niet voor hoge beschikbaarheid. Als u een beschikbaarheidsgroep voor leesschaal wilt maken, zie Een SQL Server-beschikbaarheidsgroep configureren voor leesschaal op Linux.

Configuraties die hoge beschikbaarheid en databescherming garanderen, vereisen twee of drie synchrone commit-replica's. Met drie synchrone replica's kan de beschikbaarheidsgroep automatisch herstellen, zelfs als één server niet beschikbaar is. Zie Hoge beschikbaarheid en gegevensbeveiliging voor configuraties van beschikbaarheidsgroepenvoor meer informatie.

Alle servers moeten fysiek of virtueel zijn en virtuele servers moeten zich op hetzelfde virtualisatieplatform bevinden. Deze noodzaak bestaat omdat de fencing agents platformspecifiek zijn. Zie Beleid voor Gastclusters.

Routekaart

De stappen om een beschikbaarheidsgroep op Linux-servers in te zetten voor hoge beschikbaarheid verschillen van die van een Windows Server-failovercluster. In de volgende lijst worden de stappen op hoog niveau beschreven:

  1. installatierichtlijnen voor SQL Server op Linux.

    Belangrijk

    Alle drie de servers in de beschikbaarheidsgroep moeten zich op hetzelfde platform bevinden (fysiek of virtueel) omdat Linux voor hoge beschikbaarheid fencing agents gebruikt om resources op servers te isoleren. De fencing agents zijn specifiek voor elk platform.

  2. Maak de AG. Deze stap wordt behandeld in dit huidige artikel.

  3. Configureer een clusterresourcemanager, zoals Pacemaker.

    De manier waarop u een clusterresourcebeheer configureert, is afhankelijk van de specifieke Linux-distributie. Zie de volgende koppelingen voor distributiespecifieke instructies:

    Belangrijk

    Voor productieomgevingen is een afschermingsagent vereist voor hoge beschikbaarheid. In de voorbeelden in dit artikel worden geen fencingagents gebruikt. Ze zijn alleen bedoeld voor testen en valideren.

    Een Pacemaker-cluster maakt gebruik van fencing om het cluster terug te brengen naar een bekende toestand. De manier waarop u fencing configureert, is afhankelijk van de distributie en de omgeving. Op dit moment is fencing niet beschikbaar in sommige cloudomgevingen. Zie Ondersteuningsbeleid voor RHEL-clusters met hoge beschikbaarheid - Virtualisatieplatformsvoor meer informatie.

    Zie SUSE Linux Enterprise High Availability Extensionvoor SLES.

  4. Voeg de AG toe als een bron in het cluster.

    Hoe de beschikbaarheidsgroep als een resource in het cluster wordt toegevoegd, hangt af van de Linux-distributie. Zie de volgende koppelingen voor distributiespecifieke instructies:

Overwegingen voor meerdere netwerkinterfaces (NIC's)

Zie de relevante secties voor informatie over het instellen van een beschikbaarheidsgroep voor servers met meerdere NIC's:

Voorwaarden

Voordat u de beschikbaarheidsgroep maakt, moet u het volgende doen:

  • Stel uw omgeving zo in dat alle servers waarop beschikbaarheidsreplica's worden gehost, kunnen communiceren.
  • Installeer SQL Server.

In Linux moet u een beschikbaarheidsgroep maken voordat u deze toevoegt als clusterresource die door het cluster moet worden beheerd. Dit document bevat een voorbeeld waarmee de beschikbaarheidsgroep wordt gemaakt.

  1. Werk de computernaam voor elke host bij.

    De naam van elk SQL Server-exemplaar moet zijn:

    • 15 tekens of minder.
    • Uniek binnen het netwerk.

    Als u de computernaam wilt instellen, bewerkt u /etc/hostname. Met het volgende script kunt u /etc/hostname bewerken met vi-:

    sudo vi /etc/hostname

  2. Configureer het hosts-bestand.

    Notitie

    Als hostnamen zijn geregistreerd bij hun IP-adres op de DNS-server, hoeft u de volgende stappen niet uit te voeren. Controleer of alle knooppunten die deel uitmaken van de configuratie van de beschikbaarheidsgroep met elkaar kunnen communiceren. (Een ping naar de hostnaam moet reageren met het bijbehorende IP-adres.) Zorg er ook voor dat het /etc/hosts-bestand geen record bevat waarmee het LOCALHOST-IP-adres 127.0.0.1 wordt toegewezen aan de hostnaam van het knooppunt.

    Het hosts-bestand op elke server bevat de IP-adressen en namen van alle servers die deelnemen aan de beschikbaarheidsgroep.

    Met de volgende opdracht wordt het IP-adres van de huidige server geretourneerd:

    sudo ip addr show

    Werk /etc/hostsbij. Met het volgende script kunt u /etc/hosts bewerken met vi-:

    sudo vi /etc/hosts

    In het volgende voorbeeld ziet u /etc/hosts op node1 met toevoegingen voor node1, node2en node3. In dit voorbeeld verwijst node1 naar de server die als host fungeert voor de primaire replica, en node2 en node3 verwijzen naar servers waarop de secundaire replica's worden gehost.

    127.0.0.1    localhost localhost4 localhost4.localdomain4
::1          localhost localhost6 localhost6.localdomain6
10.128.18.12 node1
10.128.16.77 node2
10.128.15.33 node3

SQL Server installeren

Installeer SQL Server. De volgende koppelingen verwijzen naar sql Server-installatie-instructies voor verschillende distributies:

AlwaysOn-beschikbaarheidsgroepen inschakelen

Schakel AlwaysOn-beschikbaarheidsgroepen in voor elk knooppunt dat als host fungeert voor een SQL Server-exemplaar en start mssql-serveropnieuw op. Voer het volgende script uit:

sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1
sudo systemctl restart mssql-server

Een AlwaysOn_health-gebeurtenissessie inschakelen

U kunt eventueel uitgebreide gebeurtenissen (XE) inschakelen om te helpen bij de diagnose van de hoofdoorzaak wanneer u problemen met een beschikbaarheidsgroep oplost. Voer de volgende opdracht uit op elk exemplaar van SQL Server:

ALTER EVENT SESSION AlwaysOn_health ON SERVER
WITH
(
        STARTUP_STATE = ON
);
GO

Zie Uitgebreide gebeurtenissen configureren voor beschikbaarheidsgroepenvoor meer informatie over deze XE-sessie.

Een certificaat maken

De SQL Server-service in Linux gebruikt certificaten om communicatie tussen de mirroring-eindpunten te verifiëren.

Met het volgende Transact-SQL script maakt u een hoofdsleutel en een certificaat. Vervolgens wordt een back-up van het certificaat gemaakt en wordt het bestand beveiligd met een persoonlijke sleutel. Werk het script bij met sterke wachtwoorden. Maak verbinding met het primaire SQL Server-exemplaar. Voer het volgende Transact-SQL script uit om het certificaat te maken:

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<master-key-password>';

CREATE CERTIFICATE dbm_certificate
    WITH SUBJECT = 'dbm';

BACKUP CERTIFICATE dbm_certificate
    TO FILE = '/var/opt/mssql/data/dbm_certificate.cer'
    WITH PRIVATE KEY (
        FILE = '/var/opt/mssql/data/dbm_certificate.pvk',
        ENCRYPTION BY PASSWORD = '<private-key-password>'
);

Op dit moment heeft uw primaire SQL Server-replica een certificaat op /var/opt/mssql/data/dbm_certificate.cer en een persoonlijke sleutel op var/opt/mssql/data/dbm_certificate.pvk. Kopieer deze twee bestanden naar dezelfde locatie op alle servers waarop beschikbaarheidsreplica's worden gehost. Gebruik de mssql-gebruiker of geef toestemming aan de mssql-gebruiker om toegang te krijgen tot deze bestanden.

Op de bronserver kopieert de volgende opdracht bijvoorbeeld de bestanden naar de doelcomputer. Vervang de <node2>-waarden door de namen van de SQL Server-exemplaren die de replica's hosten.

cd /var/opt/mssql/data
scp dbm_certificate.* root@<node2>:/var/opt/mssql/data/

Geef op elke doelserver toestemming aan de mssql-gebruiker om toegang te krijgen tot het certificaat.

cd /var/opt/mssql/data
chown mssql:mssql dbm_certificate.*

Het certificaat maken op secundaire servers

Met het volgende Transact-SQL script maakt u een hoofdsleutel en een certificaat op basis van de back-up die u hebt gemaakt op de primaire SQL Server-replica. Werk het script bij met sterke wachtwoorden. Het ontsleutelingswachtwoord is hetzelfde wachtwoord dat u in een vorige stap hebt gebruikt om het .pvk-bestand te maken. Voer het volgende script uit op alle secundaire servers om het certificaat te maken:

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<master-key-password>';

CREATE CERTIFICATE dbm_certificate
    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>'
);

Vervang in het vorige voorbeeld <private-key-password> door hetzelfde wachtwoord dat u hebt gebruikt bij het maken van het certificaat op de primaire replica.

De eindpunten voor databasespiegeling maken op alle replica's

Eindpunten voor databasespiegeling gebruiken TCP (Transmission Control Protocol) om berichten te verzenden en te ontvangen tussen de serverinstanties die deelnemen aan databasespiegelingssessies of beschikbaarheidsreplica's hosten. Het eindpunt voor databasespiegeling luistert op een uniek TCP-poortnummer.

Met het volgende Transact-SQL script maakt u een luistereindpunt met de naam Hadr_endpoint voor de beschikbaarheidsgroep. Hiermee wordt het eindpunt gestart en wordt verbinding verleend met het certificaat dat u hebt gemaakt. Voordat u het script uitvoert, vervangt u de waarden tussen < ... >. U kunt eventueel een IP-adres opnemen LISTENER_IP = (0.0.0.0). Het IP-adres van de listener moet een IPv4-adres zijn. U kunt ook 0.0.0.0gebruiken.

Werk het volgende Transact-SQL script voor uw omgeving bij op alle SQL Server-exemplaren:

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

ALTER ENDPOINT [Hadr_endpoint]
    STATE = STARTED;

Notitie

Als u SQL Server Express-editie op één knooppunt gebruikt om een replica met alleen configuraties te hosten, is de enige geldige waarde voor ROLEWITNESS. Voer het volgende script uit op de SQL Server Express-editie:

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

ALTER ENDPOINT [Hadr_endpoint]
    STATE = STARTED;

De TCP-poort op de firewall moet zijn geopend voor de listenerpoort.

Belangrijk

Voor SQL Server 2017 (14.x) is de enige verificatiemethode die wordt ondersteund voor het eindpunt voor databasespiegeling CERTIFICATE. De optie WINDOWS is niet beschikbaar.

Zie Het eindpunt voor databasespiegeling (SQL Server)voor meer informatie.

Maak de AG aan

In de voorbeelden in deze sectie wordt uitgelegd hoe u de beschikbaarheidsgroep maakt met Behulp van Transact-SQL. U kunt ook de wizard Beschikbaarheidsgroep van SQL Server Management Studio gebruiken. Wanneer u een beschikbaarheidsgroep met de wizard maakt, wordt er een fout geretourneerd wanneer u de replica's aan de beschikbaarheidsgroep koppelt. U kunt dit oplossen door ALTER, CONTROLen VIEW DEFINITIONS toe te kennen aan de pacemaker in de AG op alle replica's. Zodra machtigingen zijn verleend op de primaire replica, koppelt u de knooppunten aan de Availability Group via de wizard, maar verleent u machtigingen voor alle replica's, zodat HA goed functioneert.

Voor een configuratie met hoge beschikbaarheid die automatische failover garandeert, heeft de AG minimaal drie replica's nodig. Een van de volgende configuraties kan hoge beschikbaarheid ondersteunen:

Zie Hoge beschikbaarheid en gegevensbeveiliging voor configuraties van beschikbaarheidsgroepenvoor meer informatie.

Notitie

De beschikbaarheidsgroepen kunnen extra synchrone of asynchrone replica's bevatten.

Maak de beschikbaarheidsgroep voor hoge beschikbaarheid in Linux. Gebruik de CREATE AVAILABILITY GROUP met CLUSTER_TYPE = EXTERNAL.

  • Beschikbaarheidsgroep: CLUSTER_TYPE = EXTERNAL.

    Hiermee geeft u op dat een externe clusterentiteit de beschikbaarheidsgroep beheert. Pacemaker is een voorbeeld van een externe clusterentiteit. Wanneer het ag-clustertype extern is,

  • Primaire en secundaire replica's instellen: FAILOVER_MODE = EXTERNAL.

    Hiermee geeft u op dat de replica communiceert met een extern clusterbeheer, zoals Pacemaker.

De volgende Transact-SQL-scripts maken een AG voor hoge beschikbaarheid met de naam ag1. Het script configureert de AG-replica's met SEEDING_MODE = AUTOMATIC. Deze instelling zorgt ervoor dat SQL Server automatisch de database op elke secundaire server maakt. Werk het volgende script voor uw omgeving bij. Vervang de waarden <node1>, <node2>of <node3> door de namen van de SQL Server-exemplaren die als host fungeren voor de replica's. Vervang de <5022> door de poort die u hebt ingesteld voor het eindpunt voor gegevensspiegeling. Om de AG te maken, voert u de volgende Transact-SQL uit op het SQL Server-exemplaar dat de primaire replica host.

Belangrijk

In de huidige implementatie van de SQL Server-resourceagent moet de naam van het knooppunt overeenkomen met de eigenschap ServerName van uw instantie. Als uw knooppunt bijvoorbeeld de naam knooppunt1heeft, controleert u of SERVERPROPERTY('ServerName') knooppunt1 retourneert in uw SQL Server-exemplaar. Als er sprake is van een mismatch, worden uw replica's omgezet in een oplossende status nadat de pacemaker-resource is aangemaakt.

Een scenario waarin deze regel belangrijk is, is bij het gebruik van volledig gekwalificeerde domeinnamen. Als u bijvoorbeeld node1.yourdomain.com gebruikt als de naam van het knooppunt tijdens het instellen van het cluster, moet u ervoor zorgen dat SERVERPROPERTY('ServerName') node1.yourdomain.comretourneert en niet alleen knooppunt1. De mogelijke tijdelijke oplossingen voor dit probleem zijn:

  • Wijzig de naam van uw host in de FQDN en gebruik sp_dropserver en sp_addserver procedures op te slaan om ervoor te zorgen dat de metagegevens in SQL Server overeenkomen met de wijziging.
  • Gebruik de optie addr in de opdracht pcs cluster auth om de naam van het knooppunt te koppelen aan de waarde SERVERPROPERTY('ServerName') en gebruik een statisch IP-adres als het knooppuntadres.

Voer slechts één van de volgende scripts uit:

Beschikbaarheidsgroep maken met drie synchrone replica's

Maak een AG met drie synchrone replica's.

CREATE AVAILABILITY GROUP [ag1]
      WITH (DB_FAILOVER = ON, CLUSTER_TYPE = EXTERNAL)
      FOR REPLICA ON
         N'<node1>'
               WITH (
            ENDPOINT_URL = N'tcp://<node1>:<5022>',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = EXTERNAL,
            SEEDING_MODE = AUTOMATIC
            ),
         N'<node2>'
         WITH (
            ENDPOINT_URL = N'tcp://<node2>:<5022>',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = EXTERNAL,
            SEEDING_MODE = AUTOMATIC
            ),
         N'<node3>'
         WITH(
            ENDPOINT_URL = N'tcp://<node3>:<5022>',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = EXTERNAL,
            SEEDING_MODE = AUTOMATIC
            );

ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

Belangrijk

Nadat u het voorgaande script hebt uitgevoerd om een AG met drie synchrone replica's te maken, voert u het volgende script niet uit:

Een beschikbaarheidsgroep maken met twee synchrone replica's en een configuratiereplica

Maak AG met twee synchrone replica's en een configuratiereplica:

Belangrijk

Met deze architectuur kan elke editie van SQL Server de derde replica hosten. De derde replica kan bijvoorbeeld worden gehost in SQL Server Express Edition. In Express Edition is het enige geldige eindpunttype WITNESS.

CREATE AVAILABILITY GROUP [ag1]
   WITH (CLUSTER_TYPE = EXTERNAL)
   FOR REPLICA ON
      N'<node1>' WITH (
         ENDPOINT_URL = N'tcp://<node1>:<5022>',
         AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
         FAILOVER_MODE = EXTERNAL,
         SEEDING_MODE = AUTOMATIC
         ),
      N'<node2>' WITH (
         ENDPOINT_URL = N'tcp://<node2>:<5022>',
         AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
         FAILOVER_MODE = EXTERNAL,
         SEEDING_MODE = AUTOMATIC
         ),
      N'<node3>' WITH (
         ENDPOINT_URL = N'tcp://<node3>:<5022>',
         AVAILABILITY_MODE = CONFIGURATION_ONLY
         );
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

Een beschikbaarheidsgroep maken met twee synchrone replica's

AG opzetten met twee synchrone replica's

Neem twee replica's op in synchrone beschikbaarheidsmodus. Met het volgende script wordt bijvoorbeeld een AG met de naam ag1gemaakt. node1 en node2 hostreplica's in synchrone modus, met automatische initialisatie en automatische failover.

Belangrijk

Voer alleen het volgende script uit om een AG met twee synchrone replica's te maken. Voer het volgende script niet uit als u een van de voorgaande scripts hebt uitgevoerd.

CREATE AVAILABILITY GROUP [ag1]
   WITH (CLUSTER_TYPE = EXTERNAL)
   FOR REPLICA ON
   N'node1' WITH (
      ENDPOINT_URL = N'tcp://node1:5022',
      AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
      FAILOVER_MODE = EXTERNAL,
      SEEDING_MODE = AUTOMATIC
   ),
   N'node2' WITH (
      ENDPOINT_URL = N'tcp://node2:5022',
      AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
      FAILOVER_MODE = EXTERNAL,
      SEEDING_MODE = AUTOMATIC
   );

ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

U kunt ook een AG configureren met CLUSTER_TYPE=EXTERNAL met behulp van SQL Server Management Studio of PowerShell.

Secundaire replica's toevoegen aan de beschikbaarheidsgroep (AG)

De Pacemaker-gebruiker vereist ALTER, CONTROLen VIEW DEFINITION machtigingen voor de beschikbaarheidsgroep op alle replica's. Als u machtigingen wilt verlenen, voert u het volgende Transact-SQL script uit nadat de beschikbaarheidsgroep is gemaakt op de primaire replica en elke secundaire replica direct nadat deze zijn toegevoegd aan de beschikbaarheidsgroep. Voordat u het script uitvoert, vervangt u <pacemakerLogin> door de naam van het Pacemaker-gebruikersaccount. Als u geen aanmelding voor Pacemaker hebt, u een SQL Server-aanmelding voor Pacemaker-maken.

GRANT ALTER, CONTROL, VIEW DEFINITION ON AVAILABILITY GROUP::ag1 TO <pacemakerLogin>
GRANT VIEW SERVER STATE TO <pacemakerLogin>

Met het volgende Transact-SQL script wordt een SQL Server-exemplaar gekoppeld aan een AG met de naam ag1. Werk het script voor uw omgeving bij. Voer op elk SQL Server-exemplaar dat als host fungeert voor een secundaire replica de volgende Transact-SQL uit om lid te worden van de beschikbaarheidsgroep.

ALTER AVAILABILITY GROUP [ag1] JOIN WITH (CLUSTER_TYPE = EXTERNAL);

ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

Een database toevoegen aan de beschikbaarheidsgroep

Zorg ervoor dat de database die u toevoegt aan de beschikbaarheidsgroep zich in het volledige herstelmodel bevindt en een geldige logboekback-up heeft. Als uw database een testdatabase of een zojuist gemaakte database is, maakt u een back-up van de database. Voer op de primaire SQL Server het volgende Transact-SQL (T-SQL)-script uit om een database met de naam db1te maken en er een back-up van te maken:

CREATE DATABASE [db1];
GO

ALTER DATABASE [db1]
    SET RECOVERY FULL;
GO

BACKUP DATABASE [db1]
    TO DISK = N'/var/opt/mssql/data/db1.bak';

Voer op de primaire SQL Server-replica het volgende T-SQL-script uit om een database met de naam db1 toe te voegen aan een beschikbaarheidsgroep met de naam ag1:

ALTER AVAILABILITY GROUP [ag1] ADD DATABASE [db1];

Controleer of de database is gemaakt op de secundaire servers

Voer op elke secundaire SQL Server-replica de volgende query uit om te zien of de db1 database is gemaakt en wordt gesynchroniseerd:

SELECT *
FROM sys.databases
WHERE name = 'db1';
GO

SELECT DB_NAME(database_id) AS 'database',
       synchronization_state_desc
FROM sys.dm_hadr_database_replica_states;
GO

Belangrijk

Nadat u de beschikbaarheidsgroep hebt gemaakt, moet u de integratie voor hoge beschikbaarheid configureren met een clustertoepassing zoals Pacemaker. Voor een configuratie met leesschaal met behulp van AG's is het instellen van een cluster vanaf SQL Server 2017 (14.x) niet vereist.

Als u de stappen in dit document hebt gevolgd, hebt u een AG (beschikbaarheidsgroep) die nog niet is geclusterd. De volgende stap bestaat uit het toevoegen van het cluster. Deze configuratie is geldig voor scenario's met leesschaal/taakverdeling. Deze configuratie is niet volledig voor hoge beschikbaarheid. Voor hoge beschikbaarheid moet u de beschikbaarheidsgroep toevoegen als clusterresource. Zie Gerelateerde inhoud voor instructies.

Opmerkingen

Belangrijk

Nadat u het cluster hebt geconfigureerd en de beschikbaarheidsgroep als clusterresource hebt toegevoegd, kunt u geen failover van de AG-resources uitvoeren met Transact-SQL. SQL Server-clusterresources in Linux zijn niet zo nauw gekoppeld aan het besturingssysteem als op een Windows Server Failover Cluster (WSFC). De SQL Server-service is niet op de hoogte van de aanwezigheid van het cluster. Alle indelingen worden uitgevoerd via de hulpprogramma's voor clusterbeheer. Gebruik in RHEL of Ubuntu pcs. Gebruik in SLES crm.

Belangrijk

Als de beschikbaarheidsgroep een clusterresource is, is er een bekend probleem in de huidige release waarbij geforceerde failover met gegevensverlies naar een asynchrone replica niet werkt. Dit wordt opgelost in de komende release. Handmatige of automatische overschakeling naar een synchrone replica is succesvol.

Verwante inhoud