Logboekverzending en -replicatie (SQL Server)

Van toepassing op:SQL Server

Logboekverzending omvat twee kopieën van één database die zich doorgaans op verschillende computers bevinden. Op elk gewenst moment is er slechts één exemplaar van de database beschikbaar voor clients. Deze kopie wordt de primaire database genoemd. Updates van clients naar de primaire database worden doorgegeven via logboekverzending naar de andere kopie van de database, ook wel de secundaire database genoemd. Logboekverzending omvat het toepassen van het transactielogboek bij elke invoeging, update of verwijdering op de primaire database op de secundaire database.

Logboekverzending kan worden gebruikt in combinatie met replicatie, met het volgende gedrag:

  • Replicatie wordt niet voortgezet na een failover van logboekverzending. Als er een failover plaatsvindt, maken replicatieagents geen verbinding met de secundaire agent, zodat transacties niet worden gerepliceerd naar abonnees. Als er een failback naar de primaire server plaatsvindt, wordt de replicatie hervat. Alle transacties die via log shipping van de secundaire server terug naar de primaire server worden gekopieerd, worden gerepliceerd naar Subscribers.

  • Als de primaire permanent verloren gaat, kan de secundaire worden hernoemd zodat replicatie kan doorgaan. In de rest van dit onderwerp worden de vereisten en procedures voor het afhandelen van deze case beschreven. Het opgegeven voorbeeld is de publicatiedatabase, de meest voorkomende database voor het registreren van verzendingen, maar een vergelijkbaar proces kan ook worden toegepast op abonnements- en distributiedatabases.

Zie Back-up maken en gerepliceerde databases herstellen voor informatie over het herstellen van databases die betrokken zijn bij replicatie zonder dat u de replicatie opnieuw hoeft te configureren.

Note

Gebruik AlwaysOn-beschikbaarheidsgroepen in plaats van logboekverzending om de publicatiedatabase beschikbaar te stellen. Zie Replicatie configureren met AlwaysOn-beschikbaarheidsgroepen voor meer informatie.

Vereisten en procedures voor replicatie vanaf het secundaire systeem als het primaire systeem uitvalt

Houd rekening met de volgende vereisten en overwegingen:

  • Als een primaire database meer dan één publicatiedatabase bevat, verzendt u alle publicatiedatabases naar dezelfde secundaire database.

  • Het installatiepad voor het secundaire serverexemplaren moet hetzelfde zijn als het primaire exemplaar. Locaties van gebruikersdatabases op de secundaire server moeten hetzelfde zijn als op de primaire server.

  • Maak een back-up van de servicehoofdsleutel op het primaire exemplaar. Deze sleutel zal worden hersteld op de secundaire server. Zie BACKUPSERVICEBACKUP SERVICE MASTER KEY (Transact-SQL) voor meer informatie.

  • Logboekverzending biedt geen garantie tegen gegevensverlies. Een fout in de primaire database kan leiden tot het verlies van gegevens waarvan nog geen back-up is gemaakt of voor back-ups die verloren gaan tijdens de fout.

Logboekverzending met transactionele replicatie

Voor transactionele replicatie is het gedrag van logboekverzending afhankelijk van de synchronisatie met back-upoptie . Deze optie kan worden ingesteld op de publicatiedatabase en distributiedatabase; in logboekverzending voor de Publisher is alleen de instelling in de publicatiedatabase relevant.

Als u deze optie instelt op de publicatiedatabase, zorgt u ervoor dat transacties pas aan de distributiedatabase worden geleverd als er een back-up wordt gemaakt van de publicatiedatabase. De laatste back-up van de publicatiedatabase kan vervolgens worden hersteld op de secundaire server zonder dat de distributiedatabase transacties heeft die de herstelde publicatiedatabase niet heeft. Deze optie garandeert dat als de Publisher een failover naar een secundaire server uitvoert, consistentie wordt gehandhaafd tussen de Publisher, Distributeur en Abonnees. Latentie en doorvoer worden beïnvloed omdat transacties niet kunnen worden geleverd aan de distributiedatabase totdat er een back-up is gemaakt op het Publisher. Als uw toepassing deze latentie tolereert, raden we u aan deze optie in te stellen voor de publicatiedatabase. Als de synchronisatie met back-upoptie niet is ingesteld, ontvangen abonnees mogelijk wijzigingen die niet meer zijn opgenomen in de herstelde database op de secundaire server. Zie Strategieën voor het maken van back-ups en het herstellen van momentopnamen en transactionele replicatie voor meer informatie.

