Cách tối ưu để nâng cấp sản xuất RDS là gì?


33

Tôi có phiên bản RDS nhỏ của MySQL như một phần của hệ thống sản xuất của mình và tôi muốn nâng cấp nó lên phiên bản trung bình với IOPS được cung cấp.

Là một DBA trường học cũ, tôi biết về phương pháp "thêm nô lệ, thăng cấp thành chủ; chuyển đổi máy khách", nhưng AWS hứa sẽ cung cấp đường dẫn nâng cấp ma thuật bằng một cú nhấp chuột, tức là "ví dụ nâng cấp", "thêm IOPS được cung cấp".

Đã thử điều này trên ví dụ RDS thử nghiệm, thời gian chết quá dài, IMHO: khoảng 5 phút để nâng cấp nhỏ>> trung bình và 30 phút (!!!) để chuyển sang IOPS được cung cấp.

  • Đây có phải là hành vi bình thường?
  • Có cách nào để chạy nâng cấp trên RDS sản xuất không có thời gian chết không?
  • Bạn có đề xuất cách "dừng lại, tạo ảnh chụp nhanh, khôi phục từ ảnh chụp nhanh sang trường hợp lớn hơn" không?

Câu trả lời:


37

Nâng cấp một cá thể trong RDS có nghĩa là RDS sẽ di chuyển cơ sở dữ liệu sang một thể hiện mới, có khả năng trên một máy chủ vật lý khác, vì vậy không thể tránh khỏi thời gian chết. Di chuyển sang IOPS được cung cấp có thể có nghĩa là dữ liệu của bạn sẽ được di chuyển sang một khối EBS mới (và máy chủ có thể được di chuyển sang một phiên bản mới cũng như với thay đổi này, tùy thuộc vào việc, bên trong, các máy có khả năng truy cập vào khối EBS được cung cấp với IOPS được cung cấp hay không tách biệt về mặt vật lý với các máy không có, để chúng có thể thuộc một loại phần cứng mạng khác), do đó thời gian chết sẽ không thể tránh khỏi.

Dường như có một cách để tránh sự gián đoạn này: triển khai Multi-AZ, tạo ra một bản sao vô hình và không thể tiếp cận (với bạn) trong một khu vực sẵn có khác trong khu vực.

Trong trường hợp nâng cấp hệ thống như vá hệ điều hành hoặc nhân rộng DB Instance, các thao tác này được áp dụng đầu tiên ở chế độ chờ, trước khi chuyển đổi dự phòng tự động. Do đó, tác động khả dụng của bạn chỉ giới hạn trong thời gian cần thiết để chuyển đổi dự phòng tự động hoàn tất.

- http://aws.amazon.com/rds/multi-az/

Điều đó sẽ cung cấp một đường dẫn di chuyển nhanh chóng và liền mạch, mặc dù tôi không có cơ hội để kiểm tra khả năng này. "Sửa đổi" trong bảng điều khiển dường như cho phép bạn chuyển đổi một thể hiện thành Multi-AZ. Có lẽ, điều này sẽ dẫn đến đóng băng I / O ngắn gọn vì cá thể được nhân bản, vì vậy tôi tất nhiên sẽ khuyên bạn nên thử nghiệm tất cả các chức năng này trước khi thử.

Cách khác, RDS hỗ trợ một cơ chế bên trong cho phép bạn mô phỏng hoạt động "thêm nô lệ, thăng cấp thành chủ, chuyển đổi máy khách" và điều này cũng sẽ cho phép bạn đạt được chuyển đổi gần như không thời gian chết:

  • Tạo một bản sao đọc RDS thực tế của cơ sở dữ liệu của bạn với lớp cá thể mong muốn
  • Đợi bản sao xuất hiện trực tuyến và được đồng bộ hóa với bản gốc
  • Sửa đổi cấu hình của bản sao để thêm IOPS được cấp phép
  • Đợi bản sao xuất hiện trực tuyến và được đồng bộ hóa với bản gốc
  • Xác minh rằng cả hai hệ thống có dữ liệu giống hệt nhau bằng các công cụ của bên thứ 3
  • Ngắt kết nối ứng dụng của bạn khỏi chủ cũ
  • Xác minh tọa độ binlog phù hợp trên bản gốc và bản sao để đảm bảo rằng tất cả các bản ghi ứng dụng đã được sao chép
  • Tách các hệ thống với "Thúc đẩy bản sao đọc" trên bản sao mới trong RDS
  • Kết nối ứng dụng của bạn với chủ mới

http://aws.amazon.com/about-aws/whats-new/2012/10/11/amazon-rds-mysql-rr-promotion/


Michael, cảm ơn rất nhiều vì đã trả lời chi tiết! Vitaly
Vitaly

quảng cáo một bản sao đã đọc lên bản gốc sẽ gây ra thời gian chết (vì ví dụ sẽ cần phải báo cáo) XEM RA!
Mahmoud Khateeb

@MahmoudKhateeb cảm ơn bạn. Đúng rồi. Mặc dù không có lý do kỹ thuật tại sao điều này lại cần thiết, RDS vẫn khởi động lại một thể hiện khi bạn quảng bá nó thành chủ. Thật vậy, tôi đã học được nhiều hơn về cách RDS hoạt động trong gần 4 năm (!?) Kể từ khi tôi viết nó. Tôi sẽ chỉnh sửa.
Michael - sqlbot

Tôi đang làm điều này trên Sản xuất vào thứ Hai, vì vậy tôi có thể có một số thứ để thêm. Về cơ bản tôi sẽ thay đổi bản sao để trở thành đọc / ghi sau đó tôi sẽ trỏ tất cả các dịch vụ của mình vào đó, sau đó tôi sẽ nâng cấp bản gốc.
Mahmoud Khateeb

