Sao lưu cơ sở dữ liệu MySQL 22 GB hàng ngày

Ngay bây giờ tôi có thể thực hiện sao lưu bằng mysqldump. Nhưng tôi phải gỡ xuống máy chủ web VÀ phải mất khoảng 5 phút để thực hiện sao lưu. Nếu tôi không gỡ xuống máy chủ web, nó sẽ mất mãi mãi và không bao giờ kết thúc + trang web sẽ không thể truy cập được trong quá trình sao lưu.

Có cách nào nhanh hơn / tốt hơn để sao lưu cơ sở dữ liệu 22 GB và đang phát triển của tôi không?

Tất cả các bảng là MyISAM.

Vâng.

Thiết lập sao chép sang máy thứ hai. Khi bạn cần thực hiện sao lưu, bạn có thể khóa máy thứ cấp, thực hiện mysqlhotcopy hoặc mysqldump, sau đó mở khóa. Nó sẽ bắt kịp với chủ của bạn, và bạn không bao giờ phải lấy chủ ngoại tuyến.

Bạn thậm chí có thể thực hiện việc này trên cùng một máy, nếu bạn không muốn nhân đôi I / O ghi, nhưng lý tưởng nhất là bạn nên sao lưu nó trong thời gian thực tới máy chủ vật lý thứ hai và lấy bản sao lưu ảnh chụp của bạn thường xuyên khi bạn cần mà không làm phiền máy chủ sản xuất của bạn.

Về mặt lý thuyết cũng có thể khôi phục cơ sở dữ liệu bằng cách sử dụng trạng thái và binlog đã biết. Tôi chưa bao giờ thực hiện nó, vì vậy vui lòng điều tra trước, nhưng bạn có thể sao lưu trạng thái đã biết của cơ sở dữ liệu của mình, sau đó chỉ cần sao lưu tất cả các binlog mới và phát lại chúng nếu bạn cần khôi phục. Vì các binlog được viết một cách tuyến tính, việc kết hợp các binlog mới vào một máy tính từ xa sẽ rất nhanh.

Chỉnh sửa: Thật vậy, có vẻ như sử dụng binlog để sao lưu được ghi lại.

Câu hỏi này có liên quan cao

Xin lỗi vì đã cho rằng HĐH là Linux. Nếu bạn không sử dụng LVM, bạn nên làm. Nếu bạn là, đây là một cách rất đơn giản để tạo bản sao lưu thông qua ảnh chụp nhanh.

# Define these vars to meet your needs. These meet mine.
lvol="/dev/VolGroup03/lvol0"
snap_name="nightly_snapshot"
snap_vol="$(dirname $lvol)/$snap_name"
snap_path="/mnt/$snap_name"
snap_size="10g" # Not the size of your data, anticipated data changes during the backup
backup_path="/backups/$snap_name"

/usr/bin/time -f 'Databases were locked for %E' -- \
mysql <<- MYSQL
# based on http://pointyhair.com/tiki-view_blog_post.php?blogId=1&postId=5
FLUSH TABLES WITH READ LOCK;
\! lvcreate --size $snap_size --snapshot --name $snap_name $lvol
UNLOCK TABLES;
MYSQL
mount $snap_vol $snap_path
rsync -av --delete $snap_path/mysql $backup_path/
umount $snap_path
lvremove -f $snap_vol

Điều này sẽ cho phép bạn thực hiện sao lưu hàng đêm mà không cần phải thêm máy chủ nô lệ. Tôi rất ủng hộ việc có một máy chủ nô lệ cho Tính sẵn sàng cao, nhưng tôi không muốn bạn nghĩ rằng bạn đang bị mắc kẹt cho đến khi bạn có thể tạo ra nô lệ đó.

BẢNG XÁC SUẤT VỚI READ LOCK không phải là thứ bạn muốn làm một cách thường xuyên (hoặc thậm chí là bán thường xuyên) trên một hệ thống sản xuất. Nó chỉ là giải pháp cuối cùng thôi.

Thiết lập ít nhất hai nô lệ sao chép (Tất nhiên, điều này sẽ yêu cầu BẢNG XÓA B READNG ĐỌC KHÓA, tất nhiên). Khi chúng được thiết lập, bạn có thể tắt một bản sao lưu trong khi cái còn lại được đồng bộ hóa như một bản gốc dự phòng.

