Ngân hàng đề — Microsoft Administering Azure SQL

Đáp án

A — Transactional Replication

Vì sao đúng

Đây là cơ chế duy nhất trong danh sách nối được SQL Server tại chỗ với Azure SQL Database theo hướng nhân bản liên tục: thay đổi được đẩy sang gần như tức thì, nên lượng dữ liệu có thể mất khi sự cố xảy ra là rất nhỏ. Nó cũng cho phép CSDL đích vẫn phục vụ đọc trong lúc nhân bản.

Vì sao các phương án khác sai

• C. Log shipping — dựa vào việc khôi phục tệp nhật ký giao dịch, mà Azure SQL Database là dịch vụ PaaS không cho khôi phục log thủ công; nên cách này không dùng được với đích là SQL Database. Đây là bẫy chính.
• B. Nhân bản Azure Blob Storage — nhân bản tệp, không hiểu gì về giao dịch của CSDL.
• D. Nhân bản máy ảo Azure — áp cho máy ảo, không áp cho dịch vụ CSDL được quản lý.

Đáp án

A — Mô phỏng sự cố vào GIỜ CAO ĐIỂM.

Ghi nhớ về chất lượng câu hỏi

⚠ Câu này cùng dạng với #17443 ở lô trước — đều là câu PHỦ ĐỊNH về kiểm thử HA/DR.

Vì sao đúng

⚠ Vì sao không diễn tập vào giờ cao điểm: | Rủi ro | Nội dung | |---|---| | ⚠ Ảnh hưởng người dùng THẬT | ⚠ nếu diễn tập gặp sự cố ngoài dự kiến | | ⚠ Khó phân biệt vấn đề diễn tập với vấn đề thật | | | ⚠ Đội vận hành chịu áp lực kép | | | ⚠ Không có dư địa để xử lý nếu hỏng | |

⚠ Cách ĐÚNG
   ⚠ chọn giờ TẢI THẤP
   ⚠ thông báo trước cho mọi bên
   ⚠ có kế hoạch huỷ bỏ
   ⚠ có người trực sẵn
        ↓
⚠ Nếu muốn biết hệ thống chịu tải thế nào
   ⚠ dùng KIỂM THỬ TẢI riêng biệt

⚠ Chaos engineering trên production có tồn tại — ⚠ nhưng ⚠ chỉ với tổ chức đã rất trưởng thành, có công cụ giới hạn bán kính ảnh hưởng.

Vì sao các phương án khác đều hợp lệ

• B (khôi phục CSDL từ bản sao lưu gần nhất) — ⚠ thực hành BẮT BUỘC: ⚠ chứng minh bản sao lưu dùng được và đo thời gian khôi phục.

• C (đối chiếu dữ liệu khôi phục với production) — ⚠ bước kiểm chứng quan trọng: ⚠ khôi phục xong mà dữ liệu sai thì vô nghĩa.

• D (kiểm thử kết nối mạng) — ⚠ hợp lệ và cần thiết: ⚠ site DR thường thiếu đường mạng, firewall rule hoặc DNS.

Ghi nhớ

⚠ Kế hoạch diễn tập DR — bảng phải thuộc: | Yếu tố | Nội dung | |---|---| | ⚠ Thời điểm | ⚠ giờ tải THẤP, đã thông báo | | ⚠ Phạm vi | ⚠ xác định rõ cái gì được chạm vào | | ⚠ Tiêu chí thành công | ⚠ RTO, RPO cụ thể | | ⚠ Kế hoạch huỷ bỏ | ⚠ khi nào thì dừng diễn tập | | ⚠ Người trực | ⚠ có mặt trong suốt thời gian | | ⚠ Báo cáo sau diễn tập | ⚠ bài học và việc phải sửa |

Từ khoá nhận diện:

"cách nào KHÔNG nên" → ⚠ đọc kỹ, câu phủ định "gây rủi ro thật cho người dùng" → ⚠ không phải cách kiểm thử hợp lệ "đo RTO thật" → ⚠ diễn tập failover có kế hoạch

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lần diễn tập gần nhất là bao giờ | | | Có kế hoạch huỷ bỏ viết ra trước không | | | Bài học lần trước đã được sửa chưa | ⚠ hay chỉ ghi vào báo cáo rồi thôi |

