Gunakan penyemaian otomatis untuk menginisialisasi replika sekunder untuk grup ketersediaan AlwaysOn

Berlaku untuk:SQL Server

Di SQL Server 2012 dan 2014, satu-satunya cara untuk menginisialisasi replika sekunder dalam grup ketersediaan AlwaysOn SQL Server adalah dengan menggunakan pencadangan, penyalinan, dan pemulihan. SQL Server 2016 memperkenalkan fitur baru untuk menginisialisasi replika sekunder - penyemaian otomatis. Penyemaian otomatis menggunakan transpor aliran log untuk mengalirkan backup dengan menggunakan VDI ke replika sekunder untuk setiap database dalam grup ketersediaan melalui endpoint yang dikonfigurasi. Fitur baru ini dapat digunakan baik selama pembuatan awal grup ketersediaan atau saat database ditambahkan ke grup ketersediaan. Penyemaian otomatis ada di semua edisi SQL Server yang mendukung grup ketersediaan AlwaysOn, dan dapat digunakan dengan grup ketersediaan tradisional dan grup ketersediaan terdistribusi.

Keamanan

Izin keamanan bervariasi tergantung pada jenis replika yang diinisialisasi:

Untuk grup ketersediaan tradisional, izin harus diberikan kepada grup ketersediaan pada replika sekunder saat replika tersebut ditambahkan ke grup ketersediaan. Di Transact-SQL, gunakan perintah ALTER AVAILABILITY GROUP [<AGName>] GRANT CREATE ANY DATABASE.
Untuk grup ketersediaan terdistribusi di mana database replika yang sedang dibuat berada di replika utama grup ketersediaan kedua, tidak ada izin tambahan yang diperlukan karena sudah menjadi primer. Namun, jika hanya ada satu replika pada grup ketersediaan kedua, maka berikan CREATE ANY DATABASE izin ke nama grup ketersediaan sekunder, atau penyemaian otomatis mungkin gagal.
Untuk replika sekunder pada grup ketersediaan kedua dari grup ketersediaan terdistribusi, Anda harus menggunakan perintah ALTER AVAILABILITY GROUP [<2ndAGName>] GRANT CREATE ANY DATABASE. Replika sekunder ini diinisialisasi dari replika utama pada grup ketersediaan kedua.

Dampak log performa dan transaksi pada replika utama

Penyemaian otomatis mungkin atau mungkin tidak praktis untuk menginisialisasi replika sekunder, tergantung pada ukuran database, kecepatan jaringan, dan jarak antara replika primer dan sekunder. Misalnya, diberikan:

Ukuran database adalah 5 TB
Kecepatan jaringan adalah 1Gb/detik
Jarak antara kedua situs adalah 1000 mil

Jika bandwidth penuh tersedia, jaringan 1Gb/detik dapat menyediakan throughput berkelanjutan sebesar 125 MB/detik. Dalam contoh ini, penyemaian otomatis akan memakan waktu hanya lebih dari 11 jam. Dalam praktiknya, proses seeding otomatis lebih lambat karena sinyal jaringan melemah pada jarak yang lebih jauh dan tautan tersebut digunakan bersama sumber daya lain di jaringan. Selama penyemaian, log transaksi pada database di replika utama terus bertambah dan tidak dapat dipotong sampai penyemaian otomatis database tersebut selesai. Log transaksi kemudian dapat dipotong menggunakan cadangan log transaksi.

Pengisian awal otomatis adalah proses utas tunggal yang dapat menangani hingga lima basis data. Pemrosesan single-thread memengaruhi kinerja, terutama jika grup ketersediaan memiliki lebih dari satu basis data.

Pemadatan dapat digunakan untuk seeding otomatis, tetapi dinonaktifkan secara default. Mengaktifkan kompresi mengurangi bandwidth jaringan dan mungkin mempercepat proses, tetapi konsekuensinya adalah beban tambahan pada prosesor. Untuk menggunakan kompresi selama seeding otomatis, aktifkan flag pelacakan 9567 - lihat Menyetel kompresi untuk grup ketersediaan.

Tata letak disk

Di SQL Server 2016 dan sebelumnya, folder tempat database dibuat oleh seeding otomatis harus sudah ada dan sama dengan jalur pada replika utama.

Di SQL Server 2017, Microsoft merekomendasikan penggunaan data yang sama dan jalur file log pada semua replika yang berpartisipasi dalam grup ketersediaan tetapi Anda dapat menggunakan jalur yang berbeda jika perlu. Misalnya, dalam grup ketersediaan lintas platform, satu instans SQL Server ada di Windows dan instans SQL Server lain berada di Linux. Platform yang berbeda memiliki jalur default yang berbeda. SQL Server 2017 mendukung replika grup ketersediaan pada instans SQL Server dengan jalur default yang berbeda.

Tabel berikut menyajikan contoh tata letak disk data yang didukung yang dapat mendukung seeding otomatis:

Instans utama Jalur data default	Instans sekunder Jalur data default	Instans utama Lokasi file sumber	Instans sekunder Lokasi file target
c:\data\	/var/opt/mssql/data/	c:\data\	/var/opt/mssql/data/
c:\data\	/var/opt/mssql/data/	c:\data\group1\	/var/opt/mssql/data/group1/
c:\data\	d:\data\	c:\data\	d:\data\
c:\data\	d:\data\	c:\data\group1\	d:\data\group1\

Skenario di mana lokasi database replika primer dan sekunder bukan jalur default instans tidak terpengaruh oleh perubahan ini. Persyaratan untuk jalur file replika sekunder agar sesuai dengan jalur file replika utama tetap sama.

Instans utama Jalur data default	Instans sekunder Jalur data default	Instans utama lokasi file	Lokasi file instans sekunder
c:\data\	c:\data\	d:\group1\	d:\group1\
c:\data\	c:\data\	d:\data\	d:\data\
c:\data\	c:\data\	d:\data\group1\	d:\data\group1\

Jika Anda mencampur jalur default dan non default pada replika utama dan sekunder, SQL Server 2017 bereaksi berbeda dari rilis sebelumnya. Tabel berikut ini memperlihatkan perilaku SQL Server 2017.

Instans utama Jalur data default	Instans sekunder Jalur data default	Instans utama lokasi file	Lokasi File instans Sekunder SQL Server 2016	Lokasi File instans sekunder SQL Server 2017
c:\data\	d:\data\	c:\data\	c:\data\	d:\data\
c:\data\	d:\data\	c:\data\group1\	c:\data\group1\	d:\data\group1\

Untuk kembali ke perilaku untuk SQL Server 2016 dan sebelumnya, aktifkan bendera pelacakan 9571. Untuk informasi tentang cara mengaktifkan bendera pelacakan, lihat DBCC TRACEON (Transact-SQL).

Membuat grup ketersediaan dengan seeding otomatis

Anda membuat grup ketersediaan menggunakan seeding otomatis dengan Transact-SQL atau SQL Server Management Studio (SSMS, versi 17 atau yang lebih baru). Untuk menggunakan Wizard Grup Ketersediaan di SSMS, ikuti instruksi ini - saat Anda masuk ke Langkah 9, perhatikan bahwa seeding otomatis adalah opsi pertama, dan default.

Pilih sinkronisasi data awal

Contoh berikut membuat grup ketersediaan dengan seeding otomatis menggunakan Transact-SQL. Lihat juga topik Membuat Grup Ketersediaan (Transact-SQL). Proses seeding diaktifkan pada replika sekunder dengan menetapkan opsi SEEDING_MODE ke AUTOMATIC. Perilaku defaultnya adalah MANUAL, yang merupakan perilaku pra-SQL Server 2016 - mengharuskan pencadangan database dibuat pada replika utama, salinan file cadangan ke replika sekunder, dan pemulihan cadangan WITH NORECOVERY.