@MahmoudKhateeb với RDS, khi bạn quảng cáo một bản sao, kết nối đến bản gốc bị ngắt vĩnh viễn. Bạn không thể quay lại sử dụng chủ cũ làm chủ. Bản sao cũ bây giờ là một bản gốc và phải giữ nguyên như vậy. Tạo một bản sao của bản sao hiện có, ngay bây giờ (RDS hỗ trợ các tầng) ... sau đó nâng cấp bản sao mới và bản sao cũ khi cần ... sau đó bắt đầu sử dụng bản sao mới làm bản sao sản xuất ... sau đó quảng bá bản sao gốc của bạn và bắt đầu sử dụng nó như là chủ mới. Ném chủ cũ đi.
Michael - sqlbot

4

Ngay cả với môi trường nhiều AZ, bạn sẽ bị cúp 60-120s. Đây là trường hợp khi tôi liên tục nhấn các phiên bản RDS của chúng tôi trong khi thực hiện nâng cấp từ PostgreSQL db.m3.medium lên db.m3.large.


2

Nó cũng là POSSIBLE để tránh bất kỳ thời gian chết trong quá trình nâng cấp. Cách thực hiện là bằng cách khởi chạy nhanh một RDS mới từ ảnh chụp sao chép đã đọc và định cấu hình nó thành bản sao chủ động / hoạt động thành Master. Khi được định cấu hình, bạn có thể chuyển đổi lưu lượng ứng dụng một máy chủ APP tại thời điểm đó mà không có bất kỳ thời gian chết nào. Chúng tôi sử dụng phương pháp này mỗi khi AWS thông báo bảo trì RDS để tránh thời gian chết cũng như trong thời gian bảo trì theo lịch trình của chúng tôi.

https://workmarket.tech/zero-dftimeime-maintenances-on-mysql-rds-ba13b51103c2

Đây là những thông tin chi tiết:

M1 - Bậc thầy

R1 - Đọc bản sao của M1

SNAP1 - Ảnh chụp của R1

M2 - Thầy mới

Trình tự tạo M2: M1 → R1 → SNAP1 → M2

  • Vì chúng tôi không thể sử dụng đặc quyền SUPER trên RDS, chúng tôi không sử dụng mysqldump với — master_data2tùy chọn trên M1. Thay vào đó, chúng tôi khởi chạy R1 để có được vị trí binlog của M1 từ nó. Sau đó tạo ảnh chụp nhanh (SNAP1) từ R1 và sau đó khởi chạy M2 từ SNAP1.

  • Tạo hai nhóm tham số RDS riêng biệt với các offset sau để tránh các giới hạn PK:

    M1: auto_increment_ increment = 4 and auto_increment_offset = 1

    M2: auto_increment_ increment = 4 and auto_increment_offset = 2

  • Tạo người dùng sao chép trên M1

    GRANT EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO ‘repl’@’%’ IDENTIFIED BY PASSWORD <secret>;

1. Tạo R1 từ M1

-- Connect to the R1 and stop replication
   CALL mysql.rds_stop_replication;
-- Obtain M1’s (!!) current binlog file and position 
        `mysql> show slave status\G
             Master_Log_File: mysql-bin.000622
             Exec_Master_Log_Pos: 9135555

2. Tạo SNAP1 từ R1

  • Tạo M2 từ SNAP1 với các thuộc tính thu được từ M1

  • Gán một nhóm tham số cho M2 với độ lệch auto_increment_ khác với M1 để tránh xung đột khóa sao chép M / M

4. Thiết lập sao chép M / M

-- Configure M2 as a slave of M1
CALL mysql.rds_set_external_master (‘m1.xyxy24.us-east-1.rds.amazonaws.com’, 3306, repl’, mypassword’, mysql-bin.000622, 9135555, 0);
CALL mysql.rds_start_replication;
-- Connect to M2 and obtain its current binlog file and position
         mysql> show master status\G
            File: mysql-bin.004444
            Position: 6666622
-- Connect to M1 and configure it to be a slave of the M2
CALL mysql.rds_set_external_master (‘m2.xyxy24.us-east-1.rds.amazonaws.com’, 3306 , repl’, mypassword’, mysql-bin.004444, 6666622, 0);
CALL mysql.rds_start_replication;

5. Xóa R1 và SNAP1 vì chúng không còn cần thiết

6. Nâng cấp M2 qua Bảng điều khiển AWS

Sử dụng quy trình chuẩn để Sửa đổi sơ thẩm theo nhu cầu của bạn.

7. Thực hiện chuyển đổi duyên dáng sang M2

Khi sao chép M / M được thiết lập thành công, chúng tôi sẵn sàng tiến hành bảo trì DB mà không có thời gian chết bằng cách chuyển đổi duyên dáng các máy chủ ứng dụng tại thời điểm đó.

Dưới đây là chi tiết hơn về cách thức hoạt động.

https://workmarket.tech/zero-dftimeime-maintenances-on-mysql-rds-ba13b51103c2


1

Điều này sẽ hoạt động, tuy nhiên bạn phải đảm bảo rằng các điểm cuối của phiên bản RDS không được cấu hình trong ứng dụng của bạn dưới dạng một mục nhập tĩnh. Trao đổi RDS sẽ thay đổi các điểm cuối.


1
Vui lòng cung cấp thêm chất cho câu trả lời của bạn, chẳng hạn như một số tài liệu tham khảo để hỗ trợ câu trả lời của bạn và / hoặc lý luận mở rộng.
Erik
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.