Ngoài ra, nếu một trong những nô lệ của bạn thất bại, thì bạn có thể sử dụng ảnh chụp nhanh từ đó để xây dựng lại một nô lệ thứ hai (hoặc thứ ba). Nếu tất cả các nô lệ của bạn thất bại, bạn quay trở lại BẢNG XÓA B READNG ĐỌC.

Hãy nhớ luôn luôn có một quy trình thường xuyên kiểm tra dữ liệu đồng bộ - sử dụng một cái gì đó như mk-table-checksum để làm điều này (điều này không cần thiết để thiết lập, tham khảo tài liệu Maatkit để biết chi tiết).

Vì 22 GB tương đối nhỏ, bạn sẽ không gặp vấn đề gì khi làm điều này. Làm điều đó với một cơ sở dữ liệu lớn có thể có nhiều vấn đề hơn.

Giải pháp ở đây có hai mặt, như mô tả ở trên:

1. Thiết lập sao chép máy chủ của bạn thành nô lệ mà bạn có thể ngoại tuyến. Cách tốt nhất để làm điều này là lấy một bãi chứa cơ sở dữ liệu bằng cách sử dụng mysqldump và tham số --master-data.
2. Thiết lập sao lưu hàng đêm trên nô lệ. Bạn có thể sử dụng mysqldump với các cờ --master-data --flush-log và --single-giao dịch, hoặc bạn có thể dừng máy chủ mysql, sao chép các tệp dữ liệu trên đĩa và khởi động lại nó (sao chép sẽ chọn ở đâu nó bỏ đi).
3. Chạy một kịch bản trên nô lệ mỗi (ví dụ 5, 10, 20 phút) để kiểm tra và đảm bảo rằng mysql vẫn đang sao chép. Tôi đã viết một kịch bản python đơn giản để làm điều đó, mà bạn hoan nghênh sử dụng.

Lưu ý rằng nếu bạn đang sử dụng InnoDB cho các bảng của mình, bạn có thể sử dụng cờ --single-giao dịch để tránh phải thực hiện bất kỳ khóa bảng nào và vẫn nhận được kết xuất cơ sở dữ liệu nhất quán, ngay cả trên bản chính và do đó, sao lưu mà không cần sao lưu hạ gục máy chủ. Các giải pháp trên, tuy nhiên, là một giải pháp tốt hơn.

Ngoài ra, nếu bạn đang sử dụng LVM trên Linux, bạn có thể chụp ảnh nhanh LVM của phân vùng, sau đó sao lưu. Ảnh chụp nhanh LVM là nguyên tử, vì vậy nếu bạn thực hiện 'xóa bảng bằng khóa đọc' và sau đó chụp ảnh nhanh và mở khóa, bạn sẽ có được một ảnh chụp nhanh nhất quán.

Nếu bạn lo lắng về việc tranh chấp I / O khiến việc kết xuất mất quá nhiều thời gian, bạn có thể thêm máy thứ ba và chạy mysqldump trên mạng đó để tránh làm hỏng đĩa của bạn.

Tùy thuộc vào môi trường của bạn, ảnh chụp nhanh thường là một cách tuyệt vời để đi. Đặc biệt nếu bạn phải sao lưu chủ vì một số lý do. Chúng tôi chạy các cặp chủ và nô lệ, và sử dụng các bản sao lưu ảnh chụp nhanh trên cả hai.

1. FLUSH TABLES WITH READ LOCK;
2. Kéo một ảnh chụp nhanh trên cơ sở dữ liệu và hệ thống tập tin nhật ký.
3. UNLOCK TABLES;
4. Sao chép các tập tin dữ liệu của bạn ra khỏi snapshot lúc rảnh rỗi.

Với các bảng InnoDB, bạn sẽ muốn chạy SET AUTOCOMMIT=0;trước khi thực hiện khóa đọc.

Hãy xem "Cách thực hành tốt nhất để sao lưu cơ sở dữ liệu MySQL sản xuất? ". Đây là một bài viết tương tự trên Stack Overflow.

Bạn có thể làm một bản sao lưu dần dần. Sao lưu 1/24 hồ sơ mỗi giờ. Vấn đề duy nhất với phương pháp này là nếu nó gặp sự cố trong vài giờ đầu tiên trong ngày, bạn sẽ mất bất cứ thứ gì từ thời điểm đó đến thời điểm xảy ra sự cố. Dù bằng cách nào, nó mất ít hơn 24 giờ hồ sơ (tôi không biết điều đó quan trọng với bạn như thế nào).