Ini agak tergantung pada definisi Anda tentang "Zero Downtime" - Skenario pemulihan split-> upgrade-> fail-over-> dapat diselesaikan dengan mudah dengan mengatur replikasi antara dua server SQL Anda, yang juga memberi Anda manfaat redundansi .
Ini bekerja sangat mirip dengan apa yang Anda jelaskan di atas: Ketika Anda melakukan peningkatan, Anda membagi pasangan replikasi Anda & meningkatkan salah satu dari mereka (bersama dengan beberapa server aplikasi), alihkan beban ke perangkat mesin yang ditingkatkan, kemudian tingkatkan yang lain dan ulang -membangun replikasi. Peringatannya adalah Anda mungkin masih harus berhenti menerima perubahan (menyisipkan / memperbarui) selama jendela pemutakhiran (setidaknya sampai server yang ditingkatkan berjalan), jika tidak, Anda akan berakhir dengan skenario otak terbelah di mana Anda memiliki perubahan pada "tua"
Bergantung pada jenis perubahan skema yang Anda bicarakan & seberapa baik aplikasi Anda ditulis, Anda mungkin dapat melakukan beberapa perubahan tanpa downtime (menambahkan tabel / tampilan baru, menambahkan kolom, dll. Sering kali dapat dilakukan tanpa pemadaman listrik) , asalkan aplikasi Anda tidak panik ketika jumlah kolom dalam tabel berubah).
Saran saya kepada Anda adalah bahwa Anda bersikeras pada jendela perawatan yang memadai untuk semua perubahan / peningkatan, untuk memasukkan waktu pemadaman jika perlu. Sangat sedikit sistem yang harus benar-benar 24x7x365, dan jika Anda menemukan masalah yang tidak terduga, selalu lebih baik bagi sistem untuk offline dengan waktu yang cukup bagi Anda untuk memperbaiki masalah atau mengembalikan perubahan Anda daripada terburu-buru memperbaiki dengan pengguna yang marah bernapas di leher Anda karena mereka tidak mengharapkan pemadaman ...