Các thay đổi lược đồ có thể phá vỡ các nhóm sẵn có của mạng hay không hoặc chúng được xử lý trong suốt?

Tổ chức của tôi đang có kế hoạch áp dụng Nhóm sẵn sàng SQL Server 2012 và tôi đang cố gắng hiểu tác động (nếu có) của nó đối với quá trình nâng cấp ứng dụng của chúng tôi.

Chúng tôi phát hành các bản cập nhật ứng dụng theo chu kỳ 8 tuần và mọi bản phát hành có thể bao gồm các thay đổi lược đồ và / hoặc di chuyển dữ liệu.

Điều tôi đang cố gắng hiểu là liệu giải pháp HA / DR có xử lý các thay đổi lược đồ một cách trong suốt hay không (các cột, chỉ mục mới được thêm vào phụ) hoặc là can thiệp thủ công để tạo lược đồ trên mỗi phiên bản và sau đó bật Luôn bật lại.

Phần di chuyển dữ liệu tôi giả sử được xử lý trong suốt nhưng cũng muốn xác nhận điều đó.

Tôi đoán tôi cũng đang đưa ra một giả định về chăn rằng không có sự khác biệt nào trong các hành vi này dựa trên cấu hình Nhóm sẵn có cũng có thể sai. Làm ơn cho tôi biết.

Tóm lại; Trong bất kỳ bản phát hành nào của ứng dụng của tôi, tôi có thể thay đổi một bảng rất lớn (10 đến 100 triệu bản ghi) bằng cách thêm các cột vào nó. Một số cột có thể là "mạng mới" để chúng có thể sử dụng chức năng thay đổi lược đồ Enterprise Online. Các cột khác có thể là cấu trúc lại một cột hiện có (FullName được chia thành FirstName và LastName) và di chuyển sẽ được chạy cho mỗi hàng trong bảng để điền vào các trường này. Có bất kỳ hành vi nào trong số những hành vi này yêu cầu các DBA thay đổi cấu hình Luôn luôn hay điều này được xử lý theo mặc định và tất cả các thư mục thứ hai đều nhận được các câu lệnh DDL và DML "miễn phí"?

Cảm ơn cho bất kỳ sự rõ ràng bạn có thể cung cấp.

Thay đổi lược đồ và thay đổi dữ liệu về cơ bản là giống nhau. Nó hoạt động giống như phản chiếu truyền thống ngày nay: những gì xảy ra trong nhật ký trên chính xảy ra trên thứ cấp. Không phải mọi thứ xảy ra ở Vegas đều phải ở lại Vegas. :-)

Nơi bạn có thể muốn cẩn thận, là khi bạn có một ứng dụng trỏ đến chính và bạn cập nhật nó để phù hợp với các thay đổi lược đồ. Nhưng bạn có thể có một ứng dụng khác trỏ đến ứng dụng phụ (ví dụ với mục đích chỉ đọc) và thay đổi ứng dụng đó cũng sẽ phải được đồng bộ hóa.

Một Gotcha tiềm năng khác là khi cơ sở dữ liệu của bạn là một phần của nhóm khả dụng có tham chiếu đến các đối tượng trong cơ sở dữ liệu khác (ví dụ: bảng tra cứu tĩnh được lưu trữ trong cơ sở dữ liệu tiện ích). Nếu những thay đổi đó và AG phụ thuộc vào các đối tượng đó, bạn sẽ phải đẩy những thay đổi đó bằng tay. Điều này cũng đúng với các công việc, thông tin đăng nhập cấp máy chủ, máy chủ được liên kết, v.v. - bất cứ điều gì nằm ngoài cơ sở dữ liệu và / hoặc không thể giao dịch. Người dùng cơ sở dữ liệu có thể bị mồ côi (người dùng bị gạt sang một bên). Tôi biết điều này có thể rõ ràng nhưng muốn liệt kê nó một cách rõ ràng cho đầy đủ.

Thêm câu trả lời ở đây từ Remus, người dùng đang yêu cầu có thể xóa các truy vấn trên bản sao thứ cấp và kiểm tra lại trạng thái kích thước hàng đợi trong bảng: sys.dm_hadr_database_Vplica_states Luôn luôn thay đổi DDL và Schema