Và giá trị thật của một cuộc diễn tập DR không nằm ở việc chứng minh hệ thống hoạt động: nó nằm ở danh sách những thứ không hoạt động mà trước đó không ai biết. Một cuộc diễn tập không phát hiện ra vấn đề gì thường là một cuộc diễn tập chưa đủ nghiêm túc.

Đáp án

B — Active geo-replication.

Vì sao đúng

⚠ Yêu cầu: dữ liệu vẫn sẵn sàng khi CẢ MỘT VÙNG Azure sập.

⚠ Vùng A: primary
        ↓ ⚠ nhân bản liên tục
⚠ Vùng B: secondary (đọc được)
        ↓ ⚠ vùng A sập
⚠ Nâng secondary ở vùng B lên primary
        ↓
⚠ Dịch vụ tiếp tục

⚠ Điểm quyết định: ⚠ secondary nằm ở VÙNG KHÁC — ⚠ sự cố toàn vùng không ảnh hưởng tới nó.

Vì sao các phương án khác sai

• A (Always On FCI trên Azure VM) — ⚠ FCI dùng LƯU TRỮ CHUNG: ⚠ vì vậy các node ⚠ phải ở gần nhau, thường trong một vùng; ⚠ không bảo vệ khỏi sập cả vùng.

• C (Azure Blob Storage với LRS) — ⚠ LRS chỉ nhân bản trong MỘT trung tâm dữ liệu: ⚠ mức nhân bản yếu nhất; ⚠ và ⚠ Blob không phải giải pháp cho CSDL SQL.

• D (SQL Server với sao lưu ra đĩa cục bộ) — ⚠ sao lưu nằm CÙNG chỗ với dữ liệu gốc: ⚠ vùng sập là mất cả hai; ⚠ vi phạm nguyên tắc cơ bản nhất của sao lưu.

Ghi nhớ

⚠ Phạm vi bảo vệ theo giải pháp — bảng phải thuộc: | Giải pháp | Chịu được | |---|---| | ⚠ FCI / AG trong một vùng | ⚠ hỏng MÁY CHỦ | | ⚠ Availability Zone | ⚠ hỏng một TRUNG TÂM DỮ LIỆU trong vùng | | ⚠ Active geo-replication | ⚠ hỏng cả VÙNG | | ⚠ Auto-failover group | ⚠ hỏng cả vùng, TỰ ĐỘNG | | ⚠ Sao lưu địa lý (geo-restore) | ⚠ hỏng cả vùng, nhưng RTO GIỜ |

Từ khoá nhận diện:

"cả vùng không khả dụng" → ⚠ geo-replication hoặc failover group "một zone hỏng" → ⚠ zone-redundant "một máy chủ hỏng" → ⚠ FCI, AG trong vùng "LRS" → ⚠ mức nhân bản yếu nhất, chỉ một trung tâm dữ liệu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bản sao lưu có nằm ở vùng khác không | | | Secondary ở vùng nào | ⚠ đủ xa để không cùng chịu sự cố | | Đã diễn tập chuyển vùng chưa | |

Và sai lầm cơ bản nhưng vẫn rất phổ biến trong thiết kế sao lưu: để bản sao lưu nằm cùng nơi với dữ liệu gốc. Nó bảo vệ được lỗi con người, nhưng hoàn toàn vô dụng trước sự cố hạ tầng.

Đáp án

D — Tăng tần suất nhịp tim (heartbeat) của cụm.

Ghi nhớ về chất lượng câu hỏi

⚠ Diễn đạt của khoá không khớp chính xác với cách cấu hình thật.

⚠ KHÔNG sửa khoá — ⚠ đây vẫn là phương án duy nhất nói về tham số heartbeat của cụm, ⚠ thứ trực tiếp quyết định khi nào một node bị coi là chết.

Vì sao đúng (về mặt ý tưởng)

⚠ Cơ chế heartbeat của Windows Server Failover Cluster:

⚠ Các node gửi nhịp tim cho nhau
        ↓
⚠ Bỏ lỡ N nhịp liên tiếp
        ↓
⚠ Cụm coi node đó là CHẾT
        ↓
