Memindahkan Database ke Pusat Data Baru

Perusahaan saya memindahkan infrastruktur kami ke pusat data baru dan saya mencoba mencari cara terbaik untuk menjaga agar database di server baru tetap sinkron dengan database produksi saat ini sampai lingkungan baru siap untuk ditayangkan. Bukan sebagai DBA penuh waktu, saya melakukan riset dan dari apa yang saya baca, sepertinya setup replikasi transnasional akan paling sesuai dengan kebutuhan kita.

Beberapa perincian: DB produksi berukuran sekitar 90 GB dan menggunakan Robocopy, butuh waktu sekitar 9 jam untuk memindahkan salinannya ke salah satu server baru. Basis data produksi saat ini harus tetap online dan dapat diakses di seluruh proses migrasi. Ini dalam pemulihan sederhana, jadi mirroring basis data tidak tersedia.

Apakah replikasi transaksional merupakan metode terbaik untuk menjaga sinkronisasi database?

Rencana saya:

1. (Selesai) Transfer database saat ini dan log ke server baru dan lampirkan ke contoh baru SQL Server
2. Siapkan distributor pada mesin basis data pengembangan kami dan publikasikan ke sana dari basis data produksi
3. Buat pelanggan di mesin database baru yang akan menerima pembaruan yang didorong keluar dari distributor, sekali setiap malam

Ada dua hal di pikiran saya. Replikasi transaksional mensyaratkan bahwa setiap tabel yang diterbitkan memiliki kunci utama dan banyak tabel dalam database produksi tidak memiliki kunci primer yang ditentukan. Saya tidak berpikir ini akan menjadi masalah yang terlalu besar karena perhatian utama saya adalah hanya menyinkronkan database. Kami akan menguji berbagai aplikasi yang menggunakan database pada data yang lebih baru, tetapi saya ingin memastikan itu bukan masalah serius. Kedua, apakah saya perlu juga memindahkan DB sistem terkait dari instance asli, seperti master? Kami pindah ke pengaturan Direktori Aktif di lingkungan baru, jadi saya tidak peduli dengan pengguna dan semacamnya, tapi saya tidak yakin tentang perlunya DB sistem.

Dan secara umum, apakah saya memahami konsep-konsep ini dengan benar?

Situasi Anda saat ini:

• Basis data 90 GB yang ingin Anda pindahkan ke pusat data baru.
• Basis data dalam pemulihan sederhana.
• Anda berpikir untuk menggunakan T-Rep untuk menjaga data tetap sinkron.
• Ada banyak tabel dalam database yang tidak memiliki Kunci Utama - ini adalah persyaratan untuk setiap tabel untuk dipublikasikan.
• Anda sudah memiliki salinan yang disalin ke pusat data tujuan.

Saya melihat banyak kekurangan dalam pendekatan Anda:

• T-Rep tidak mudah diatur dibandingkan dengan teknologi lain. Jika ada perubahan skema maka diperlukan snapshot baru.
• Jika Anda menggunakan T-REP maka Anda harus membuat perubahan skema - tambahkan Primary Key ke tabel yang tidak ada.
• Melakukan perubahan apa pun pada basis data Anda yang ada, aplikasi Anda harus sepenuhnya diuji untuk menghindari perilaku yang tidak terduga.
• Jika database Anda memiliki banyak transaksi dan tergantung pada bandwidth jaringan antara 2 pusat data, akan ada latensi replikasi juga.

Berdasarkan pengalaman saya, di bawah ini adalah rekomendasi saya:

• Ubah database Anda menjadi pemulihan penuh. Ini bukan dampak besar dibandingkan dengan menciptakan PK.
• Kirimkan cadangan penuh dari basis data sumber - ambil cadangan dengan kompresi dan aktifkan inisialisasi file instan. Ini akan membantu Anda mengurangi waktu pemulihan di pusat data tujuan.
• Pulihkan basis data di server tujuan WITH NORECOVERY.
• Terapkan Logshipping dan inisialisasi dari cadangan.
• Logshipping mengirimkan log setiap 1 menit.
• Pada hari failover, ambil cadangan log ekor terakhir pada sumber dan kembalikan pada tujuan menggunakan WITH RECOVERY. Ini akan membawa database tujuan online.
• Setelah basis data tujuan online, Anda harus menyinkronkan pengguna .
• Anda harus mengubah web.config Anda untuk mengarahkannya ke server baru.

Anda tidak harus memindahkan basis data sistem apa pun. Pastikan Anda melakukan semua pekerjaan persiapan sebelum skrip keluar login, pekerjaan, paket ssis, dll dan membuatnya di server tujuan.

Lihat jawaban ini untuk langkah-langkah pemulihan pasca dan praktik terbaik lainnya .

Catatan: Anda dapat menerapkan Database mirroring (SYNC atau ASYNC tergantung pada edisi sql server yang Anda gunakan) juga, tetapi logshipping hanya sederhana untuk diterapkan dan jika Anda mengujinya, itu tidak akan mengecewakan Anda. Saya telah berhasil memindahkan basis data terabyte dari satu pusat data ke pusat data lainnya menggunakan teknik di atas dan berfungsi dengan baik.

Basis data produksi saat ini harus tetap online dan dapat diakses di seluruh proses migrasi.

Akan selalu ada downtime dan Anda harus menjadwalkannya. Bahkan jika Anda berinvestasi membayar sejumlah besar uang dalam solusi seperti pengelompokan, ketika Anda gagal, akan ada beberapa downtime. Anda harus menyeimbangkan berapa banyak perusahaan Anda dapat berinvestasi dalam memiliki downtime hampir nol vs apa yang tersedia dengan beberapa downtime yang dapat diterima.

Tidak punya kesempatan untuk menggunakan ini sendiri dan saya pikir ini masih dalam pratinjau, tetapi SQL Data Sync pada platform Azure bisa menjadi opsi potensial:

https://azure.microsoft.com/en-gb/documentation/articles/sql-database-get-started-sql-data-sync/

Ia bekerja dengan on-premise serta Azure SQL database dan sepertinya alat yang berguna untuk menjaga sinkronisasi database.