CREATE AVAILABILITY GROUP [<AGName>]
  FOR DATABASE db1
  REPLICA ON N'Primary_Replica'
WITH (
  ENDPOINT_URL = N'TCP://Primary_Replica.Contoso.com:5022', 
  FAILOVER_MODE = AUTOMATIC, 
  AVAILABILITY_MODE = SYNCHRONOUS_COMMIT
),
  N'Secondary_Replica' WITH (
    ENDPOINT_URL = N'TCP://Secondary_Replica.Contoso.com:5022', 
    FAILOVER_MODE = AUTOMATIC, 
    SEEDING_MODE = AUTOMATIC);
 GO

Pengaturan SEEDING_MODE pada replika utama selama CREATE AVAILABILITY GROUP pernyataan tidak berpengaruh karena replika utama sudah berisi salinan baca/tulis utama database. SEEDING_MODE hanya akan berlaku ketika replika lain dibuat sebagai primer dan database ditambahkan. Mode penyemaian dapat diubah nanti - lihat Mengubah mode penyemaian replika.

Pada instans yang menjadi replika sekunder, setelah instans digabungkan, pesan berikut ditambahkan ke Log SQL Server:

Replika ketersediaan lokal untuk grup ketersediaan 'AGName' belum diberikan izin untuk membuat basis data, tetapi memiliki SEEDING_MODE sebesar AUTOMATIC. Gunakan ALTER AVAILABILITY GROUP ... GRANT CREATE ANY DATABASE untuk mengizinkan pembuatan database yang disemai oleh replika ketersediaan utama.

Memberikan izin buat database pada replika sekunder ke grup ketersediaan

Setelah bergabung, berikan izin grup ketersediaan untuk membuat database pada instans replika sekunder SQL Server. Agar penyemaian otomatis berfungsi, grup ketersediaan memerlukan izin untuk membuat database.

Tips

Ketika grup ketersediaan membuat database pada replika sekunder, grup tersebut menetapkan "sa" (lebih khusus akun dengan sid 0x01) sebagai pemilik database.

Untuk mengubah pemilik database setelah replika sekunder secara otomatis membuat database, gunakan ALTER AUTHORIZATION. Lihat ALTER AUTHORIZATION (Transact-SQL) .

Contoh berikut memberikan izin ini ke grup ketersediaan yang disebut AGName.

ALTER AVAILABILITY GROUP [<AGName>] 
    GRANT CREATE ANY DATABASE
 GO

Jika perlu atur pemilik database pada replika sekunder.

Verifikasi seeding otomatis

Jika berhasil, database secara otomatis dibuat pada replika sekunder dengan status:

DISINKRONKAN jika replika sekunder dikonfigurasi agar sinkron dan data disinkronkan.
MENYINKRONKAN jika replika sekunder dikonfigurasi dengan pergerakan data asinkron, atau ketika dikonfigurasi dengan sinkron tetapi belum disinkronkan dengan replika utama.

Selain Dynamic Management Views yang dijelaskan di bawah ini, dimulainya dan selesainya seeding otomatis dapat dilihat di log SQL Server:

Log SQL Server

Menggabungkan pencadangan dan pemulihan dengan seeding otomatis

Dimungkinkan untuk menggabungkan cadangan tradisional, menyalin, dan memulihkan dengan seeding otomatis. Dalam hal ini, pertama-tama pulihkan database pada replika sekunder termasuk semua log transaksi yang tersedia. Selanjutnya, aktifkan pengisian otomatis saat membuat grup ketersediaan untuk "menyelaraskan" database pada replika sekunder, seolah-olah cadangan tail-log telah dipulihkan (lihat Tail-Log Backups (SQL Server)).

Tambahkan database ke grup ketersediaan dengan penyemaian otomatis