⚠ GỠ khỏi cụm, có thể gây failover

Vì sao các phương án khác sai

• A (giảm lease timeout) — ⚠ NGƯỢC hướng: ⚠ giảm nghĩa là nhạy cảm hơn, ⚠ node càng dễ bị coi là chết.

• B (Database Level Health Detection) — ⚠ theo dõi sức khoẻ ở mức CSDL: ⚠ khiến failover nhạy hơn, ⚠ không giải quyết trục trặc mạng.

• C (điều chỉnh trọng số phiếu quorum) — ⚠ quyết định bên nào tiếp tục chạy khi cụm bị chia rẽ: ⚠ không ảnh hưởng việc node bị gỡ vì trục trặc mạng thoáng qua.

Ghi nhớ

⚠ Cụm trên đám mây — điều chỉnh cần thiết: | Điều chỉnh | Lý do | |---|---| | ⚠ Nới ngưỡng heartbeat | ⚠ mạng đám mây có biến động lớn hơn mạng LAN | | ⚠ Dùng Cloud Witness cho quorum | ⚠ không cần máy chủ thứ ba | | ⚠ Đặt node ở Availability Zone khác nhau | | | ⚠ Dùng Azure Load Balancer cho listener | | | ⚠ Cấu hình mặc định | ⚠ được thiết kế cho mạng LAN, quá nhạy cho đám mây |

Từ khoá nhận diện:

"node bị gỡ khỏi cụm vì trục trặc mạng" → ⚠ nới tham số heartbeat "cụm bị chia rẽ, bên nào chạy tiếp" → ⚠ quorum và trọng số phiếu "failover quá nhạy" → ⚠ xem lại health detection và heartbeat

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tham số heartbeat đang là bao nhiêu | | | Node bị gỡ có trùng lúc CPU cao không | | | Có dùng Cloud Witness cho quorum chưa | |

Và nguyên nhân bị bỏ qua nhiều nhất khi một node liên tục rớt khỏi cụm: không phải mạng, mà là chính máy chủ đó quá tải. Một VM chạy CPU 100% không kịp gửi nhịp tim, và cụm hoàn toàn có lý khi kết luận nó đã chết.

Đáp án

A và B — Cấu hình point-in-time restore với thời hạn 35 ngày, và cấu hình long-term retention lưu bản sao lưu hằng tuần ít nhất 6 tháng.

Vì sao đúng

⚠ Đề có HAI yêu cầu riêng biệt, cần HAI cơ chế: | Yêu cầu | Cơ chế | |---|---| | ⚠ Khôi phục về bất kỳ thời điểm nào trong 35 ngày | ⚠ PITR với retention = 35 ngày | | ⚠ Khôi phục từ bản sao lưu ít nhất 6 tháng tuổi | ⚠ Long-term retention (LTR) |

⚠ Short-term (PITR)
   ⚠ 1-35 ngày
   ⚠ khôi phục tới TỪNG GIÂY
        ↓ ⚠ hết 35 ngày
⚠ Long-term retention
   ⚠ bản full theo tuần/tháng/năm
   ⚠ tới 10 NĂM
   ⚠ chỉ khôi phục về ĐIỂM SAO LƯU

⚠ Hai cơ chế TÁCH BIỆT, phải cấu hình cả hai.

Vì sao các phương án khác sai

• C (dùng sao lưu tự động với thiết lập MẶC ĐỊNH) — ⚠ mặc định chỉ 7 ngày: ⚠ không đáp ứng cả 35 ngày lẫn 6 tháng.

• D (bật geo-redundant backup storage) — ⚠ quyết định NƠI LƯU bản sao lưu, không phải THỜI GIAN GIỮ: ⚠ GRS cho khôi phục ở vùng khác, ⚠ nhưng không kéo dài thời hạn.

Ghi nhớ

⚠ Hai tầng sao lưu của Azure SQL — bảng phải thuộc: | Tầng | Thời hạn | Khôi phục về | |---|---|---| | ⚠ Short-term (PITR) | ⚠ 1-35 ngày | ⚠ BẤT KỲ giây nào | | ⚠ Long-term retention | ⚠ tới 10 năm | ⚠ chỉ ĐIỂM có bản sao lưu |

