Apakah perubahan skema “memecah” Ketersediaan Grup atau mereka ditangani secara transparan?

Organisasi saya berencana untuk mengadopsi Grup Ketersediaan SQL Server 2012 dan saya mencoba memahami apa dampaknya (jika ada) pada proses peningkatan aplikasi kami.

Kami merilis pembaruan aplikasi pada siklus 8 minggu dan rilis apa pun dapat mencakup perubahan skema dan / atau migrasi data.

Apa yang saya coba pahami adalah apakah solusi HA / DR menangani perubahan skema secara transparan (kolom baru, indeks ditambahkan ke sekunder) atau diperlukan intervensi manual untuk membuat skema pada setiap contoh dan kemudian nyalakan Selalu Nyalakan kembali.

Sepotong migrasi data yang saya asumsikan ditangani secara transparan tetapi ingin mengonfirmasi hal itu juga.

Saya kira saya juga membuat asumsi selimut bahwa tidak ada perbedaan dalam perilaku ini berdasarkan pada konfigurasi Grup Ketersediaan yang mungkin salah juga. Tolong beritahu saya.

Pendeknya; Dalam setiap rilis aplikasi saya, saya dapat mengubah tabel yang sangat besar (10 hingga 100 juta catatan) dengan menambahkan kolom ke dalamnya. Beberapa kolom mungkin "baru bersih" sehingga dapat menggunakan fungsionalitas perubahan skema Enterprise Online. Kolom lain mungkin merupakan refactoring dari kolom yang ada (FullName akan dipecah menjadi FirstName dan LastName) dan migrasi akan dijalankan untuk setiap baris dalam tabel untuk mengisi kolom ini. Apakah ada dari perilaku ini yang membutuhkan DBA untuk mengubah konfigurasi AlwaysOn atau apakah ini ditangani secara default dan semua sekunder mendapatkan pernyataan DDL dan DML "gratis"?

Terima kasih atas kejelasan yang Anda berikan.

Perubahan skema dan perubahan data pada dasarnya sama. Ini berfungsi seperti mirroring tradisional hari ini: apa yang terjadi di log pada primer terjadi pada sekunder. Tidak semua yang terjadi di Vegas harus tetap di Vegas. :-)

Di mana Anda mungkin ingin berhati-hati, adalah ketika Anda memiliki aplikasi yang menunjuk ke utama, dan Anda memperbarui itu untuk mencocokkan perubahan skema. Tetapi Anda mungkin memiliki aplikasi berbeda yang menunjuk ke sekunder (mis. Dengan niat baca-saja), dan bahwa perubahan aplikasi harus disinkronkan juga.

Gotcha potensial lainnya adalah ketika database Anda yang merupakan bagian dari grup ketersediaan memiliki referensi ke objek di database lain (misalnya tabel pencarian statis yang disimpan dalam database utilitas). Jika itu berubah dan AG tergantung pada objek-objek itu, Anda harus mendorong perubahan itu secara manual. Hal yang sama berlaku untuk pekerjaan, login tingkat server, server terkait dll - segala sesuatu yang hidup di luar database dan / atau tidak dapat ditransaksikan. Pengguna basis data bisa menjadi yatim (selain pengguna yang terkandung). Saya tahu ini mungkin jelas tetapi ingin mendaftar secara eksplisit untuk kelengkapan.

Jawaban lebih lanjut di sini dari Remus, pengguna meminta kemungkinan menghapus pertanyaan pada replika sekunder dan memeriksa ulang status ukuran antrian dalam tabel: sys.dm_hadr_database_replica_states AlwaysOn DDL dan Schema Changes