Làm thế nào để kết xuất hiệu quả một cơ sở dữ liệu innodb MySQL khổng lồ?

Tôi đã nhận được một máy chủ cơ sở dữ liệu MySQL sản xuất Ubuntu 10.04 với tổng kích thước cơ sở dữ liệu là 260 GB trong khi kích thước của phân vùng gốc là 300 GB nơi lưu trữ DB, về cơ bản có nghĩa là khoảng 96% / đã đầy và không còn chỗ để lưu trữ kết xuất / sao lưu vv Hiện tại không có đĩa nào khác được gắn vào máy chủ.

Nhiệm vụ của tôi là di chuyển cơ sở dữ liệu này sang máy chủ khác trong trung tâm dữ liệu khác nhau. Câu hỏi là làm thế nào để làm điều đó một cách hiệu quả với thời gian chết tối thiểu?

Tôi đang suy nghĩ theo dòng:

• Yêu cầu gắn thêm một ổ đĩa vào máy chủ và kết xuất trong ổ đĩa đó. [EDIT: Hiện tại không thể.]
• Chuyển kết xuất sang máy chủ mới, khôi phục nó và tạo nô lệ máy chủ mới của máy chủ hiện có để giữ dữ liệu đồng bộ
• Khi cần di chuyển, ngắt sao chép, cập nhật cấu hình nô lệ để chấp nhận các yêu cầu đọc / ghi và làm cho máy chủ cũ chỉ đọc để nó không giải trí bất kỳ yêu cầu ghi nào và yêu cầu các nhà phát triển ứng dụng cập nhật cấu hình với địa chỉ IP mới cho db.

Đề xuất của bạn để cải thiện điều này hoặc bất kỳ cách tiếp cận tốt hơn thay thế cho nhiệm vụ này là gì?

Nếu bạn đang cân nhắc chuyển sang một DB Server với cùng một phiên bản chính xác của MySQL, bạn có thể muốn rsynccác datadirtừ server cũ sang máy chủ mới.

Điều này sẽ hoạt động bất kể bố cục tệp InnoDB hoặc thậm chí sự hiện diện của các bảng MyISAM.

1. cài đặt cùng một phiên bản mysql trên ServerB mà ServerA có
2. Trên ServerA, chạy RESET MASTER;để xóa tất cả các bản ghi nhị phân trước quá trình rsycn. Nếu đăng nhập nhị phân không được kích hoạt, bạn có thể bỏ qua bước này.
3. Trên ServerA, chạy SET GLOBAL innodb_max_dirty_pages_pct = 0;từ mysql và khoảng 10 phút (Thao tác này sẽ xóa các trang bẩn từ Nhóm đệm InnoDB. Nó cũng giúp thực hiện tắt máy mysql nhanh hơn) Nếu cơ sở dữ liệu của bạn là tất cả MyISAM, bạn có thể bỏ qua bước này.
4. rsync / var / lib / mysql của ServerA thành / var / lib / mysql trên ServerB
5. Lặp lại Bước 3 cho đến khi rsync mất ít hơn 1 phút
6. service mysql stop trên ServerA
7. Thực hiện thêm một rsync
8. scp ServerA: /etc/my.cnf đến ServerB: / etc /.
9. service mysql start trên ServerB
10. service mysql start trên ServerA (tùy chọn)

Về cơ bản, đây là những gì một kịch bản như vậy muốn

mysql -u... -p... -e"RESET MASTER;"
mysql -u... -p... -e"SET GLOBAL innodb_max_dirty_pages_pct = 0;"
RSYNCSTOTRY=10
cd /var/lib/mysql
X=0
while [ ${X} -lt ${RSYNCSTOTRY} ]
do
    X=`echo ${X}+1|bc`
    rsync -r * targetserver:/var/lib/mysql/.
    sleep 60
done
service mysql stop
rsync -r * targetserver:/var/lib/mysql/.
service mysql start

Một thành viên của DBA StackExchange nói rằng tôi nên tránh xa FLUSH TABLES WITH READ LOCK;dựa trên một cái gì đó trong mysqlperformanceblog.com