Từ khoá nhận diện:

"bất kỳ thời điểm nào trong N ngày" → ⚠ PITR, N ≤ 35 "sao lưu vài tháng hoặc vài năm tuổi" → ⚠ Long-term retention "khôi phục ở vùng khác" → ⚠ geo-restore, cần backup storage GRS "mặc định" → ⚠ 7 ngày — thường KHÔNG đủ cho đề bài

Ba việc kiểm chứng: | Việc | Cách | |---|---| | PITR retention đặt bao nhiêu ngày | ⚠ mặc định 7, thường phải nâng | | LTR đã cấu hình chưa | ⚠ KHÔNG bật mặc định | | Đã thử khôi phục từ bản LTR chưa | |

Và cấu hình bị bỏ quên nhiều nhất trong Azure SQL Database: long-term retention không hề bật sẵn. Nhiều tổ chức tin rằng mình đang giữ sao lưu nhiều năm, cho tới ngày kiểm toán viên hỏi bản sao lưu của quý trước.

Đáp án

A — sys.dm_tran_locks.

Ghi nhớ về chất lượng câu hỏi

⚠ Câu này và #17460 trong CÙNG LÔ có khoá khác nhau cho chủ đề rất gần.

⚠ Thực tế: ⚠ dân DBA thường JOIN cả hai để có bức tranh đầy đủ.

Vì sao đúng

⚠ sys.dm_tran_locks cho biết mọi yêu cầu khoá: | Cột quan trọng | Nội dung | |---|---| | ⚠ request_session_id | ⚠ phiên nào yêu cầu khoá | | ⚠ request_mode | ⚠ loại khoá: S, X, U, IS, IX | | ⚠ request_status | ⚠ GRANT (đã có) hay WAIT (đang chờ) | | ⚠ resource_type | ⚠ OBJECT, PAGE, KEY, RID | | ⚠ resource_description | ⚠ tài nguyên cụ thể |

⚠ request_status = 'WAIT'
        ↓
⚠ Đây chính là phiên ĐANG CHỜ KHOÁ
        ↓
⚠ Tìm phiên có 'GRANT' trên CÙNG tài nguyên
        ↓
⚠ Đó là phiên đang CHẶN

Vì sao các phương án khác sai

• C (sys.dm_os_wait_stats) — ⚠ thống kê chờ TÍCH LUỸ toàn hệ thống: ⚠ cho biết loại chờ nào nhiều nhất, ⚠ không cho biết PHIÊN nào đang chờ ngay lúc này.

• B (sys.dm_exec_sessions) — ⚠ thông tin phiên: ⚠ ai đăng nhập, từ ứng dụng nào; ⚠ không có thông tin khoá.

• D (sys.dm_db_index_usage_stats) — ⚠ thống kê sử dụng index: ⚠ hoàn toàn khác chủ đề.

Ghi nhớ

⚠ Bộ DMV cho blocking — dùng phối hợp: | DMV | Góc nhìn | |---|---| | ⚠ sys.dm_tran_locks | ⚠ KHOÁ: ai giữ, ai chờ, trên tài nguyên nào | | ⚠ sys.dm_os_waiting_tasks | ⚠ CHỜ: ai chờ ai, chuỗi chặn | | ⚠ sys.dm_exec_requests | ⚠ REQUEST đang chạy, có blocking_session_id | | ⚠ sys.dm_exec_sessions | ⚠ AI: người dùng, ứng dụng, máy | | ⚠ Truy vấn chẩn đoán tốt | ⚠ JOIN cả bốn lại |

Từ khoá nhận diện:

"phiên đang chờ KHOÁ" → ⚠ sys.dm_tran_locks với request_status = 'WAIT' "head blocker, chuỗi chặn" → ⚠ sys.dm_os_waiting_tasks "loại chờ nào nhiều nhất toàn hệ thống" → ⚠ sys.dm_os_wait_stats "deadlock đã xảy ra" → ⚠ Extended Events system_health

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có phiên nào giữ khoá quá lâu không | | | Có leo thang khoá lên mức bảng không | | | READ COMMITTED SNAPSHOT đã bật chưa | ⚠ giảm hẳn blocking giữa đọc và ghi |

