Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Van toepassing op:
Azure SQL Database
In dit artikel worden de verificatievereisten beschreven voor het configureren en beheren van actieve geo-replicatie en failovergroepen. Het biedt ook de stappen die nodig zijn om gebruikerstoegang tot de secundaire database in te stellen. Ten slotte wordt ook beschreven hoe u na het gebruik van geo-herstel toegang tot de herstelde database inschakelt. Zie Bedrijfscontinuïteit in Azure SQL Database voor meer informatie over herstelopties.
Herstel na noodgevallen met ingesloten gebruikers
In tegenstelling tot traditionele gebruikers, die moeten worden toegewezen aan aanmeldingen in de master database, wordt een ingesloten gebruiker volledig beheerd door de database zelf. Dit heeft twee voordelen. In het scenario voor herstel na noodgevallen kunnen de gebruikers verbinding blijven maken met de nieuwe primaire database of de database die is hersteld met geo-herstel zonder extra configuratie, omdat de database de gebruikers beheert. Er zijn ook potentiële schaalbaarheids- en prestatievoordelen van deze configuratie vanuit het oogpunt van aanmelding. Zie Ingesloten databasegebruikers: een draagbare database maken voor meer informatie.
Het belangrijkste nadeel is dat het beheer van het proces voor herstel na noodgevallen op schaal lastiger is. Wanneer u meerdere databases hebt die gebruikmaken van dezelfde aanmelding, kan het onderhouden van de referenties van geïsoleerde gebruikers in meerdere databases de voordelen van deze gebruikers tenietdoen. Het beleid voor wachtwoordrotatie vereist bijvoorbeeld dat wijzigingen consistent in meerdere databases worden aangebracht in plaats van het wachtwoord voor de aanmelding eenmaal in de master database te wijzigen. Als u daarom meerdere databases hebt die dezelfde gebruikersnaam en hetzelfde wachtwoord gebruiken, wordt het gebruik van ingesloten gebruikers niet aanbevolen.
Aanmeldingen en gebruikers configureren
Als u aanmeldingen en gebruikers gebruikt (in plaats van ingesloten gebruikers), moet u extra stappen uitvoeren om ervoor te zorgen dat dezelfde aanmeldingen in de master database aanwezig zijn. In de volgende secties worden de betrokken stappen en aanvullende overwegingen beschreven.
Opmerking
Het is ook mogelijk om aanmeldingen te gebruiken die zijn gemaakt op basis van Microsoft Entra ID (voorheen Azure Active Directory) om uw databases te beheren. Zie Databasetoegang autoriseren voor meer informatie.
Gebruikerstoegang tot een secundaire of herstelde database instellen
Om ervoor te zorgen dat de secundaire database kan worden gebruikt als een alleen-lezen database en om te garanderen dat er goed toegang is tot de nieuwe primaire database of de herstelde database met geo-herstel, moet de master database van de doelserver vóór het herstel de juiste beveiligingsconfiguratie hebben.
Het voorbereiden van de toegang voor gebruikers tot een secundaire geo-replicatie moet uitgevoerd worden als onderdeel van het configureren van geo-replicatie. Het voorbereiden van gebruikerstoegang tot de geografisch herstelde databases moet op elk gewenst moment worden uitgevoerd wanneer de oorspronkelijke server online is (als onderdeel van de test voor herstel na noodgevallen).
Opmerking
Als u overschakelt of een georestore uitvoert naar een server die geen goed geconfigureerde aanmeldingen heeft, wordt de toegang tot de server beperkt tot het beheerdersaccount van de server.
Het instellen van aanmeldingen op de doelserver omvat drie stappen:
1. Aanmeldingen bepalen met toegang tot de primaire database
De eerste stap van het proces is om te bepalen welke aanmeldingen moeten worden gedupliceerd op de doelserver. Dit wordt bereikt met een paar SELECT-instructies, één in de logische master database op de bronserver en één in de primaire database zelf.
Alleen de serverbeheerder of een lid van de LoginManager-serverrol kan de aanmeldingen op de bronserver bepalen met de volgende SELECT instructie.
SELECT [name], [sid]
FROM [sys].[sql_logins]
WHERE [type_desc] = 'SQL_Login'
Alleen een lid van de db_owner-databaserol, de dbo-gebruiker of de serverbeheerder, kan alle databasegebruikersprincipes van de primaire database bepalen.
SELECT [name], [sid]
FROM [sys].[database_principals]
WHERE [type_desc] = 'SQL_USER'
2. Zoek de SID voor de aanmeldingen die zijn geïdentificeerd in stap 1
Door de uitvoer van de query's uit de vorige sectie te vergelijken en de SID's te koppelen, kunt u de aanmelding van de server toewijzen aan de databasegebruiker. Aanmeldingen met een databasegebruiker met een overeenkomende SID hebben gebruikerstoegang tot die database als principal van die databasegebruiker.
De volgende query kan worden gebruikt om alle gebruikersprinciplen en hun SID's in een database weer te geven. Alleen een lid van de db_owner databaserol of serverbeheerder kan deze query uitvoeren.
SELECT [name], [sid]
FROM [sys].[database_principals]
WHERE [type_desc] = 'SQL_USER'
Opmerking
De INFORMATION_SCHEMA en sys gebruikers hebben NULL SID's en de guest SID is 0x00. De dbo SID kan beginnen met 0x01060000000001648000000000048454 als de maker van de database de serverbeheerder was in plaats van lid van DbManager.
3. Maak de aanmeldingen op de doelserver
De laatste stap is om naar de doelserver of servers te gaan en de aanmeldingen te genereren met de juiste SID's. De basissyntaxis is als volgt.
CREATE LOGIN [<login name>]
WITH PASSWORD = '<login password>',
SID = 0x1234 /*replace 0x1234 with the desired login SID*/
Maak op de doelserver geen nieuwe aanmelding met de serverbeheerder-SID van de bron. In plaats daarvan moet de serverbeheerder van het doel zich aanmelden bij een database-principal in de database, zoals db_owner of gebruiker.
Opmerking
Als u gebruikers toegang wilt verlenen tot de secundaire, maar niet aan de primaire, kunt u dit doen door de aanmelding van de gebruiker op de primaire server te wijzigen met behulp van de volgende syntaxis.
ALTER LOGIN [<login name>] DISABLE
Met DISABLE wordt het wachtwoord niet gewijzigd, dus u kunt het altijd inschakelen als dat nodig is.