Transactionele replicatie en logboekverzending configureren met de optie Synchroniseren met back-up

  1. Als de optie voor synchronisatie met back-up niet is ingesteld voor de publicatiedatabase, voert u sp_replicationdboption '<publicationdatabasename>', 'sync with backup', 'true' uit. Zie sp_replicationdboption (Transact-SQL) voor meer informatie.

  2. Configureer logboekverzending voor de publicatiedatabase. Zie Logboekverzending configureren (SQL Server) voor meer informatie.

  3. Als de Publisher mislukt, herstelt u het laatste logboek van de database naar de secundaire server met behulp van de optie KEEP_REPLICATION van RESTORE LOG. Hiermee blijven alle replicatie-instellingen voor de database behouden. Zie Failover naar een secundaire server voor logboekverzending (SQL Server) en RESTORE (Transact-SQL) voor meer informatie.

  4. Herstel de database msdb en de database master van de primaire naar de secundaire. Zie Back-up maken en herstellen van systeemdatabases (SQL Server)voor meer informatie. Als de primaire database ook een distributeur was, herstelt u de distributiedatabase van de primaire naar de secundaire database.

    Deze databases moeten wat betreft replicatieconfiguratie en -instellingen overeenkomen met de publicatiedatabase op de primaire server.

  5. Wijzig de naam van de computer op de secundaire server en wijzig de naam van het SQL Server exemplaar zodat deze overeenkomt met de naam van de primaire server. Zie de documentatie Windows voor informatie over het wijzigen van de naam van de computer. Zie De naam van een computer wijzigen die als host fungeert voor een Stand-Alone exemplaar van SQL Server en de naam van een SQL Server failoverclusterexemplaren wijzigen voor meer informatie over het wijzigen van de naam van de server.

  6. Herstel op de secundaire server de servicehoofdsleutel waarvan een back-up is gemaakt vanaf de primaire server. Zie RESTORESERVICERESTORE SERVICE MASTER KEY (Transact-SQL) voor meer informatie.

Transactionele replicatie en logboekverzending configureren zonder de optie voor synchronisatie met back-up

  1. Configureer logboekverzending voor de publicatiedatabase. Zie Logboekverzending configureren (SQL Server) voor meer informatie.

  2. Als de Publisher mislukt, herstelt u het laatste logboek van de database naar de secundaire server met behulp van de optie KEEP_REPLICATION van RESTORE LOG. Hiermee blijven alle replicatie-instellingen voor de database behouden. Zie Failover naar een secundaire server voor logverzending (SQL Server) en RESTORE (Transact-SQL) voor meer informatie.

  3. Herstel de database msdb en de database master van de primaire naar de secundaire. Zie Back-up maken en herstellen van systeemdatabases (SQL Server)voor meer informatie. Als de primaire database ook een distributeur was, herstelt u de distributiedatabase van de primaire naar de secundaire database.

    Deze databases moeten wat betreft replicatieconfiguratie en -instellingen overeenkomen met de publicatiedatabase op de primaire server.

  4. Wijzig de naam van de computer op de secundaire server en wijzig de naam van het SQL Server exemplaar zodat deze overeenkomt met de naam van de primaire server. Zie de documentatie Windows voor informatie over het wijzigen van de naam van de computer. Zie De naam van een computer wijzigen die als host fungeert voor een Stand-Alone exemplaar van SQL Server en de naam van een SQL Server failoverclusterexemplaren wijzigen voor meer informatie over het wijzigen van de naam van de server.

    Mogelijk ontvangt u een foutbericht van de logboeklezeragent dat de publicatiedatabase en de distributiedatabase niet worden gesynchroniseerd.

  5. Herstel op de secundaire server de servicehoofdsleutel waarvan een back-up is gemaakt vanaf de primaire server. Zie RESTORESERVICERESTORE SERVICE MASTER KEY (Transact-SQL) voor meer informatie.

  6. Voer sp_replrestart uit. Deze opgeslagen procedure kan worden gebruikt om de logboeklezeragent te dwingen alle vorige gerepliceerde transacties in het databaselogboek van de publicatie te negeren. Transacties die worden toegepast nadat de opgeslagen procedure is voltooid, worden verwerkt door de logboeklezeragent. Zie sp_replrestart (Transact-SQL) voor meer informatie.

  7. Start de logboeklezeragent opnieuw op nadat de opgeslagen procedure is uitgevoerd. Voor meer informatie, zie Start en Stop een Replicatieagent (SQL Server Management Studio).

  8. Transacties die al naar de abonnee zijn gedistribueerd, kunnen bij de Publisher worden toegepast. Om ervoor te zorgen dat de Distribution Agent geen fout veroorzaakt wanneer deze transacties opnieuw worden toegepast op een abonnee, geeft u het agentprofiel met de naam Continue On Data Consistency Errors op.