Và điều làm việc chẩn đoán blocking khó hơn nó cần phải khó: các DMV mỗi cái chỉ cho một mảnh của bức tranh. Một truy vấn chẩn đoán viết sẵn ghép chúng lại đáng giá hơn nhiều so với việc nhớ tên từng DMV.

Đáp án

C — Point in time restore.

Ghi nhớ về chất lượng câu hỏi

⚠ Câu này GẦN TRÙNG với #17401 ở lô trước.

Vì sao đúng

⚠ Kịch bản kinh điển của PITR: lỗi con người.

⚠ 14:32 — ai đó chạy nhầm
   UPDATE khong co WHERE
        ↓
⚠ 14:45 — phát hiện ra
        ↓
⚠ Khôi phục về 14:31
        ↓
⚠ Ra một CSDL MỚI
        ↓
⚠ Đối chiếu, lấy lại dữ liệu đúng

⚠ Không cần dừng hệ thống: ⚠ khôi phục ra CSDL mới, ⚠ rồi mới quyết định dùng thế nào.

Vì sao các phương án khác sai

• B (differential backup) — ⚠ là một THÀNH PHẦN của PITR, không phải tính năng: ⚠ riêng nó chỉ khôi phục về thời điểm bản sao lưu đó.

• D (Always On availability group) — ⚠ giải pháp HA: ⚠ replica cũng đã đồng bộ luôn lỗi đó; ⚠ hoàn toàn không giúp gì với lỗi logic.

• A (log shipping) — ⚠ giải pháp nhân bản, không phải khôi phục theo thời điểm: ⚠ tuy nhiên ⚠ nếu secondary có độ trễ cấu hình sẵn thì có thể lấy lại dữ liệu — nhưng đó là ca dùng ngoại lệ.

Ghi nhớ

⚠ HA/DR KHÔNG bảo vệ khỏi lỗi logic — bảng phải thuộc: | Loại sự cố | Giải pháp | |---|---| | ⚠ Hỏng phần cứng, sập máy chủ | ⚠ HA: FCI, AG, zone-redundant | | ⚠ Sập cả vùng | ⚠ DR: geo-replication, failover group | | ⚠ LỖI CON NGƯỜI, hỏng dữ liệu logic | ⚠ SAO LƯU và PITR | | ⚠ Điểm mấu chốt | ⚠ nhân bản sao chép TRUNG THỰC cả lỗi của bạn |

Từ khoá nhận diện:

"sửa nhầm dữ liệu, xoá nhầm" → ⚠ PITR "máy chủ hỏng" → ⚠ HA "cả vùng sập" → ⚠ DR "CSDL bị xoá" → ⚠ restore deleted database

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thời hạn PITR có đủ để phát hiện lỗi không | ⚠ lỗi có thể mất vài ngày mới lộ | | Có ai được ghi trực tiếp lên production không | | | Bảng quan trọng có temporal versioning không | |

Và câu hỏi nên đặt cho mọi kiến trúc HA/DR được thiết kế đẹp đẽ: nếu ai đó chạy một lệnh DELETE nhầm, kiến trúc này cứu được không?. Câu trả lời gần như luôn là không — và đó chính là lý do sao lưu không bao giờ bị thay thế.

Đáp án

A — Dynamic Management Views (DMV).

Vì sao đúng

⚠ SQL Server có bộ DMV riêng cho Always On: | DMV | Cho biết | |---|---| | ⚠ sys.dm_hadr_availability_replica_states | ⚠ trạng thái từng replica: primary/secondary, đồng bộ hay không | | ⚠ sys.dm_hadr_database_replica_states | ⚠ độ trễ gửi/nhận log, hàng đợi log | | ⚠ sys.dm_hadr_availability_group_states | ⚠ trạng thái tổng thể của nhóm | | ⚠ sys.dm_hadr_cluster | ⚠ thông tin WSFC | | ⚠ sys.availability_groups | ⚠ cấu hình nhóm |

⚠ log_send_queue_size
   ⚠ log chờ GỬI sang secondary
⚠ redo_queue_size
   ⚠ log đã tới nhưng chưa ÁP DỤNG
        ↓
⚠ Hai con số này quyết định
   ⚠ RPO thực tế (send queue)
   ⚠ RTO thực tế (redo queue)

Vì sao các phương án khác sai

• B (Azure Metrics Explorer) — ⚠ cho chỉ số của TÀI NGUYÊN AZURE: ⚠ CPU và đĩa của VM; ⚠ không biết gì về trạng thái bên trong Always On.

• D (Azure Automation runbook) — ⚠ công cụ TỰ ĐỘNG HOÁ: ⚠ chạy được script kiểm tra, ⚠ nhưng bản thân nó không cung cấp thông tin.

• C (log của Azure Blob Storage) — ⚠ hoàn toàn không liên quan.

Ghi nhớ

⚠ Giám sát Always On — bảng phải thuộc: | Cần biết | Nguồn | |---|---| | ⚠ Trạng thái replica, độ trễ đồng bộ | ⚠ DMV dm_hadr_* | | ⚠ Sự kiện failover | ⚠ SQL Error Log, Cluster Log | | ⚠ Sức khoẻ VM và mạng | ⚠ Azure Monitor | | ⚠ Dashboard trực quan | ⚠ AlwaysOn Dashboard trong SSMS | | ⚠ Cảnh báo tự động | ⚠ SQL Agent alert hoặc Azure Monitor + Log Analytics |

Từ khoá nhận diện:

"trạng thái Always On, độ trễ đồng bộ" → ⚠ DMV dm_hadr_* "CPU, bộ nhớ của VM" → ⚠ Azure Monitor "node bị gỡ khỏi cụm" → ⚠ Cluster Log "deadlock" → ⚠ Extended Events

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hai hàng đợi log có tăng dần không | | | Chế độ đồng bộ có khớp với cam kết RPO không | | | Có cảnh báo khi trạng thái đồng bộ thay đổi không | |

Và con số quyết định RPO thật của một cấu hình Always On bất đồng bộ: log_send_queue_size. Đó chính xác là lượng dữ liệu sẽ mất nếu primary chết ngay lúc này.

Đáp án

D — Azure Backup.

Ghi nhớ về chất lượng câu hỏi

⚠ Với Azure SQL Database, lưu trữ dài hạn là tính năng TÍCH HỢP SẴN, không cần Azure Backup.

⚠ KHÔNG sửa khoá — ⚠ trong bốn phương án, ⚠ Azure Backup là dịch vụ sao lưu duy nhất được đưa ra.

⚠ Cách nhớ an toàn: ⚠ PaaS → LTR tích hợp; ⚠ IaaS (SQL trên VM) → Azure Backup.

Vì sao đúng (theo bối cảnh đề)

⚠ Azure Backup là dịch vụ sao lưu tập trung của Azure: | Năng lực | Nội dung | |---|---| | ⚠ Sao lưu SQL Server trên Azure VM | ⚠ full, differential, log | | ⚠ Chính sách lưu trữ dài hạn | ⚠ hằng ngày, tuần, tháng, năm | | ⚠ Quản tập trung qua Recovery Services Vault | | | ⚠ Soft delete và immutable vault | ⚠ chống xoá nhầm và mã tống tiền | | ⚠ Giám sát và cảnh báo tích hợp | |

Vì sao các phương án khác sai

• B (Blob Storage lifecycle management) — ⚠ quản vòng đời của OBJECT trong Storage: ⚠ chuyển lớp, xoá theo tuổi; ⚠ không tạo ra bản sao lưu CSDL.

• A (Azure Site Recovery) — ⚠ khôi phục thảm hoạ cho MÁY ẢO: ⚠ nhân bản cả máy, ⚠ không phải sao lưu CSDL theo thời điểm.

• C (SQL Data Sync) — ⚠ đồng bộ dữ liệu hai chiều: ⚠ KHÔNG phải sao lưu — ⚠ xoá nhầm sẽ lan đi mọi nơi.

Ghi nhớ

⚠ Ba dịch vụ dễ lẫn — bảng phải thuộc: | Dịch vụ | Bảo vệ gì | |---|---| | ⚠ Azure Backup | ⚠ SAO LƯU: khôi phục về thời điểm quá khứ | | ⚠ Azure Site Recovery | ⚠ DR: nhân bản máy ảo sang vùng khác | | ⚠ SQL Data Sync | ⚠ ĐỒNG BỘ: phân phối dữ liệu, KHÔNG bảo vệ |