Anda dapat menambahkan database ke grup ketersediaan menggunakan seeding otomatis menggunakan Transact-SQL atau SQL Server Management Studio (SSMS, versi 17 atau yang lebih baru). Jika replika sekunder menggunakan penyemaian otomatis saat ditambahkan ke grup ketersediaan, tidak ada tambahan yang perlu dilakukan. Jika replika sekunder menggunakan cadangan, salin, dan pemulihan, pertama-tama ubah mode seeding (lihat bagian berikutnya) lalu saat menambahkan database gunakan GRANT pernyataan - lihat Grup Ketersediaan - Tambahkan Database.

Mengubah mode penyemaian replika

Mode penyemaian replika dapat diubah setelah grup ketersediaan dibuat, yang memungkinkan penyemaian otomatis diaktifkan atau dinonaktifkan. Mengaktifkan seeding otomatis setelah database dibuat memungkinkan database ditambahkan ke grup ketersediaan menggunakan seeding otomatis jika database tersebut dibuat melalui pencadangan, penyalinan, dan pemulihan. Contohnya:

ALTER AVAILABILITY GROUP [AGName]
  MODIFY REPLICA ON 'Replica_Name'
  WITH (SEEDING_MODE = AUTOMATIC)

Untuk menonaktifkan seeding otomatis, gunakan nilai MANUAL.

Mencegah penyemaian otomatis setelah grup ketersediaan dibuat

Jika Anda tidak ingin sepenuhnya menonaktifkan seeding otomatis untuk replika sekunder, tetapi ingin sementara mencegah replika sekunder agar tidak dapat membuat database secara otomatis, tolak izin CREATE pada grup ketersediaan. Ini adalah kasus ketika database baru ditambahkan ke grup ketersediaan, tetapi grup ketersediaan tidak boleh diizinkan untuk membuat database pada replika sekunder.

ALTER AVAILABILITY GROUP [AGName] 
    DENY CREATE ANY DATABASE
GO

Pantau seeding otomatis

Ada empat cara untuk memantau dan memecahkan masalah penyemaian otomatis:

SQL Server Log seperti yang sudah dijelaskan
Tampilan manajemen dinamis
Tabel riwayat cadangan
Kejadian yang diperluas

Tampilan Manajemen Dinamis

Ada dua tampilan manajemen dinamis (DMV) untuk memantau seeding: sys.dm_hadr_automatic_seeding dan sys.dm_hadr_physical_seeding_stats.

sys.dm_hadr_automatic_seeding memuat status umum penyemaian otomatis dan menyimpan riwayat setiap kali dijalankan (baik berhasil maupun tidak). Kolom current_state memiliki nilai COMPLETED atau FAILED. Jika nilai GAGAL, gunakan nilai di failure_state_desc untuk membantu mendiagnosis masalah. Anda mungkin perlu menggabungkannya dengan apa yang ada di Log SQL Server untuk melihat apa yang salah. DMV ini diisi pada replika utama dan semua replika sekunder.
sys.dm_hadr_physical_seeding_stats menunjukkan status operasi penyemaian otomatis saat dijalankan. Seperti halnya sys.dm_hadr_automatic_seeding, ini mengembalikan nilai untuk replika primer dan sekunder, tetapi riwayat ini tidak disimpan. Nilai-nilai tersebut hanya berlaku untuk eksekusi saat ini dan tidak disimpan. Kolom yang relevan meliputi start_time_utc, end_time_utc, estimate_time_complete_utc, total_disk_io_wait_time_ms, total_network_wait_time_ms, dan, jika operasi seeding gagal, failure_message.

Tabel riwayat cadangan

Seeding otomatis juga memasukkan entri ke tabel msdb yang menyimpan riwayat pencadangan dan pemulihan. Pada replika sekunder yang menerima seeding otomatis, kolom physical_device_name pada tabel backupmediafamily memiliki GUID sebagai nilainya, dan entri yang sesuai di backupset berisi nama replika utama untuk server_name dan machine_name.

