Trước tiên, chúng ta sẽ hiểu về bộ nhớ trong RDS Aurora. Có 2 loại lưu trữ trong Aurora. Cửa hàng phiên bản là bộ nhớ cục bộ nơi các đối tượng tạm thời được lưu trữ và bộ nhớ chính cho dữ liệu. Do đó, khi bạn chạy ALTER trên một bảng, nó sẽ tạo ra một bảng tạm thời và RDS aurora sẽ sử dụng bộ lưu trữ cá thể để lưu trữ bảng tạm thời. Đối với phiên bản của bạn là phiên bản db.r3.large, nó có 1 × 32 GB bộ nhớ cục bộ, vì vậy nếu các đối tượng tạm thời của bạn trên phiên bản này lớn hơn kích thước này, bạn sẽ gặp lỗi "table full". Ngoài ra, giới hạn bộ nhớ cục bộ khác với tổng số dung lượng bộ nhớ có sẵn cho phiên bản Aurora của bạn và dựa trên việc sử dụng cơ sở dữ liệu của bạn, dung lượng lưu trữ Amazon Aurora của bạn sẽ tự động tăng lên, lên đến 64 TB, với gia số 10GB.Tại sao sự cố này lại xảy ra mặc dù dung lượng bộ nhớ Amazon Aurora sẽ tự động tăng lên đến 64TB.?
Thay thế trên bàn lớn trong RDS giải pháp cho toàn bảng Lỗi
- Để khắc phục sự cố, bạn có thể mở rộng phiên bản để có thêm bộ nhớ cục bộ để chạy ALTER của bạn, thay đổi bảng sau đó giảm tỷ lệ loại phiên bản. Điều này dẫn đến có một số thời gian ngừng hoạt động trong khi loại phiên bản nâng cấp / hạ cấp.
- Bạn cũng có thể sử dụng lệnh:“pt-online-schema-change”, nếu bạn sử dụng lệnh này, nó làm cho bảng gốc vẫn có sẵn để sử dụng mà không có thời gian chết hoặc không có khóa bàn.
Kết quả:
Nếu bạn đang thay đổi bảng bằng pt -online-schema-change lệnh trên một bảng có kích thước 35-40GB thì có thể mất gần 30 giờ.pt-online-schema-change không khóa bàn. Lệnh này tạo các trình kích hoạt trên bảng gốc. Nhưng đối với điều này, nó cần các đặc quyền của người dùng siêu cấp. khi bạn đang sử dụng thủ tục lưu trữ, bạn sẽ gặp lỗi:Tại sao sử dụng lệnh pt-online-schema-change và tại sao nên bật “log_bin_trust_osystem_creators“ trong nhóm tham số DB? ?
# 1419 - Bạn không có đặc quyền SUPER và ghi nhật ký nhị phân được bật (bạn * có thể * muốn sử dụng biến log_bin_trust_ Chức năng_creators ít an toàn hơn.Lý do: Lỗi này xảy ra trên các trường hợp RDS khi bạn cố gắng sử dụng "Thủ tục đã lưu trữ". Bạn sẽ sớm nhận ra rằng việc cấp siêu đặc quyền cho người dùng sẽ không hoạt động. Vì vậy, cách duy nhất để làm cho mọi thứ hoạt động là đặt log_bin_trust_osystem_creators thành 1. Theo tài liệu Percona: Điểm mấu chốt là việc tạo trình kích hoạt trên máy chủ có bật nhật ký nhị phân yêu cầu người dùng có SUPER đặc quyền (điều này là không thể trong Amazon RDS). Thông báo lỗi chỉ định cách giải quyết. Chúng ta cần bật biến trong nhóm tham số DB “log_bin_trust_ Chức năng_creators”. Kích hoạt nó giống như nói với máy chủ: “Tôi tin tưởng các chức năng và trình kích hoạt của người dùng thông thường và chúng sẽ không gây ra sự cố, vì vậy hãy cho phép người dùng của tôi tạo chúng.” Vì chức năng cơ sở dữ liệu sẽ không thay đổi, nên vấn đề tin tưởng người dùng của bạn sẽ là vấn đề. log_bin_trust_ Chức năng_creators là một biến toàn cục có thể được thay đổi động. Cố gắng tìm thêm chi tiết về “Super_priv”, Khi bạn kiểm tra quyền của người dùng trong bảng người dùng của cơ sở dữ liệu MySQL. bạn có thể thấy rằng Super_priv không được đặt cho bất kỳ ai ngoại trừ người dùng rdsadmin.
MySQL> select User,Super_priv from user; +-----------+------------+ | User | Super_priv | +-----------+------------+ | rdsadmin | Y | | root | N | | dbuser | N | +-----------+------------+ 3 rows in set (0.00 sec)
Ở đây “root” là người dùng Chính và “dbuser” là người dùng DB, những người dùng này do chúng tôi tạo ra và người dùng “rdsadmin” được AWS tạo tự động mà chúng tôi không có quyền truy cập vào người dùng này. Người dùng rdsadmin MySQL được Amazon sử dụng cho công việc quản lý và bảo trì.
Đây là phần cuối của hướng dẫn, cách Thay đổi trên Big Table trong RDS Giải pháp cho toàn bộ Lỗi.
