Meningkatkan atau menambal database yang direplikasi
Berlaku untuk:
SQL Server - Hanya Windows
SQL Server mendukung peningkatan database yang direplikasi dari versi SQL Server sebelumnya; tidak diperlukan untuk menghentikan aktivitas di simpul lain saat node sedang ditingkatkan. Pastikan Anda mematuhi aturan mengenai versi mana yang didukung dalam topologi:
- Distributor dapat menjadi versi apa pun selama lebih besar dari atau sama dengan versi Penerbit (dalam banyak kasus Distributor adalah instans yang sama dengan Penerbit).
- Publisher dapat berupa versi apa pun selama kurang dari atau sama dengan versi Distributor.
- Versi pelanggan tergantung pada jenis publikasi:
- Pelanggan untuk publikasi transaksi dapat berupa versi apa pun dalam dua versi versi Publisher. Misalnya: Penerbit SQL Server 2012 (11.x) dapat memiliki Pelanggan SQL Server 2014 (12.x) dan SQL Server 2016 (13.x) ; dan Penerbit SQL Server 2016 (13.x) dapat memiliki Pelanggan SQL Server 2014 (12.x) dan SQL Server 2012 (11.x).
- Pelanggan untuk publikasi gabungan dapat berupa semua versi yang sama dengan atau lebih rendah dari versi Penerbit yang didukung sesuai siklus dukungan siklus hidup versi.
Jalur peningkatan ke SQL Server berbeda tergantung pada pola penyebaran. SQL Server menawarkan dua jalur peningkatan secara umum:
- Berdampingan: Sebarkan lingkungan paralel dan pindahkan database bersama dengan objek tingkat instans terkait, seperti login, pekerjaan, dll. ke lingkungan baru.
- Peningkatan di tempat: Izinkan media penginstalan SQL Server untuk meningkatkan penginstalan SQL Server yang ada dengan mengganti bit SQL Server, dan meningkatkan objek database. Untuk lingkungan yang menjalankan Grup Ketersediaan AlwaysOn atau Instans Kluster Failover, peningkatan di tempat dikombinasikan dengan peningkatan bergulir untuk meminimalkan waktu henti.
Pendekatan umum yang telah diadopsi untuk peningkatan topologi replikasi berdampingan adalah memindahkan pasangan penerbit-pelanggan dalam bagian ke lingkungan berdampingan baru dibandingkan dengan pergerakan seluruh topologi. Pendekatan bertahap ini membantu mengontrol waktu henti dan meminimalkan dampak hingga batas tertentu bagi bisnis tergantung pada replikasi.
Sebagian besar artikel ini tercakup dalam peningkatan versi SQL Server. Namun, proses peningkatan di tempat juga harus digunakan saat menambal SQL Server dengan paket layanan atau pembaruan kumulatif juga.
Peringatan
Meningkatkan topologi replikasi adalah proses multi-langkah. Sebaiknya coba tingkatkan replika topologi replikasi Anda di lingkungan pengujian sebelum menjalankan peningkatan pada lingkungan produksi aktual. Ini akan membantu menyerika dokumentasi operasional apa pun yang diperlukan untuk menangani peningkatan dengan lancar tanpa menimbulkan waktu henti yang mahal dan lama selama proses peningkatan yang sebenarnya. Kami telah melihat pelanggan mengurangi waktu henti secara signifikan dengan penggunaan Grup Ketersediaan Always On dan/atau Instans Kluster Failover SQL Server untuk lingkungan produksi mereka sambil meningkatkan topologi replikasi mereka. Selain itu, sebaiknya ambil cadangan semua database termasuk MSDB, Master, database Distribusi, dan database pengguna yang berpartisipasi dalam replikasi sebelum mencoba peningkatan.
Saat Anda memiliki database distribusi dalam instans kluster failover, pastikan bahwa semua simpul yang berpartisipasi menggunakan build yang sama. Kami tidak merekomendasikan penyiapan di mana satu simpul adalah versi SQL Server yang lebih lama dari SQL Server 2016 SP2-CU3 atau SQL Server 2017 CU6 dan simpul lainnya adalah versi SQL Server yang lebih lama dari SQL Server 2016 SP2-CU3 atau SQL Server 2017 CU6. Dimulai di SQL Server 2016 SP2-CU3 dan SQL Server 2017 CU6, dukungan ditambahkan untuk menggunakan database distribusi dalam Grup Ketersediaan AlwaysOn dan untuk objek baru (tabel, prosedur tersimpan) dalam database distribusi. Jika database distribusi Anda berada dalam instans kluster failover dan Anda melakukan migrasi bertahap (dan Anda tidak dapat memutakhirkan semua simpul ke versi SQL Server yang sama), untuk jangka waktu migrasi yang sempit, kami sarankan Anda melakukan tugas akun seperti menambahkan pelanggan, langganan, penerbit, atau publikasi baru pada simpul yang memiliki versi SQL Server yang lebih baru.
Matriks Replikasi
Matriks kompatibilitas replikasi transaksional dan rekam jepret
| Penerbit | Distributor | Pelanggan |
|---|---|---|
| SQL Server 2022 (16.x) | SQL Server 2022 (16.x) | SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) |
| SQL Server 2019 (15.x) | SQL Server 2022 (16.x) SQL Server 2019 (15.x) |
SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) |
| SQL Server 2017 (14.x) | SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) |
SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) |
| SQL Server 2016 (13.x) | SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) |
SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) |
| SQL Server 2014 (12.x) | SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) |
SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
| SQL Server 2012 (11.x) | SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) |
SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
| SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
Menggabungkan matriks kompatibilitas replikasi
| Penerbit | Distributor | Pelanggan |
|---|---|---|
| SQL Server 2022 (16.x) | SQL Server 2022 (16.x) | SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
| SQL Server 2019 (15.x) | SQL Server 2022 (16.x) SQL Server 2019 (15.x) |
SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
| SQL Server 2017 (14.x) | SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) |
SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
| SQL Server 2016 (13.x) | SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) |
SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
| SQL Server 2014 (12.x) | SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) |
SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
| SQL Server 2012 (11.x) | SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) |
SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
| SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
Jalankan Agen Pembaca Log untuk Replikasi Transaksional Sebelum Peningkatan
Sebelum memutakhirkan SQL Server, Anda harus memastikan bahwa semua transaksi yang dilakukan dari tabel yang diterbitkan telah diproses oleh Agen Pembaca Log. Untuk memastikan bahwa semua transaksi telah diproses, lakukan langkah-langkah berikut untuk setiap database yang berisi publikasi transaksi:
- Pastikan bahwa Agen Pembaca Log berjalan untuk database. Secara default, agen berjalan terus menerus.
- Hentikan aktivitas pengguna pada tabel yang diterbitkan.
- Izinkan waktu bagi Agen Pembaca Log untuk menyalin transaksi ke database distribusi, lalu hentikan agen.
- Jalankan sp_replcmds untuk memverifikasi bahwa semua transaksi telah diproses. Hasil yang ditetapkan dari prosedur ini harus kosong.
- Jalankan sp_replflush untuk menutup koneksi dari sp_replcmds.
- Lakukan peningkatan server ke versi terbaru SQL Server.
- Mulai ulang Agen SQL Server dan Agen Pembaca Log jika tidak dimulai secara otomatis setelah peningkatan.
Jalankan Agen untuk Gabungkan Replikasi Setelah Peningkatan
Setelah peningkatan, jalankan Agen Rekam Jepret untuk setiap publikasi gabungan dan Gabungkan Agen untuk setiap langganan guna memperbarui metadata replikasi. Anda tidak perlu menerapkan rekam jepret baru, karena tidak perlu menginisialisasi ulang langganan. Metadata langganan diperbarui saat pertama kali Agen Penggabungan dijalankan setelah peningkatan. Ini berarti bahwa database langganan dapat tetap online dan aktif selama pemutakhiran Publisher.
Menggabungkan replikasi menyimpan publikasi dan metadata langganan dalam sejumlah tabel sistem dalam database publikasi dan langganan. Menjalankan metadata publikasi pembaruan Agen Rekam Jepret dan menjalankan metadata langganan pembaruan Agen Penggabungan. Hanya diperlukan untuk menghasilkan rekam jepret publikasi. Jika publikasi penggabungan menggunakan filter berparameter, setiap partisi juga memiliki rekam jepret. Tidak perlu memperbarui rekam jepret yang dipartisi ini.
Jalankan agen dari SQL Server Management Studio, Replication Monitor, atau dari baris perintah. Untuk informasi selengkapnya tentang menjalankan Agen Rekam Jepret, lihat artikel berikut ini:
- Membuat dan Menerapkan Rekam Jepret Awal
- Memulai dan Menghentikan Agen Replikasi (SQL Server Management Studio)
- Membuat dan Menerapkan Rekam Jepret Awal
- Konsep Executables Agen Replikasi
Untuk informasi selengkapnya tentang menjalankan Agen Penggabungan, lihat artikel berikut ini:
Setelah memutakhirkan SQL Server dalam topologi yang menggunakan replikasi penggabungan, ubah tingkat kompatibilitas publikasi publikasi apa pun jika Anda ingin menggunakan fitur baru.
Memutakhirkan ke Edisi Standar, Grup Kerja, atau Ekspres
Sebelum memutakhirkan dari satu edisi SQL Server ke edisi lainnya, verifikasi bahwa fungsionalitas yang saat ini Anda gunakan didukung dalam edisi yang Anda tingkatkan. Untuk informasi selengkapnya, lihat bagian tentang Replikasi di Edisi dan fitur SQL Server 2022 yang didukung.
Langkah-langkah untuk meningkatkan topologi replikasi
Langkah-langkah ini menguraikan urutan server dalam topologi replikasi harus ditingkatkan. Langkah yang sama berlaku apakah Anda menjalankan replikasi transaksional atau penggabungan. Namun, langkah-langkah ini tidak mencakup replikasi Peer-to-Peer, mengantre memperbarui langganan, atau segera memperbarui langganan.
Peningkatan di tempat
- Tingkatkan Distributor.
- Tingkatkan Penerbit dan Pelanggan. Ini dapat ditingkatkan dalam urutan apa pun.
Catatan
Untuk SQL 2008 dan 2008 R2, peningkatan penerbit dan pelanggan harus dilakukan pada saat yang sama untuk menyelaraskan dengan matriks topologi replikasi. Penerbit atau pelanggan SQL 2008 atau 2008R2 tidak dapat memiliki penerbit atau pelanggan SQL 2016 (atau lebih besar). Jika peningkatan pada saat yang sama tidak dimungkinkan, gunakan peningkatan menengah untuk meningkatkan instans SQL ke SQL 2014, lalu tingkatkan lagi ke SQL 2016 (atau lebih besar).
Peningkatan berdampingan
- Tingkatkan Distributor.
- Konfigurasi ulang Distribusi pada instans SQL Server baru.
- Mutakhirkan Publisher.
- Tingkatkan Pelanggan.
- Konfigurasi ulang semua pasangan Publisher-Subscriber, termasuk reinisialisasi Pelanggan.
Langkah-langkah untuk migrasi berdampingan dari Distributor ke Windows Server 2012 R2
Jika Anda berencana untuk meningkatkan instans SQL Server Anda ke SQL Server 2016 (atau lebih besar), dan OS Anda saat ini adalah Windows 2008 (atau 2008 R2), maka Anda harus melakukan peningkatan OS berdampingan ke Windows Server R2 atau yang lebih besar. Alasan peningkatan OS menengah ini adalah bahwa SQL Server 2016 tidak dapat diinstal pada Windows Server 2008/2008 R2, dan Windows Server 2008/20008 R2 tidak mengizinkan peningkatan di tempat langsung ke Windows Server 2016. Meskipun dimungkinkan untuk melakukan peningkatan di tempat dari Windows Server 2008/2008 R2 ke Windows Server 2012, dan kemudian ke Windows Server 2016, melakukannya umumnya tidak disarankan karena waktu henti dan kompleksitas tambahan mencegah jalur roll-back yang mudah. Peningkatan berdampingan adalah satu-satunya jalur peningkatan yang tersedia untuk instans SQL Server yang berpartisipasi dalam kluster failover. Langkah-langkah berikut dapat dilakukan pada instans SQL Server mandiri, atau satu dalam Instans Kluster Failover AlwaysOn (FCI).
- Siapkan instans SQL Server baru (mandiri, atau Kluster Failover AlwaysOn), edisi, dan versi sebagai distributor Anda di Windows Server 2012 R2/2016 dengan kluster Windows yang berbeda dan nama FCI SQL Server atau nama host mandiri. Anda harus menjaga struktur direktori tetap sama dengan distributor lama untuk memastikan bahwa agen replikasi dapat dieksekusi, folder replikasi, dan jalur file database ditemukan di jalur yang sama pada lingkungan baru. Ini akan mengurangi langkah-langkah pasca migrasi/peningkatan yang diperlukan.
- Pastikan replikasi Anda disinkronkan lalu matikan semua agen replikasi.
- Matikan instans Distributor SQL Server saat ini. Jika ini adalah instans mandiri, matikan server. Jika ini adalah FCI SQL, maka ambil seluruh peran SQL Server secara offline di manajer kluster, termasuk nama jaringan.
- Hapus entri objek komputer DNS dan AD untuk lingkungan lama (instans distributor saat ini).
- Ubah nama host server baru agar sesuai dengan server lama.
- Jika ini adalah SQL FCI, ganti nama SQL FCI baru dengan nama server virtual yang sama dengan instans lama.
- Salin file database dari instans sebelumnya menggunakan pengalihan SAN, salinan penyimpanan, atau salinan file.
- Bawa instans SQL Server baru secara online.
- Mulai ulang semua agen replikasi dan verifikasi apakah agen berhasil berjalan.
- Validasi jika replikasi berfungsi seperti yang diharapkan.
- Gunakan media penyiapan SQL Server untuk menjalankan peningkatan instans SQL Server Anda di tempat ke versi baru SQL Server.
Catatan
Untuk mengurangi waktu henti, kami sarankan Anda melakukan migrasi berdampingan dari distributor sebagai satu aktivitas dan peningkatan di tempat ke SQL Server 2016 sebagai aktivitas lain. Ini akan memungkinkan Anda untuk mengambil pendekatan bertahas, mengurangi risiko, dan meminimalkan waktu henti.
Sinkronisasi Web untuk Replikasi Penggabungan
Opsi Sinkronisasi web untuk replikasi penggabungan mengharuskan Pendengar Replikasi SQL Server (replisapi.dll) disalin ke direktori virtual di server Layanan Informasi Internet (IIS) yang digunakan untuk sinkronisasi. Saat Anda mengonfigurasi sinkronisasi Web, file disalin ke direktori virtual oleh Wizard Konfigurasi Sinkronisasi Web. Jika Anda meningkatkan komponen SQL Server yang diinstal di server IIS, Anda harus menyalin replisapi.dll secara manual dari direktori COM ke direktori virtual di server IIS. Untuk informasi selengkapnya tentang mengonfigurasi sinkronisasi Web, lihat Mengonfigurasi Sinkronisasi Web.
Memulihkan Database yang Direplikasi dari Versi Sebelumnya
Untuk memastikan pengaturan replikasi dipertahankan saat memulihkan cadangan database yang direplikasi dari versi sebelumnya: pulihkan ke server dan database dengan nama yang sama dengan server dan database tempat cadangan diambil.
Lihat Juga
Replikasi SQL Server
Tanya Jawab Umum Administrasi Replikasi
Kompatibilitas Mundur Replikasi
Peningkatan Versi dan Edisi yang Didukung
Tingkatkan SQL Server
Meningkatkan Topologi Replikasi ke SQL Server 2016
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk