Trước đây, chúng tôi đã đăng một blog thảo luận về Đạt được Dự phòng &Dự phòng MySQL trên Google Cloud Platform (GCP) và trong blog này, chúng ta sẽ xem xét cách đối thủ của Amazon, Dịch vụ Cơ sở dữ liệu Quan hệ của Amazon (RDS), xử lý chuyển đổi dự phòng. Chúng tôi cũng sẽ xem xét cách bạn có thể thực hiện sao lưu dự phòng của nút chính cũ của mình, đưa nó trở lại thứ tự ban đầu với tư cách là nút chính.
Khi so sánh các đám mây công cộng khổng lồ về công nghệ hỗ trợ các dịch vụ cơ sở dữ liệu quan hệ được quản lý, Amazon là công ty duy nhất cung cấp tùy chọn thay thế (cùng với MySQL / MariaDB, PostgreSQL, Oracle và SQL Server) để cung cấp loại quản lý cơ sở dữ liệu của riêng nó được gọi là Amazon Aurora. Đối với những người không quen thuộc với Aurora, nó là một công cụ cơ sở dữ liệu quan hệ được quản lý hoàn toàn tương thích với MySQL và PostgreSQL. Aurora là một phần của dịch vụ cơ sở dữ liệu được quản lý Amazon RDS, một dịch vụ web giúp dễ dàng thiết lập, vận hành và mở rộng quy mô cơ sở dữ liệu quan hệ trên đám mây.
Tại sao bạn cần chuyển đổi dự phòng hoặc sao lưu dự phòng?
Việc thiết kế một hệ thống lớn có khả năng chịu lỗi, có tính khả dụng cao, không có Lỗi duy nhất (SPOF) yêu cầu thử nghiệm thích hợp để xác định xem nó sẽ phản ứng như thế nào khi có sự cố.
Nếu bạn lo lắng về cách hệ thống của bạn sẽ hoạt động khi phản hồi với Phát hiện lỗi, Cách ly và Phục hồi (FDIR) của hệ thống, thì chuyển đổi dự phòng và dự phòng phải có tầm quan trọng cao.
Chuyển đổi dự phòng cơ sở dữ liệu trong Amazon RDS
Chuyển đổi dự phòng xảy ra tự động (vì chuyển đổi dự phòng thủ công được gọi là chuyển đổi dự phòng). Như đã thảo luận trong một blog trước, nhu cầu chuyển đổi dự phòng xảy ra khi cơ sở dữ liệu tổng thể hiện tại của bạn gặp sự cố mạng hoặc kết thúc bất thường của hệ thống lưu trữ. Dự phòng chuyển nó sang trạng thái dự phòng ổn định hoặc sang máy chủ máy tính dự phòng, hệ thống, thành phần phần cứng hoặc mạng.
Trong Amazon RDS, bạn không cần phải thực hiện việc này, cũng như không phải tự mình giám sát vì RDS là một dịch vụ cơ sở dữ liệu được quản lý (nghĩa là Amazon xử lý công việc cho bạn). Dịch vụ này quản lý những thứ như sự cố phần cứng, sao lưu và phục hồi, cập nhật phần mềm, nâng cấp bộ nhớ và thậm chí vá lỗi phần mềm. Chúng ta sẽ nói về điều đó sau trong blog này.
Dự phòng cơ sở dữ liệu trong Amazon RDS
Trong blog trước, chúng tôi cũng đã trình bày lý do tại sao bạn cần khôi phục dự phòng. Trong một môi trường nhân bản điển hình, bản chính phải đủ mạnh để mang tải rất lớn, đặc biệt khi yêu cầu khối lượng công việc cao. Thiết lập chính của bạn yêu cầu các thông số kỹ thuật phần cứng phù hợp để đảm bảo nó có thể xử lý ghi, tạo các sự kiện sao chép, xử lý các lần đọc quan trọng, v.v. một cách ổn định. Khi cần chuyển đổi dự phòng trong quá trình khôi phục sau thảm họa (hoặc để bảo trì), không có gì lạ khi khi quảng cáo một bản chính mới, bạn có thể sử dụng phần cứng kém hơn. Tình trạng này có thể tạm thời ổn, nhưng về lâu dài, bản gốc được chỉ định phải được đưa trở lại để dẫn đầu bản sao sau khi nó được coi là khỏe mạnh (hoặc bảo trì xong).
Trái ngược với chuyển đổi dự phòng, các hoạt động khôi phục dự phòng thường xảy ra trong môi trường được kiểm soát bằng cách sử dụng chuyển đổi. Nó hiếm khi được thực hiện khi ở chế độ hoảng sợ. Cách tiếp cận này cung cấp cho các kỹ sư của bạn đủ thời gian để lập kế hoạch cẩn thận và diễn tập bài tập để đảm bảo quá trình chuyển đổi diễn ra suôn sẻ. Mục tiêu chính của nó là chỉ cần đưa bản gốc tốt, cũ trở lại trạng thái mới nhất và khôi phục thiết lập sao chép về cấu trúc liên kết ban đầu của nó. Vì chúng tôi đang xử lý Amazon RDS, nên bạn thực sự không cần quá lo lắng về những loại vấn đề này vì đây là một dịch vụ được quản lý với hầu hết các công việc do Amazon xử lý.
Amazon RDS xử lý dự phòng cơ sở dữ liệu như thế nào?
Khi triển khai các nút Amazon RDS, bạn có thể thiết lập cụm cơ sở dữ liệu của mình với Vùng đa khả dụng (AZ) hoặc với Vùng sẵn sàng duy nhất. Hãy kiểm tra từng người trong số họ về cách xử lý chuyển đổi dự phòng.
Thiết lập Nhiều AZ là gì?
Khi thảm họa hoặc thảm họa xảy ra, chẳng hạn như sự cố mất điện ngoài kế hoạch hoặc thiên tai trong đó các phiên bản cơ sở dữ liệu của bạn bị ảnh hưởng, Amazon RDS sẽ tự động chuyển sang bản sao dự phòng trong Vùng khả dụng khác. AZ này thường nằm trong một nhánh khác của trung tâm dữ liệu, thường cách xa vùng khả dụng hiện tại nơi các phiên bản được đặt. AZ này là những phương tiện hiện đại, rất sẵn có để bảo vệ các cá thể cơ sở dữ liệu của bạn. Thời gian chuyển đổi dự phòng phụ thuộc vào việc hoàn thành thiết lập, thường dựa trên kích thước và hoạt động của cơ sở dữ liệu cũng như các điều kiện khác có tại thời điểm cá thể DB chính không khả dụng.
Thời gian chuyển đổi dự phòng thường là 60-120 giây. Tuy nhiên, chúng có thể lâu hơn vì các giao dịch lớn hoặc quá trình khôi phục kéo dài có thể làm tăng thời gian chuyển đổi dự phòng. Khi quá trình chuyển đổi dự phòng hoàn tất, cũng có thể mất thêm thời gian để Bảng điều khiển RDS (Giao diện người dùng) phản ánh Vùng khả dụng mới.
Thiết lập Single-AZ là gì?
Thiết lập đơn AZ chỉ nên được sử dụng cho các phiên bản cơ sở dữ liệu của bạn nếu RTO (Mục tiêu thời gian khôi phục) và RPO (Mục tiêu điểm khôi phục) của bạn đủ cao để cho phép. Có những rủi ro liên quan đến việc sử dụng Single-AZ, chẳng hạn như thời gian ngừng hoạt động lớn có thể làm gián đoạn hoạt động kinh doanh.
Các Trường hợp Lỗi RDS Phổ biến
Lượng thời gian ngừng hoạt động phụ thuộc vào loại lỗi. Hãy xem xét những điều này là gì và cách xử lý quá trình khôi phục phiên bản.
Lỗi phiên bản có thể khôi phục
Lỗi phiên bản Amazon RDS xảy ra khi phiên bản EC2 bên dưới bị lỗi. Khi sự kiện xảy ra, AWS sẽ kích hoạt thông báo sự kiện và gửi cảnh báo cho bạn bằng cách sử dụng Thông báo sự kiện Amazon RDS. Hệ thống này sử dụng AWS Simple Notification Service (SNS) làm bộ xử lý cảnh báo.
RDS sẽ tự động thử khởi chạy một phiên bản mới trong cùng Vùng khả dụng, đính kèm ổ đĩa EBS và thử khôi phục. Trong trường hợp này, RTO thường dưới 30 phút. RPO bằng 0 vì khối lượng EBS có thể được phục hồi. Ổ đĩa EBS nằm trong một Vùng khả dụng duy nhất và kiểu khôi phục này xảy ra trong cùng Vùng khả dụng như phiên bản gốc.
Lỗi phiên bản không thể khôi phục hoặc Lỗi âm lượng EBS
Để khôi phục phiên bản RDS không thành công (hoặc nếu khối lượng EBS bên dưới bị lỗi mất dữ liệu) thì cần khôi phục điểm trong thời gian (PITR). PITR không được Amazon xử lý tự động, vì vậy bạn cần tạo một tập lệnh để tự động hóa nó (sử dụng AWS Lambda) hoặc thực hiện thủ công.
Thời gian RTO yêu cầu khởi động phiên bản Amazon RDS mới, phiên bản này sẽ có tên DNS mới sau khi được tạo và sau đó áp dụng tất cả các thay đổi kể từ lần sao lưu cuối cùng.
RPO thường là 5 phút, nhưng bạn có thể tìm thấy nó bằng cách gọi RDS:description-db-instances:LatestRestworthyTime. Thời gian có thể thay đổi từ 10 phút đến hàng giờ tùy thuộc vào số lượng bản ghi cần được áp dụng. Nó chỉ có thể được xác định bằng cách thử nghiệm vì nó phụ thuộc vào kích thước của cơ sở dữ liệu, số lượng thay đổi được thực hiện kể từ lần sao lưu cuối cùng và mức khối lượng công việc trên cơ sở dữ liệu. Vì các bản sao lưu và nhật ký giao dịch được lưu trữ trong Amazon S3, quá trình khôi phục này có thể xảy ra ở bất kỳ Vùng sẵn sàng nào được hỗ trợ trong Vùng.
Khi phiên bản mới được tạo, bạn sẽ cần cập nhật tên điểm cuối của khách hàng của mình. Bạn cũng có tùy chọn đổi tên nó thành tên điểm cuối của phiên bản DB cũ (nhưng điều đó yêu cầu bạn xóa phiên bản cũ bị lỗi) nhưng điều đó khiến cho việc xác định nguyên nhân gốc rễ của vấn đề không thể thực hiện được.
Gián đoạn Khu vực Khả dụng
Sự gián đoạn Vùng khả dụng có thể là tạm thời và rất hiếm, tuy nhiên, nếu lỗi AZ thường xuyên hơn thì phiên bản sẽ được đặt thành trạng thái không thành công. Quá trình khôi phục sẽ hoạt động như được mô tả trước đó và một phiên bản mới có thể được tạo ở một AZ khác, bằng cách sử dụng khôi phục tại điểm trong thời gian. Bước này phải được thực hiện thủ công hoặc theo kịch bản. Chiến lược cho loại tình huống khôi phục này phải là một phần trong kế hoạch khôi phục sau thảm họa (DR) lớn hơn của bạn.
Nếu lỗi Vùng sẵn sàng là tạm thời, cơ sở dữ liệu sẽ ngừng hoạt động nhưng vẫn ở trạng thái khả dụng. Bạn chịu trách nhiệm giám sát cấp ứng dụng (sử dụng công cụ của Amazon hoặc bên thứ ba) để phát hiện loại tình huống này. Nếu điều này xảy ra, bạn có thể đợi cho Vùng sẵn sàng phục hồi hoặc bạn có thể chọn khôi phục phiên bản sang Vùng khả dụng khác bằng cách khôi phục tại thời điểm.
RTO sẽ là thời gian cần thiết để khởi động một phiên bản RDS mới và sau đó áp dụng tất cả các thay đổi kể từ lần sao lưu cuối cùng. RPO có thể dài hơn, tính đến thời điểm xảy ra lỗi Vùng khả dụng.
Thử nghiệm chuyển đổi dự phòng và dự phòng trên Amazon RDS
Chúng tôi đã tạo và thiết lập Amazon RDS Aurora bằng cách sử dụng db.r4.large với triển khai Multi-AZ (sẽ tạo ra một bản sao / trình đọc Aurora ở một AZ khác) mà chỉ có thể truy cập thông qua EC2. Bạn sẽ cần đảm bảo chọn tùy chọn này khi tạo nếu bạn định sử dụng Amazon RDS làm cơ chế chuyển đổi dự phòng.
Trong quá trình cung cấp phiên bản RDS của chúng tôi, mất khoảng ~ 11 phút trước các phiên bản đã trở nên khả dụng và có thể truy cập được. Dưới đây là ảnh chụp màn hình của các nút có sẵn trong RDS sau khi tạo:
Hai nút này sẽ có tên điểm cuối được chỉ định riêng, chúng tôi sẽ sử dụng để kết nối từ quan điểm của khách hàng. Xác minh nó trước và kiểm tra tên máy chủ cơ bản cho từng nút này. Để kiểm tra, bạn có thể chạy lệnh bash này bên dưới và chỉ cần thay thế tên máy chủ / tên điểm cuối cho phù hợp:
[email protected]:~# host=('s9s-db-aurora.cluster-cmu8qdlvkepg.us-east-2.rds.amazonaws.com' 's9s-db-aurora.cluster-ro-cmu8qdlvkepg.us-east-2.rds.amazonaws.com'); for h in "${host[@]}"; do mysql -h $h -e "select @@hostname; select @@global.innodb_read_only"; done;
+---------------+
| @@hostname |
+---------------+
| ip-10-20-0-94 |
+---------------+
+---------------------------+
| @@global.innodb_read_only |
+---------------------------+
| 0 |
+---------------------------+
+----------------+
| @@hostname |
+----------------+
| ip-10-20-1-139 |
+----------------+
+---------------------------+
| @@global.innodb_read_only |
+---------------------------+
| 1 |
+---------------------------+Kết quả làm rõ như sau,
s9s-db-aurora-instance-1 = s9s-db-aurora.cluster-cmu8qdlvkepg.us-east-2.rds.amazonaws.com = ip-10-20-0-94 (read-write)
s9s-db-aurora-instance-1-us-east-2b = s9s-db-aurora.cluster-ro-cmu8qdlvkepg.us-east-2.rds.amazonaws.com = ip-10-20-1-139 (read-only)Mô phỏng chuyển đổi dự phòng Amazon RDS
Bây giờ, hãy mô phỏng sự cố để mô phỏng chuyển đổi dự phòng cho phiên bản người viết Amazon RDS Aurora, là s9s-db-aurora-instance-1 với điểm cuối s9s-db-aurora.cluster-cmu8qdlvkepg.us -east-2.rds.amazonaws.com.
Để thực hiện việc này, hãy kết nối với phiên bản nhà văn của bạn bằng cách sử dụng dấu nhắc lệnh ứng dụng khách mysql và sau đó đưa ra cú pháp bên dưới:
ALTER SYSTEM SIMULATE percentage_of_failure PERCENT DISK FAILURE [ IN DISK index | NODE index ]
FOR INTERVAL quantity [ YEAR | QUARTER | MONTH | WEEK| DAY | HOUR | MINUTE | SECOND ];Việc phát hành lệnh này có khả năng phát hiện khôi phục Amazon RDS và hoạt động khá nhanh chóng. Mặc dù truy vấn dành cho mục đích thử nghiệm, nhưng nó có thể khác khi sự kiện này xảy ra trong một sự kiện thực tế. Bạn có thể muốn biết thêm về cách kiểm tra sự cố phiên bản trong tài liệu của họ. Xem cách chúng tôi kết thúc bên dưới:
mysql> ALTER SYSTEM SIMULATE 100 PERCENT DISK FAILURE FOR INTERVAL 3 MINUTE;
Query OK, 0 rows affected (0.01 sec)Chạy lệnh SQL ở trên có nghĩa là nó phải mô phỏng lỗi ổ đĩa trong ít nhất 3 phút. Tôi đã theo dõi thời điểm bắt đầu mô phỏng và mất khoảng 18 giây trước khi quá trình chuyển đổi dự phòng bắt đầu.
Xem bên dưới về cách RDS xử lý lỗi mô phỏng và chuyển đổi dự phòng,
Tue Sep 24 10:06:29 UTC 2019
+---------------+
| @@hostname |
+---------------+
| ip-10-20-0-94 |
+---------------+
+---------------------------+
| @@global.innodb_read_only |
+---------------------------+
| 0 |
+---------------------------+
+----------------+
| @@hostname |
+----------------+
| ip-10-20-1-139 |
+----------------+
+---------------------------+
| @@global.innodb_read_only |
+---------------------------+
| 1 |
+---------------------------+
….
…..
………..
Tue Sep 24 10:06:44 UTC 2019
+---------------+
| @@hostname |
+---------------+
| ip-10-20-0-94 |
+---------------+
+---------------------------+
| @@global.innodb_read_only |
+---------------------------+
| 0 |
+---------------------------+
ERROR 2003 (HY000): Can't connect to MySQL server on 's9s-db-aurora.cluster-ro-cmu8qdlvkepg.us-east-2.rds.amazonaws.com' (111)
….
……..
………..
Tue Sep 24 10:06:51 UTC 2019
+---------------+
| @@hostname |
+---------------+
| ip-10-20-0-94 |
+---------------+
+---------------------------+
| @@global.innodb_read_only |
+---------------------------+
| 0 |
+---------------------------+
+----------------+
| @@hostname |
+----------------+
| ip-10-20-1-139 |
+----------------+
+---------------------------+
| @@global.innodb_read_only |
+---------------------------+
| 0 |
+---------------------------+
….
………..
…………………
Tue Sep 24 10:07:13 UTC 2019
+----------------+
| @@hostname |
+----------------+
| ip-10-20-1-139 |
+----------------+
+---------------------------+
| @@global.innodb_read_only |
+---------------------------+
| 0 |
+---------------------------+
+---------------+
| @@hostname |
+---------------+
| ip-10-20-0-94 |
+---------------+
+---------------------------+
| @@global.innodb_read_only |
+---------------------------+
| 1 |
+---------------------------+Kết quả của mô phỏng này khá thú vị. Hãy lấy cái này từng cái một.
- Vào khoảng 10:06:29, tôi bắt đầu chạy truy vấn mô phỏng như đã nêu ở trên.
- Vào khoảng 10:06:44, nó cho thấy rằng điểm cuối s9s-db-aurora.cluster-ro-cmu8qdlvkepg.us-east-2.rds.amazonaws.com với tên máy chủ được chỉ định là ip-10-20-1- 139 trong thực tế đó là phiên bản chỉ đọc, không thể truy cập được, tuy nhiên lệnh mô phỏng được chạy trong phiên bản chỉ đọc.
- Vào khoảng 10:06:51, nó cho thấy rằng điểm cuối s9s-db-aurora.cluster-ro-cmu8qdlvkepg.us-east-2.rds.amazonaws.com với tên máy chủ được chỉ định là ip-10-20-1- 139 là lên nhưng nó có đánh dấu là trạng thái đọc-ghi. Hãy lưu ý rằng biến innodb_read_only, đối với các phiên bản được quản lý bởi Aurora MySQL, đây là mã định danh của nó để xác định xem máy chủ lưu trữ là nút đọc-ghi hay chỉ đọc và Aurora cũng chỉ chạy trên công cụ lưu trữ InnoDB cho các phiên bản MySQL có thể so sánh được.
- Vào khoảng 10:07:13, thứ tự đã thay đổi. Điều này có nghĩa là quá trình chuyển đổi dự phòng đã được thực hiện và các cá thể đã được gán cho các điểm cuối được chỉ định của nó.
Kiểm tra kết quả dưới đây được hiển thị trong bảng điều khiển RDS:
Nếu bạn so sánh với phiên bản trước đó, s9s-db-aurora- instance-1 là một độc giả, nhưng sau đó được thăng cấp như một nhà văn sau khi chuyển đổi dự phòng. Quá trình bao gồm cả bài kiểm tra mất khoảng 44 giây để hoàn thành nhiệm vụ, nhưng quá trình chuyển đổi dự phòng đã hoàn thành trong gần 30 giây. Điều đó thật ấn tượng và nhanh chóng đối với chuyển đổi dự phòng, đặc biệt khi coi đây là cơ sở dữ liệu dịch vụ được quản lý; nghĩa là bạn không cần phải lo lắng về bất kỳ vấn đề phần cứng hoặc bảo trì nào.
Thực hiện Dự phòng trong Amazon RDS
Dự phòng trong Amazon RDS khá đơn giản. Trước khi xem qua, hãy thêm một bản sao trình đọc mới. Chúng tôi cần một tùy chọn để kiểm tra và xác định xem AWS RDS sẽ chọn nút nào khi nó cố gắng không quay lại được cái chính mong muốn (hoặc dự phòng trở lại cái chính trước đó) và để xem liệu nó có chọn đúng nút dựa trên mức độ ưu tiên hay không. Danh sách các phiên bản hiện tại tính đến thời điểm hiện tại và các điểm cuối của nó được hiển thị bên dưới.
Bản sao mới nằm trên us-west-2c AZ với tên máy chủ db của ip-10-20-2-239.
Chúng tôi sẽ cố gắng thực hiện dự phòng bằng cách sử dụng cá thể s9s-db-aurora-instance-1 làm mục tiêu dự phòng mong muốn. Trong thiết lập này, chúng tôi có hai phiên bản trình đọc. Để đảm bảo rằng nút chính xác được chọn trong quá trình chuyển đổi dự phòng, bạn sẽ cần xác định mức độ ưu tiên hoặc tính khả dụng có ở trên cùng hay không (cấp-0> cấp-1> cấp-2, v.v. cho đến cấp-15). Điều này có thể được thực hiện bằng cách sửa đổi phiên bản hoặc trong quá trình tạo bản sao.
Bạn có thể xác minh điều này trong bảng điều khiển RDS của mình.
Trong thiết lập này, s9s-db-aurora-instance-1 có ưu tiên =0 (và là bản sao đọc), s9s-db-aurora-instance-1-us-East-2b có priority =1 (và là người viết hiện tại) và s9s-db-aurora-instance-1-us- East-2c có mức độ ưu tiên =2 (và cũng là bản sao đọc). Hãy xem điều gì sẽ xảy ra khi chúng tôi cố gắng khôi phục dự phòng.
Bạn có thể theo dõi trạng thái bằng cách sử dụng lệnh này.
$ host=('s9s-db-aurora.cluster-cmu8qdlvkepg.us-east-2.rds.amazonaws.com' 's9s-db-aurora.cluster-ro-cmu8qdlvkepg.us-east-2.rds.amazonaws.com' 's9s-us-east-2c.cluster-custom-cmu8qdlvkepg.us-east-2.rds.amazonaws.com'); while true; do echo -e "\n==========================================="; date; echo -e "===========================================\n"; for h in "${host[@]}"; do mysql -h $h -e "select @@hostname; select @@global.innodb_read_only"; done; sleep 1; done;Sau khi kích hoạt chuyển đổi dự phòng, nó sẽ dự phòng trở lại mục tiêu mong muốn của chúng ta, đó là nút s9s-db-aurora-instance-1.
===========================================
Tue Sep 24 13:30:59 UTC 2019
===========================================
+----------------+
| @@hostname |
+----------------+
| ip-10-20-1-139 |
+----------------+
+---------------------------+
| @@global.innodb_read_only |
+---------------------------+
| 0 |
+---------------------------+
+---------------+
| @@hostname |
+---------------+
| ip-10-20-0-94 |
+---------------+
+---------------------------+
| @@global.innodb_read_only |
+---------------------------+
| 1 |
+---------------------------+
+----------------+
| @@hostname |
+----------------+
| ip-10-20-2-239 |
+----------------+
+---------------------------+
| @@global.innodb_read_only |
+---------------------------+
| 1 |
+---------------------------+
…
……
………
===========================================
Tue Sep 24 13:31:35 UTC 2019
===========================================
+----------------+
| @@hostname |
+----------------+
| ip-10-20-1-139 |
+----------------+
+---------------------------+
| @@global.innodb_read_only |
+---------------------------+
| 1 |
+---------------------------+
ERROR 2003 (HY000): Can't connect to MySQL server on 's9s-db-aurora.cluster-ro-cmu8qdlvkepg.us-east-2.rds.amazonaws.com' (111)
ERROR 2003 (HY000): Can't connect to MySQL server on 's9s-us-east-2c.cluster-custom-cmu8qdlvkepg.us-east-2.rds.amazonaws.com' (111)
….
…..
===========================================
Tue Sep 24 13:31:38 UTC 2019
===========================================
+---------------+
| @@hostname |
+---------------+
| ip-10-20-0-94 |
+---------------+
+---------------------------+
| @@global.innodb_read_only |
+---------------------------+
| 0 |
+---------------------------+
+----------------+
| @@hostname |
+----------------+
| ip-10-20-2-239 |
+----------------+
+---------------------------+
| @@global.innodb_read_only |
+---------------------------+
| 1 |
+---------------------------+
+----------------+
| @@hostname |
+----------------+
| ip-10-20-2-239 |
+----------------+
+---------------------------+
| @@global.innodb_read_only |
+---------------------------+
| 1 |
+---------------------------+Nỗ lực khôi phục dự phòng bắt đầu lúc 13:30:59 và hoàn thành vào khoảng 13:31:38 (mốc 30 giây gần nhất). Nó kết thúc ~ 32 giây trong bài kiểm tra này, vẫn còn nhanh.
Tôi đã xác minh chuyển đổi dự phòng / dự phòng nhiều lần và nó đã liên tục trao đổi trạng thái đọc-ghi giữa các trường hợp s9s-db-aurora-instance-1 và s9s-db-aurora-instance-1- us-đông-2b. Điều này khiến s9s-db-aurora-instance-1-us-East-2c được bỏ chọn trừ khi cả hai nút đang gặp sự cố (điều này rất hiếm khi tất cả chúng đều nằm ở các AZ khác nhau).
Trong quá trình chuyển đổi dự phòng / dự phòng, RDS diễn ra với tốc độ chuyển đổi nhanh chóng trong quá trình chuyển đổi dự phòng vào khoảng 15 - 25 giây (rất nhanh). Xin lưu ý rằng chúng tôi không có tệp dữ liệu khổng lồ được lưu trữ trên phiên bản này, nhưng nó vẫn khá ấn tượng khi không có thêm gì để quản lý.
Kết luận
Chạy Single-AZ gây nguy hiểm khi thực hiện chuyển đổi dự phòng. Amazon RDS cho phép bạn sửa đổi và chuyển đổi thiết lập Single-AZ sang Multi-AZ, mặc dù điều này sẽ khiến bạn thêm một số chi phí. Single-AZ có thể ổn nếu bạn thấy ổn với thời gian RTO và RPO cao hơn, nhưng chắc chắn không được khuyến nghị cho các ứng dụng kinh doanh có lưu lượng truy cập cao, đặc biệt quan trọng.
Với Multi-AZ, bạn có thể tự động chuyển đổi dự phòng và dự phòng trên Amazon RDS, dành thời gian tập trung vào việc điều chỉnh hoặc tối ưu hóa truy vấn. Điều này giúp giảm bớt nhiều vấn đề mà DevOps hoặc DBA phải đối mặt.
Mặc dù Amazon RDS có thể gây ra tình thế tiến thoái lưỡng nan ở một số tổ chức (vì nó không phải là nền tảng bất khả tri), nhưng nó vẫn đáng được xem xét; đặc biệt nếu ứng dụng của bạn yêu cầu một kế hoạch DR dài hạn và bạn không muốn phải mất thời gian lo lắng về việc lập kế hoạch phần cứng và dung lượng.
