Pengantar
Seringkali, kita perlu memastikan toleransi kesalahan DBMS MS SQL Server, terutama, ketika tidak ada edisi Enterprise, tetapi hanya edisi Standar.
Kami ingin mencatat bahwa kami tidak akan memeriksa edisi Express karena ada batasan signifikan untuk instance ini. Tentu, kita bisa melewati beberapa dari mereka. Misalnya, untuk mengatasi masalah dengan ukuran database 10 GB, kita dapat membagi database besar menjadi yang lebih kecil. Untuk melakukan ini, kita dapat membuat database baru berdasarkan properti tertentu, dan menggabungkan pilihan dari tabel yang sama dari database yang berbeda dalam tampilan di database utama. Namun, toleransi kesalahan dalam edisi Express akan dilakukan oleh administrator sistem atau dengan menggunakan perangkat lunak Anda sendiri atau pihak ketiga.
Dalam artikel ini, kita akan menjelajahi semua teknologi toleransi kesalahan standar yang ada untuk MS SQL Server 2017 dan contoh penerapan standar toleransi kesalahan terpadu yang paling sesuai dalam edisi Standar.
Ulasan singkat
-
Selalu Aktif
Distribusi beban di antara semua pihak, semua pihak harus memiliki karakteristik yang sama satu sama lain.Mode sinkron memastikan keandalan transmisi data maksimum; namun, performanya akan sama dengan kecepatan party paling lambat. Mode asinkron memastikan kinerja tertinggi, tetapi mungkin ada ketidakcocokan data antara kedua pihak, yang dapat menyebabkan pemeliharaan yang lebih kompleks dan kemungkinan kehilangan perubahan terbaru jika terjadi kegagalan pihak utama. Kecepatan beralih ke mode sinkron hampir seketika dan tidak memerlukan administrator sistem dan DBA, sedangkan dalam mode asinkron, itu tergantung pada keadaan duplikat DB saat ini dan biasanya memakan waktu sekitar 5 menit (Anda juga dapat mengotomatiskan proses peralihan dengan satu DBA tanpa administrator sistem ).Microsoft merekomendasikan penggunaan teknologi ini untuk database. Ini tersedia dalam edisi Enterprise mulai dari versi 2012 dan yang lebih tinggi dan dengan batasan dalam edisi Standar (Untuk mempelajari lebih lanjut, lihat 5 Pertanyaan Teratas tentang Grup Ketersediaan Dasar).
-
Pengelompokan
Terlepas dari kesederhanaan konfigurasi, solusi ini tidak dapat diandalkan karena hambatan dalam bentuk gudang data tunggal. Jika terjadi kegagalan gudang data, diperlukan waktu lebih dari 1 jam untuk memulihkannya. Teknologi ini tersedia dalam edisi Standar versi 2008 dan lebih tinggi.
-
Replikasi
Replikasi apa pun melibatkan pembuatan pemicu sistem untuk setiap tabel yang berpartisipasi sementara replikasi snapshot akan banyak memuat database utama. Oleh karena itu, replikasi snapshot dapat dilakukan hanya selama jam tidak sibuk dari beban database (misalnya, pada malam hari), yang tidak dapat diterima, karena siaga panas diperlukan. Replikasi penggabungan rumit untuk dikelola oleh beberapa sistem (misalnya, CRM, NAV).
Replikasi transaksional dimungkinkan dalam edisi Enterprise. Tersedia dalam edisi Standar (penggabungan dan cuplikan database) dan edisi Enterprise (transaksi) hingga versi 2008 dan yang lebih tinggi. -
Pencerminan
Hal ini dimungkinkan dalam mode apapun. Namun, mode sinkron memastikan keandalan maksimum dan peralihan cepat, sedangkan mode asinkron memberi pengguna kecepatan kinerja maksimum dari basis data utama. Namun, data yang tidak cocok mungkin terjadi antara pihak-pihak dan peralihan mungkin lambat.
Di sini, server saksi atau DBA menyediakan sakelar otomatis di tingkat basis data (misalnya, ketika beban CPU lebih dari 50% di server utama). Administrator sistem memberikan koneksi ke server lain. Basis data cadangan untuk semua jenis pencerminan berada dalam mode pemulihan berkelanjutan, sehingga tidak dapat diakses.
Mode pemulihan database penuh.
Microsoft menganggapnya sebagai teknologi database yang ketinggalan zaman. Ini tersedia dalam edisi Standar (dalam mode sinkron) dan dalam edisi Enterprise (dalam mode asinkron) hingga versi 2008 dan lebih tinggi.
-
Pengiriman log transaksi
Ada dua mode:pemulihan berkelanjutan di server siaga atau pemulihan dengan penundaan. Mode pertama mengalihkan basis data cadangan ke mode pemulihan berkelanjutan dan dalam hal ini, kami tidak dapat mengaksesnya.
Mode kedua mengalihkan basis data cadangan ke mode pemulihan secara teratur saat menerapkan pembaruan (basis data cadangan tersedia di antara penerapan, tetapi ini dimungkinkan asalkan instance MS SQL Server memiliki versi yang sama).
Cara kerjanya:
- Secara berkala, salinan cadangan dari log transaksi database disimpan ke folder publik di server sumber dan standby (direktori dan jadwal dikonfigurasi setiap 15 menit secara default).
- Server siaga secara berkala menyalin cadangan log transaksi dari database ke folder lokal (direktori dan jadwal dikonfigurasi setiap 15 menit secara default).
- Server siaga memulihkan log transaksi dari cadangan log transaksi (jadwal dikonfigurasi setiap 15 menit secara default).
Administrator basis data dapat mengotomatiskan proses peralihan di tingkat basis data, sementara administrator sistem dapat melakukan ini di tingkat koneksi ke server.
Juga, perlu dicatat bahwa metode ini selalu bekerja dalam mode asinkron. Anda dapat mengonfigurasi beberapa basis data cadangan.
Mode pemulihan basis data penuh atau dicatat secara massal.
Ini tersedia dalam edisi Standar hingga versi 2008 dan lebih tinggi.
Ada dua mode:pemulihan berkelanjutan di server siaga atau pemulihan dengan penundaan.
Ringkasan
Yang paling disukai adalah pengiriman log transaksi dalam edisi Standar karena nyaman digunakan untuk transisi yang mulus dari satu server ke server lain, misalnya, saat memperbarui lingkungan. Selain itu, pengiriman log transaksi sederhana dan mudah digunakan, serta selalu berfungsi dalam mode asinkron, yang tidak banyak memuat basis data, tidak seperti mode pencerminan sinkron. Bagaimanapun, pencerminan dapat diterima, jika dimungkinkan untuk mengonfigurasi peralihan otomatisnya sendiri; jika tidak, pengalihan palsu dimungkinkan (misalnya, ketika CPU server utama dimuat lebih dari 50%).
Untuk edisi Enterprise, gunakan teknologi AlwaysOn.
Mengonfigurasi failover setelah pengiriman log transaksi
Anda dapat menemukan informasi lebih rinci tentang konfigurasi pengiriman log transaksi di sini. Selain itu, dimungkinkan untuk mengotomatiskan proses ini dengan mengembangkan utilitas Anda sendiri untuk beberapa penggunaan berulang, serta untuk kembali ke server utama setelah diperbaiki jika terjadi failover.
Mari kita jelajahi salah satu opsi yang memungkinkan untuk men-debug failover setelah pengiriman log transaksi di tingkat DBMS.
Perlu dicatat bahwa metode ini cocok untuk server yang dicadangkan hanya untuk satu instance MS SQL Server, karena, untuk beberapa instance, ada masalah dalam menentukan tugas mana yang harus dijalankan dan mana yang tidak.
Mari kita jelaskan urutan langkah-langkahnya:
- Lakukan semua tugas untuk menyalin file terbaru dari sumbernya (Dengan arsitektur yang dipikirkan dengan matang, direktori harus dapat diakses meskipun server utama sedang down)
- Nonaktifkan semua tugas untuk menyalin file dari sumbernya
- Lakukan semua tugas untuk memulihkan database menggunakan file terbaru dari sumbernya
- Nonaktifkan semua tugas pemulihan database menggunakan file terbaru dari sumbernya
- Buat database dipulihkan dan menjadi prinsipal untuk pengiriman log, tetapi tanpa penerima
- Buat cadangan lengkap database
- Buat tugas untuk mencadangkan log transaksi
Di bawah ini, ada contoh penerapan urutan yang disebutkan di atas sebagai prosedur tersimpan.
Perlu dicatat bahwa penting untuk mengonfigurasi login (sebaiknya login domain) di mana tugas akan dilakukan untuk membuat cadangan log transaksi.
Contoh men-debug failover pengiriman log transaksi
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 Untuk kembali ke server utama, perlu untuk mengonfigurasi pengiriman log transaksi dari server siaga ke server utama, dan kemudian melakukan debug dari failover. Kemudian, server utama akan menjadi server produksi. Setelah itu, Anda perlu mengkonfigurasi pengiriman log transaksi dari server produksi ke server siaga.
Mengonfigurasi penyesuaian otomatis untuk memantau pengiriman log transaksi
Untuk memantau pengiriman log transaksi, gunakan tugas LSAlert_
Cukup sering, dari waktu ke waktu, server pemantau (jika bukan produksi) salah mengambil waktu baru-baru ini untuk membuat cadangan log transaksi database di server produksi. Akibatnya, kami menghadapi peringatan palsu.
Dimungkinkan untuk menyelesaikan masalah menggunakan skrip berikut:
Contoh mengonfigurasi penyesuaian untuk memantau pengiriman log transaksi
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 Kami dapat mengotomatiskan panggilan untuk prosedur tersimpan berdasarkan waktu. Misalnya, kita dapat membuat tugas yang sesuai di Agen dan menjadwalkannya setiap 5 menit. Tentu saja, server produksi harus ditautkan ke server cadangan (Objek server\Server tertaut).
Di sini kita menggunakan tampilan [inf].[vServerLastBackupDB] di database SRV yang mendefinisikan backup database terbaru:
Contoh penerapan tampilan vServerLastBackupDB:
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; Hasil
Dalam artikel ini, kami telah meninjau secara singkat semua kemungkinan toleransi kesalahan dan opsi ketersediaan cepat di MS SQL Server 2017, serta contoh penerapan debugging failover dan penyesuaian otomatis pemantauan pengiriman log transaksi.
Referensi:
- msdb
- Edisi SQL Server 2017 yang tersedia
- Selalu Aktif
- Penginstalan Cluster Failover SQL Server
- Replikasi
- Mencerminkan
- Pengiriman Log
- Konfigurasikan Pengiriman Log