Aktivitas yang Diperluas

Penyemaian otomatis menambahkan peristiwa baru yang diperluas untuk melacak perubahan status, kegagalan, dan statistik performa selama inisialisasi. Misalnya, skrip berikut membuat sesi peristiwa yang diperluas yang menangkap peristiwa yang terkait dengan penyemaian otomatis.

CREATE EVENT SESSION [AlwaysOn_autoseed] ON SERVER 
    ADD EVENT sqlserver.hadr_automatic_seeding_state_transition,
    ADD EVENT sqlserver.hadr_automatic_seeding_timeout,
    ADD EVENT sqlserver.hadr_db_manager_seeding_request_msg,
    ADD EVENT sqlserver.hadr_physical_seeding_backup_state_change,
    ADD EVENT sqlserver.hadr_physical_seeding_failure,
    ADD EVENT sqlserver.hadr_physical_seeding_forwarder_state_change,
    ADD EVENT sqlserver.hadr_physical_seeding_forwarder_target_state_change,
    ADD EVENT sqlserver.hadr_physical_seeding_progress,
    ADD EVENT sqlserver.hadr_physical_seeding_restore_state_change,
    ADD EVENT sqlserver.hadr_physical_seeding_submit_callback
    ADD TARGET package0.event_file(
        SET filename=N'autoseed.xel',
        max_file_size=(5),
        max_rollover_files=(4)
        )
    WITH (
        MAX_MEMORY=4096 KB,
        EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,
        MAX_DISPATCH_LATENCY=30 SECONDS,
        MAX_EVENT_SIZE=0 KB,
        MEMORY_PARTITION_MODE=NONE,
        TRACK_CAUSALITY=OFF,
        STARTUP_STATE=ON
        )
GO

ALTER EVENT SESSION AlwaysOn_autoseed ON SERVER STATE=START
GO

Tabel berikut mencantumkan peristiwa tambahan yang terkait dengan seeding otomatis.

Nama	Deskripsi
hadr_db_manager_seeding_request_msg	Pesan permintaan penyemaian.
perubahan status pencadangan penyemaian fisik HADR	Perubahan status sisi pencadangan seeding fisik.
hadr_physical_seeding_restore_state_change	Perubahan status sisi pemulihan penyemaian fisik.
hadr_physical_seeding_forwarder_state_change	Perubahan status sisi penerus seeding fisik.
hadr_penyemaian_fisik_penerus_perubahan_status_target	Perubahan status sisi target penerus seeding fisik.
hadr_physical_seeding_submit_callback	Penyemaian fisik mengirimkan peristiwa panggilan balik.
hadr_physical_seeding_failure	Peristiwa kegagalan penyemaian fisik.
hadr_physical_seeding_progress	Peristiwa kemajuan penyemaian fisik.
hadr_physical_seeding_schedule_long_task_failure	Peristiwa kegagalan tugas yang berjalan lama pada jadwal seeding fisik.
hadr_automatic_seeding_start	Terjadi ketika operasi penyemaian otomatis diajukan.
hadr_penyemaian_otomatis_transisi_status	Terjadi ketika operasi penyemaian otomatis berubah status.
hadr_automatic_seeding_success	Terjadi ketika operasi penyemaian otomatis berhasil.
hadr_kegagalan_penyemaian_otomatis	Terjadi ketika operasi seeding otomatis gagal.
hadr_automatic_seeding_timeout	Terjadi ketika waktu operasi penyemaian otomatis habis.

Lihat juga

ALTER AVAILABILITY GROUP (Transact-SQL)

CREATE AVAILABILITY GROUP (Transact-SQL)

Panduan Pemecahan Masalah dan Pemantauan Grup Ketersediaan AlwaysOn

Saran dan Komentar

Apakah halaman ini membantu?

Last updated on 2026-07-21