Logboekverzending met samenvoegreplicatie

Volg de stappen in de onderstaande procedure om samenvoegreplicatie en logboekverzending te configureren.

Samenvoegingsreplicatie en logboekverzending configureren

  1. Configureer logboekverzending voor de publicatiedatabase. Zie Logboekverzending configureren (SQL Server) voor meer informatie.

  2. Als de Publisher mislukt, wijzigt u de naam van de computer op de secundaire server en wijzigt u de naam van het SQL Server exemplaar zodat deze overeenkomt met de naam van de primaire server. Zie de documentatie Windows voor informatie over het wijzigen van de naam van de computer. Zie De naam van een computer wijzigen die als host fungeert voor een Stand-Alone exemplaar van SQL Server en de naam van een SQL Server failoverclusterexemplaren wijzigen voor meer informatie over het wijzigen van de naam van de server.

  3. Herstel het laatste transactielogboek van de database naar de secundaire server met de optie KEEP_REPLICATION van RESTORE LOG. Hiermee blijven alle replicatie-instellingen voor de database behouden. Zie Failover naar een secundaire server voor logboekverzending (SQL Server) en RESTORE (Transact-SQL) voor meer informatie.

  4. Herstel de database msdb en de database master van de primaire naar de secundaire. Zie Back-up maken en herstellen van systeemdatabases (SQL Server)voor meer informatie. Als de primaire database ook een distributeur was, herstelt u de distributiedatabase van de primaire naar de secundaire database.

    Deze databases moeten wat betreft replicatieconfiguratie en -instellingen overeenkomen met de publicatiedatabase op de primaire server.

  5. Herstel op de secundaire server de servicehoofdsleutel waarvan een back-up is gemaakt vanaf de primaire server. Zie RESTORESERVICERESTORE SERVICE MASTER KEY (Transact-SQL) voor meer informatie.

  6. Synchroniseer de publicatiedatabase met een of meer abonnementsdatabases. Hiermee kunt u deze wijzigingen uploaden die eerder in de publicatiedatabase zijn aangebracht, maar niet worden weergegeven in de herstelde back-up. De gegevens die kunnen worden geüpload, zijn afhankelijk van de manier waarop een publicatie wordt gefilterd:

    • Als de publicatie niet is gefilterd, moet u de publicatiedatabase kunnen bijwerken door te synchroniseren met de meest actuele Abonnee.

    • Als de publicatie is gefilterd, kunt u de publicatiedatabase mogelijk niet up-to-date brengen. Overweeg een tabel die zodanig is gepartitioneerd dat elk abonnement alleen klantgegevens ontvangt voor één regio: Noord, Oost, Zuid en West. Als er voor elke gegevenspartitie ten minste één Abonnee is, zou synchronisatie met een Abonnee voor elke partitie de publicatiedatabase moeten bijwerken zodat deze up-to-date is. Als gegevens in de partitie West bijvoorbeeld niet naar abonnees zijn gerepliceerd, kunnen deze gegevens bij de Publisher niet worden bijgewerkt. In dit geval raden we u aan om alle abonnementen opnieuw te initialiseren, zodat de gegevens op de Publisher en abonnees convergeren. Zie Abonnementen opnieuw initialiseren voor meer informatie.

    Als u synchroniseert met een abonnee met een versie van SQL Server vóór SQL Server 2005 (9.x), kan het abonnement niet anoniem zijn. Het moet een clientabonnement of serverabonnement zijn (in eerdere releases lokale abonnementen en globale abonnementen genoemd). Zie Gegevens synchroniseren voor meer informatie.

Zie ook

SQL Server-replicatie
Over logboekverzending (SQL Server)Replicatie configureren met AlwaysOn-beschikbaarheidsgroepen