Tôi đã đọc qua và biết rằng các CHỌN đối với các bảng InnoDB ở giữa một FLUSH TABLES WITH READ LOCK;vẫn có thể cho phép ghi xảy ra theo một cách nào đó. Như Arlukin đã chỉ ra trong nhận xét , LVM sẽ hoạt động với FLUSH TABLES WITH READ LOCKInnoDB tốt (+1 cho nhận xét của anh ấy).

• http://www.mysqlperformanceblog.com/2012/03/23/how-flush-tables-with-read-lock-works-with-innodb-tables/
• http://forums.mysql.com/read.php?22,184590,184610

Đối với tất cả người dùng không phải LVM, bạn có thể sử dụng cơ sở dữ liệu toàn bộ MyISAM để sử dụng FLUSH TABLES WITH READ LOCK;. Đối với InnoDB, --single-tranactionvui lòng sử dụng trong mysqldumps.

Một bãi chứa và khôi phục cơ sở dữ liệu có kích thước sẽ mất nhiều giờ. Tôi sẽ, Tùy thuộc vào các phiên bản của mysql miễn là số phiên bản tăng lên và không có bước nhảy nào trong số sửa đổi chính. Bạn sẽ có thể lấy các tệp cơ sở dữ liệu thô trong / var / lib / mysql và đặt chúng trên máy chủ mới, đặt quyền và kích hoạt máy chủ bằng công tắc --skip-Grant-bảng. Thêm các khoản trợ cấp cần thiết cho người dùng phản ánh địa chỉ IP mới sau đó khởi động lại bình thường.

Tôi sẽ giải quyết kích thước của cơ sở dữ liệu của bạn vì nó quá lớn để có hiệu quả.

Bạn có thể làm theo các bước sau để di chuyển cơ sở dữ liệu InnoDB khổng lồ này.

• Cài đặt SSHFS và gắn kết phân vùng có liên quan của máy chủ từ xa trên máy chủ sản xuất
• Sử dụng Percona XtraBackup để lấy bản sao nóng của cơ sở dữ liệu InnoDB và lưu trực tiếp vào thư mục được gắn SSHFS

• Nhiệm vụ này sẽ mất vài giờ. Để giảm thiểu ảnh hưởng của tập lệnh hotcopy trên máy chủ trực tiếp, hãy đặt mức độ ưu tiên thấp cho nó bằng cách sử dụng renice

  $ renice -n 5 -p <SCRIPT-PID>

• Đảm bảo rằng cả hai máy chủ đang chạy cùng một bản phát hành của máy chủ MySQL.
• Khi hotcopy hoàn tất, bạn có thể khôi phục nó trong máy chủ mới bắt đầu quá trình sao chép

Bạn có thể gặp sự chậm chạp trong quá trình này nhưng chắc chắn không có thời gian chết. Percona XtraBackup sẽ tạo ra một bản sao nóng nhanh hơn và tiêu tốn ít tài nguyên hơn so với mysqldump. Điều này là lý tưởng cho một cơ sở dữ liệu InnoDB khổng lồ.

Tùy thuộc vào kiểu sử dụng và số liệu thống kê, bạn có thể chạy quy trình này khi có lưu lượng tối thiểu trên máy chủ. Có lẽ làm điều này vào cuối tuần là một ý tưởng tốt? Trên đây chỉ là một phác thảo của quá trình. Bạn có thể cần phải xem qua tài liệu Percona XtraBackup và SSHFS.

Bạn chỉ có thể chuyển cơ sở dữ liệu thẳng đến máy chủ từ xa ...

$ mysqldump | ssh user@server 'cat - > dumpfile.sql.gz'

... SQL nên nén tốt, do đó bạn sẽ hoàn thành việc này nhanh hơn rất nhiều với một trong các tùy chọn này mặc dù nó cũng phụ thuộc vào dung lượng RAM bạn có trong hộp ...

$ mysqldump | ssh -C user@server 'cat - > dumpfile.sql.gz'
$ mysqldump | gzip -c | ssh user@server 'cat - > dumpfile.sql.gz'