Từ khoá nhận diện:

"lưu trữ sao lưu nhiều năm — Azure SQL Database" → ⚠ Long-term retention (LTR) "sao lưu SQL Server trên VM" → ⚠ Azure Backup "nhân bản máy ảo sang vùng khác" → ⚠ Site Recovery "đồng bộ hai chiều" → ⚠ Data Sync — KHÔNG phải sao lưu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đang dùng PaaS hay IaaS | ⚠ quyết định LTR hay Azure Backup | | Bản sao lưu có bị xoá được không | | | Đã thử khôi phục từ bản dài hạn chưa | |

Và thay đổi lớn trong tư duy sao lưu vài năm gần đây: bản sao lưu giờ là mục tiêu tấn công đầu tiên. Mã tống tiền hiện đại tìm và xoá sao lưu trước khi mã hoá dữ liệu — nên tính bất biến của bản lưu quan trọng không kém việc có bản lưu.

Đáp án

B — Auto-failover groups.

Vì sao đúng

⚠ Thời gian chuyển đổi gồm nhiều phần, tự động hoá cắt được phần lớn nhất: | Thành phần RTO | Có auto-failover group | |---|---| | ⚠ Phát hiện sự cố | ⚠ tự động | | ⚠ Quyết định chuyển | ⚠ tự động | | ⚠ Nâng secondary lên primary | ⚠ tự động | | ⚠ Ứng dụng đổi kết nối | ⚠ KHÔNG cần — endpoint cố định |

⚠ Không có failover group
   ⚠ phát hiện → ⚠ gọi người
   → ⚠ quyết định → ⚠ thao tác tay
   → ⚠ đổi chuỗi kết nối
        ↓ ⚠ RTO tính bằng CHỤC PHÚT

⚠ Có failover group
   ⚠ mọi bước TỰ ĐỘNG
        ↓ ⚠ RTO tính bằng PHÚT

Vì sao các phương án khác sai

• A (log shipping) — ⚠ kỹ thuật cũ, chuyển đổi HOÀN TOÀN THỦ CÔNG: ⚠ làm RTO tệ hơn, không tốt hơn.

• C (Stretch Database) — ⚠ chuyển dữ liệu LẠNH lên Azure để tiết kiệm chi phí: ⚠ không liên quan HA/DR; ⚠ ⚠ và tính năng này đã bị khai tử.

• D (sao lưu ra Azure Blob) — ⚠ là sao lưu: ⚠ khôi phục từ sao lưu có RTO hàng giờ.

Ghi nhớ

⚠ Rút ngắn RTO — bảng phải thuộc: | Cách | Tác động | |---|---| | ⚠ Secondary CHẠY SẴN | ⚠ bỏ thời gian khôi phục | | ⚠ Tự động phát hiện và chuyển | ⚠ bỏ thời gian gọi người | | ⚠ Endpoint cố định | ⚠ bỏ thời gian đổi cấu hình ứng dụng | | ⚠ Ứng dụng tự kết nối lại | ⚠ bỏ thời gian khởi động lại dịch vụ | | ⚠ Bốn thứ này cộng lại | ⚠ là toàn bộ RTO |

Từ khoá nhận diện:

"giảm thời gian chuyển đổi" → ⚠ auto-failover group "chuyển thủ công" → ⚠ active geo-replication, log shipping "Stretch Database" → ⚠ tiết kiệm chi phí lưu trữ, ĐÃ KHAI TỬ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chuỗi kết nối có dùng endpoint của failover group không | | | Ứng dụng có logic thử lại không | | | Đã đo RTO đầu-cuối chưa | ⚠ từ lúc sự cố tới lúc người dùng dùng lại được |

Và con số RTO duy nhất thật sự quan trọng: thời gian từ lúc người dùng gặp lỗi tới lúc họ dùng lại được bình thường. Cơ sở dữ liệu chuyển xong trong hai phút không có nghĩa gì nếu ứng dụng mất thêm hai mươi phút để ổn định.