Inleiding
Vaak moeten we fouttolerantie van MS SQL Server DBMS garanderen, vooral wanneer er geen Enterprise-editie is, maar alleen de Standard-editie.
We willen graag opmerken dat we de Express-editie niet gaan onderzoeken omdat er aanzienlijke beperkingen zijn voor deze instantie. Natuurlijk kunnen we er een aantal omzeilen. Om het probleem met de databasegrootte van 10 GB op te lossen, kunnen we bijvoorbeeld een grote database opsplitsen in kleinere. Om dit te doen, kunnen we een nieuwe database maken op basis van een bepaalde eigenschap en de selecties uit dezelfde tabellen van verschillende databases combineren in de views in de hoofddatabase. Fouttolerantie in de Express-editie wordt echter uitgevoerd door een systeembeheerder of door uw eigen software of software van derden te gebruiken.
In dit artikel gaan we alle bestaande standaard fouttolerantietechnologieën voor MS SQL Server 2017 onderzoeken en een voorbeeld van het implementeren van de meest geschikte uniforme standaard van fouttolerantie in de Standard-editie.
Korte recensie
-
AlwaysOn
Belastingverdeling over alle partijen, alle partijen moeten qua kenmerken vergelijkbaar zijn. De synchrone modus zorgt voor maximale betrouwbaarheid van gegevensoverdracht; de prestaties zullen echter gelijk zijn aan de snelheid van de langzaamste partij. De asynchrone modus zorgt voor de hoogste prestaties, maar er kunnen niet-overeenkomende gegevens tussen de partijen zijn, wat kan leiden tot een complexer onderhoud en de kans dat de laatste wijzigingen verloren gaan in het geval van een storing van de hoofdpartij. De snelheid van overschakelen naar een synchrone modus is bijna onmiddellijk en vereist geen systeembeheerder en DBA, terwijl het in de asynchrone modus afhangt van de huidige status van DB-duplicaten en gewoonlijk ongeveer 5 minuten duurt (u kunt het schakelproces ook automatiseren door één DBA zonder een systeembeheerder ).Microsoft raadt het gebruik van deze technologie voor een database aan. Het is beschikbaar in de Enterprise-editie vanaf versie 2012 en hoger en met beperkingen in de Standard-editie (raadpleeg voor meer informatie Top 5 vragen over basisbeschikbaarheidsgroepen).
-
Clustering
Ondanks de eenvoud van configuratie is deze oplossing onbetrouwbaar vanwege de bottleneck in de vorm van één datawarehouse. In het geval van een storing in het datawarehouse, duurt het meer dan 1 uur om het te herstellen. Deze technologie is beschikbaar in de Standard-editie van versie 2008 en hoger.
-
Replicatie
Elke replicatie omvat het maken van systeemtriggers voor elke deelnemende tabel, terwijl snapshotreplicatie de hoofddatabase zwaar belast. Daarom kan snapshotreplicatie alleen worden uitgevoerd tijdens de daluren van de databasebelasting (bijvoorbeeld 's nachts), wat onaanvaardbaar is, omdat een hot-standby nodig is. Samenvoegreplicatie is moeilijk te onderhouden door sommige systemen (bijvoorbeeld CRM, NAV).
Transactionele replicatie is mogelijk in de Enterprise-editie. Beschikbaar in de Standard-editie (samenvoegen en database-snapshots) en de Enterprise-editie (transacties) tot versie 2008 en hoger. -
Spiegelen
Het is mogelijk in elke modus. De synchrone modus zorgt echter voor maximale betrouwbaarheid en snel schakelen, terwijl de asynchrone modus gebruikers de maximale prestatiesnelheid van de hoofddatabase biedt. Het is echter mogelijk dat gegevens tussen partijen niet overeenkomen en het overstappen kan langzaam gaan.
Hier zorgt een getuige-server of DBA voor de automatische omschakeling op databaseniveau (bijvoorbeeld wanneer de CPU-belasting meer dan 50% is op de hoofdserver). Een systeembeheerder verleent de verbinding met de andere server. Een back-updatabase voor elk type spiegeling bevindt zich in een continue herstelmodus en is dus niet toegankelijk.
Een herstelmodus van de database is vol.
Microsoft beschouwt het als een verouderde databasetechnologie. Het is beschikbaar in de Standard-editie (in de synchrone modus) en in de Enterprise-editie (in de asynchrone modus) tot versie 2008 en hoger.
-
Verzending transactielogboek
Er zijn twee modi:continu herstel op een standby-server of herstel met vertraging. De eerste modus schakelt een back-updatabase naar een continue herstelmodus en in dit geval hebben we er geen toegang toe.
De tweede modus schakelt de back-updatabase regelmatig naar een herstelmodus tijdens het implementeren van updates (de back-updatabase is beschikbaar tussen implementaties, maar dit is mogelijk op voorwaarde dat MS SQL Server-instanties van dezelfde versie zijn).
Hoe het werkt:
- Soms wordt er een reservekopie van het databasetransactielogboek opgeslagen in een openbare map op de bron- en stand-byserver (de directory en het schema worden standaard elke 15 minuten geconfigureerd).
- De standby-server kopieert periodiek de back-up van het transactielogboek van de database naar een lokale map (de directory en het schema worden standaard elke 15 minuten geconfigureerd).
- De standby-server herstelt het transactielogboek vanaf de back-up van het transactielogboek (het schema wordt standaard elke 15 minuten geconfigureerd).
Databasebeheerders kunnen het schakelproces op databaseniveau automatiseren, terwijl een systeembeheerder dit kan doen op het niveau van verbinding met de server.
Er moet ook worden opgemerkt dat deze methode altijd werkt in de asynchrone modus. U kunt meerdere back-updatabases configureren.
De databaseherstelmodus is vol of bulksgewijs geregistreerd.
Het is beschikbaar in de Standard-editie tot de versie 2008 en hoger.
Er zijn twee modi:continu herstel op een standby-server of herstel met vertragingen.
Samenvatting
De meeste voorkeur gaat uit naar verzending van transactielogboeken in de Standard-editie, omdat het handig is om het te gebruiken voor een soepele overgang van de ene server naar de andere, bijvoorbeeld bij het bijwerken van de omgeving. Bovendien is de verzending van het transactielogboek eenvoudig en gebruiksvriendelijk en werkt het altijd in de asynchrone modus, die de database niet veel laadt, in tegenstelling tot de synchrone spiegelmodus. In ieder geval is spiegelen acceptabel, als het mogelijk is om zijn eigen automatische schakeling te configureren; anders is valse omschakeling mogelijk (bijvoorbeeld wanneer de CPU van de hoofdserver voor meer dan 50% wordt belast).
Gebruik voor de Enterprise-editie de AlwaysOn-technologie.
Failover configureren bij verzending van transactielogboek
U kunt hier meer gedetailleerde informatie vinden over het configureren van de verzending van het transactielogboek. Bovendien is het mogelijk om dit proces te automatiseren door uw eigen hulpprogramma te ontwikkelen voor herhaald meervoudig gebruik, evenals voor terugkeer naar de hoofdserver nadat deze is gerepareerd in het geval van een failover.
Laten we eens kijken naar een van de mogelijke opties voor het debuggen van failover bij verzending van transactielogboeken op DBMS-niveau.
Opgemerkt moet worden dat deze methode geschikt is voor een server die is gereserveerd voor slechts één exemplaar van MS SQL Server-instantie, aangezien er voor meerdere gevallen een probleem is bij het bepalen welke taken moeten worden uitgevoerd en welke niet.
Laten we de volgorde van stappen beschrijven:
- Voer alle taken uit om de nieuwste bestanden van de bron te kopiëren (met een goed doordachte architectuur moet de map toegankelijk zijn, zelfs als de hoofdserver niet beschikbaar is)
- Schakel alle taken uit om bestanden van de bron te kopiëren
- Voer alle taken uit om een database te herstellen met de nieuwste bestanden van de bron
- Schakel alle databasehersteltaken uit met de nieuwste bestanden van de bron
- Maak de database hersteld en de belangrijkste voor de verzending van het log, maar zonder een ontvanger
- Maak volledige back-ups van de database
- Taken maken om transactielogboeken te back-uppen
Hieronder ziet u een voorbeeld van het implementeren van de bovengenoemde volgorde als een opgeslagen procedure.
Opgemerkt moet worden dat het belangrijk is om een login (bij voorkeur een domein login) te configureren waaronder de taken zullen worden uitgevoerd om back-ups van transactielogboeken te maken.
Een voorbeeld van het debuggen van de failover van de verzending van het transactielogboek
CREATE PROCEDURE [srv].[RunLogShippingFailover]
@isfailover bit=1,
@login nvarchar(255)=N'LOGIN', -- a domain login under which the tasks will be performed run to create backups of transaction logs.
@backup_directory nvarchar(255)=N'DIRECTORY'—public directory to send backups of transaction logs between MS SQL Server instances (for example, 'D:\Shared')
AS
/*
Moving the standby server to the main mode when the principal server is down if @ isfailover = 1 is fully automated
when @isfailover equals 0, nothing happens - here we need to create anew the shipping log from the standby to the principal one,
and then we need to switch to the principal server and then to configure the transaction log shipping again.
this standby server is believed to receive backups of transaction logs from one server
*/
BEGIN
--if there is a shift switch to a standby server, you need to perform all the tasks to copy the latest files from the source
if(@isfailover=1)
begin
select [job_id]
into #jobs
from [msdb].[dbo].[sysjobs]
where [name] like 'LSCopy%';
declare @job_id uniqueidentifier;
while(exists(select top(1) 1 from #jobs))
begin
select top(1)
@job_id=[job_id]
from #jobs;
begin try
EXEC [msdb].dbo.sp_start_job @[email protected]_id;
end try
begin catch
end catch
delete from #jobs
where [job_id][email protected]_id;
end
drop table #jobs;
end
--disable all the tasks for copying files from the source when switching to the backup server
--enable all the tasks for copying files from the source when returning to the production server
update [msdb].[dbo].[sysjobs]
set [enabled]=case when (@isfailover=1) then 0 else 1 end
where [name] like 'LSCopy%';
--if we shift to a standby server, we need to perform all the tasks to restore databases by using the latest files from the source
if(@isfailover=1)
begin
select [job_id]
into #jobs2
from [msdb].[dbo].[sysjobs]
where [name] like 'LSRestore%';
while(exists(select top(1) 1 from #jobs2))
begin
select top(1)
@job_id=[job_id]
from #jobs2;
begin try
EXEC [msdb].dbo.sp_start_job @[email protected]_id;
EXEC [msdb].dbo.sp_start_job @[email protected]_id;
end try
begin catch
end catch
delete from #jobs2
where [job_id][email protected]_id;
end
drop table #jobs2;
end
--disable all the tasks to restore databases using the latest files from the source when switching to a standby server
--enable all the tasks to restore databases using the latest files when returning to the production server
update [msdb].[dbo].[sysjobs]
set [enabled]=case when (@isfailover=1) then 0 else 1 end
where [name] like 'LSRestore%';
--when switching to a standby server, we make the database restorable and principal for log shipping without a recipient
if(@isfailover=1)
begin
select [secondary_database] as [name]
into #dbs
from msdb.dbo.log_shipping_monitor_secondary
where [secondary_server][email protected]@SERVERNAME;
declare @db nvarchar(255);
while(exists(select top(1) 1 from #dbs))
begin
select top(1)
@db=[name]
from #dbs;
begin try
RESTORE DATABASE @db WITH RECOVERY;
end try
begin catch
end catch
delete from #dbs
where [name][email protected];
end
drop table #dbs;
select [secondary_database] as [name]
into #dbs2
from msdb.dbo.log_shipping_monitor_secondary
where [secondary_server][email protected]@SERVERNAME;
declare @jobId BINARY(16);
declare @command nvarchar(max);
declare @dt nvarchar(255)=cast(YEAR(GetDate()) as nvarchar(255))
+'_'+cast(MONTH(GetDate()) as nvarchar(255))
+'_'+cast(DAY(GetDate()) as nvarchar(255))
+'_'+cast(DatePart(hour,GetDate()) as nvarchar(255))
+'_'+cast(DatePart(minute,GetDate()) as nvarchar(255))
+'.trn';
declare @backup_job_name nvarchar(255);
declare @schedule_name nvarchar(255);
declare @disk nvarchar(255);
declare @uid uniqueidentifier;
while(exists(select top(1) 1 from #dbs2))
begin
select top(1)
@db=[name]
from #dbs2;
set @[email protected]_directory+N'\'[email protected]+N'.bak';
set @backup_job_name=N'LSBackup_'[email protected];
set @schedule_name=N'LSBackupSchedule_'[email protected]@SERVERNAME+N'_'[email protected];
set @command=N'declare @disk nvarchar(max)='+N''''[email protected]_directory+N'\'[email protected]+'_'[email protected]+N''''
+N'BACKUP LOG ['[email protected]+'] TO DISK = @disk
WITH NOFORMAT, NOINIT, NAME = '+N''''[email protected]+N''''+N', SKIP, NOREWIND, NOUNLOAD, STATS = 10;';
set @uid=newid();
begin try
BACKUP DATABASE @db TO DISK = @disk
WITH NOFORMAT, NOINIT, NAME = @db, SKIP, NOREWIND, NOUNLOAD, STATS = 10;
EXEC msdb.dbo.sp_add_job @[email protected]_job_name,
@enabled=1,
@notify_level_eventlog=0,
@notify_level_email=0,
@notify_level_netsend=0,
@notify_level_page=0,
@delete_level=0,
@description=N'No description available.',
@category_name=N'[Uncategorized (Local)]',
@[email protected], @job_id = @jobId OUTPUT;
EXEC msdb.dbo.sp_add_jobstep @[email protected], @[email protected]_job_name,
@step_id=1,
@cmdexec_success_code=0,
@on_success_action=1,
@on_success_step_id=0,
@on_fail_action=2,
@on_fail_step_id=0,
@retry_attempts=0,
@retry_interval=0,
@os_run_priority=0, @subsystem=N'TSQL',
@[email protected],
@database_name=N'master',
@flags=0;
EXEC msdb.dbo.sp_update_job @job_id = @jobId, @start_step_id = 1;
EXEC msdb.dbo.sp_add_jobschedule @[email protected], @[email protected]_job_name,
@enabled=1,
@freq_type=4,
@freq_interval=1,
@freq_subday_type=4,
@freq_subday_interval=5,
@freq_relative_interval=0,
@freq_recurrence_factor=0,
@active_start_date=20171009,
@active_end_date=99991231,
@active_start_time=0,
@active_end_time=235959,
@[email protected];
EXEC msdb.dbo.sp_add_jobserver @job_id = @jobId, @server_name = N'(local)';
end try
begin catch
end catch
delete from #dbs2
where [name][email protected];
end
drop table #dbs2;
end
END Om terug te keren naar de hoofdserver, is het noodzakelijk om de verzending van het transactielogboek van de standby-server naar de hoofdserver te configureren en vervolgens de foutopsporing van een failover uit te voeren. Vervolgens wordt de hoofdserver de productieserver. Daarna moet u de verzending van het transactielogboek configureren van de productieserver naar de stand-byserver.
Automatische aanpassing configureren voor het bewaken van de verzending van het transactielogboek
Gebruik de taak LSAlert_
Heel vaak neemt de monitoringserver (als het geen productieserver is) na verloop van tijd ten onrechte de recente tijd voor het maken van een back-up van het databasetransactielogboek op de productieserver. Als gevolg hiervan krijgen we te maken met valse waarschuwingen.
Het is mogelijk om het probleem op te lossen met het volgende script:
Een voorbeeld van het configureren van de aanpassing voor het bewaken van verzending van transactielogboeken
CREATE PROCEDURE [srv].[AutoCorrectMonitorLogShipping]
AS
BEGIN
/*
Adjustment of monitoring the transaction log shipping
*/
SET NOCOUNT ON;
update t2
set
t2.[last_backup_date]=t1.[BackupFinishDate]
,t2.[last_backup_date_utc]=DateAdd(hour,-DateDiff(hour,GetUTCDate(),GetDate()),t1.[BackupFinishDate])
,t2.[last_backup_file]=
RIGHT(t1.[PhysicalDeviceName], CHARINDEX('\',REVERSE(t1.[PhysicalDeviceName]),1)-1)
from [PRODUCTION_INSTANCE_NAME].[SRV].[inf].[vServerLastBackupDB] as t1
inner join [msdb].[dbo].[log_shipping_monitor_primary] as t2 on t1.[DBName] collate SQL_Latin1_General_CP1_CI_AS=t2.[primary_database] collate SQL_Latin1_General_CP1_CI_AS
where t1.[BackupType]=N'log';
END We kunnen een oproep voor een opgeslagen procedure automatiseren op tijd. We kunnen bijvoorbeeld een passende taak aanmaken in de Agent en deze elke 5 minuten inplannen. Natuurlijk moet de productieserver zijn gekoppeld aan de back-upserver (Serverobjecten\Gekoppelde servers).
Hier gebruiken we de [inf].[vServerLastBackupDB]-weergave in de SRV-database die de nieuwste databaseback-ups definieert:
Een voorbeeld van het implementeren van de vServerLastBackupDB-weergave:
CREATE VIEW [inf].[vServerLastBackupDB] as
with backup_cte as
(
select
bs.[database_name],
backup_type =
case bs.[type]
when 'D' then 'database'
when 'L' then 'log'
when 'I' then 'differential'
else 'other'
end,
bs.[first_lsn],
bs.[last_lsn],
bs.[backup_start_date],
bs.[backup_finish_date],
cast(bs.[backup_size] as decimal(18,3))/1024/1024 as BackupSizeMb,
rownum =
row_number() over
(
partition by bs.[database_name], type
order by bs.[backup_finish_date] desc
),
LogicalDeviceName = bmf.[logical_device_name],
PhysicalDeviceName = bmf.[physical_device_name],
bs.[server_name],
bs.[user_name]
FROM msdb.dbo.backupset bs
INNER JOIN msdb.dbo.backupmediafamily bmf
ON [bs].[media_set_id] = [bmf].[media_set_id]
)
select
[server_name] as [ServerName],
[database_name] as [DBName],
[user_name] as [USerName],
[backup_type] as [BackupType],
[backup_start_date] as [BackupStartDate],
[backup_finish_date] as [BackupFinishDate],
[BackupSizeMb], -- uncompressed size
[LogicalDeviceName],
[PhysicalDeviceName],
[first_lsn] as [FirstLSN],
[last_lsn] as [LastLSN]
from backup_cte
where rownum = 1; Resultaat
In dit artikel hebben we kort alle mogelijke fouttolerantie- en snelle beschikbaarheidsopties in MS SQL Server 2017 besproken, evenals voorbeelden van het implementeren van debuggen van failover en automatische aanpassing van het bewaken van de verzending van het transactielogboek.
Referenties:
- msdb
- Beschikbare SQL Server 2017-edities
- Altijd aan
- SQL Server Failover Cluster Installatie
- Replicatie
- Spiegelen
- Verzending loggen
- Log verzending configureren