Cách để tự động quy mô máy chủ MySQL?


8

Tôi điều hành một trang web có lưu lượng truy cập tăng cao và vì các giải pháp mở rộng tự động đó rất có lợi cho trường hợp này. Hiện tại máy chủ web có thể tự động mở rộng quy mô theo chiều ngang nhưng nút cổ chai nằm trên máy chủ MySQL.

  • Tôi đã thử với Amazon RDS Multi-AZ nhưng phải mất 15 phút để cơ sở dữ liệu 12 GB nâng cấp với một số phút ngừng hoạt động. Nó đã giúp ích rất nhiều khi tôi đã biết rằng một sự đột biến giao thông sẽ xảy ra trong một thời điểm cụ thể.
  • Tôi cũng đã xem xét Xeround. Đây có lẽ là giải pháp tốt nhất mặc dù nó khá tốn kém cho cơ sở dữ liệu có kích thước này. Dù sao nó không phải là một lựa chọn vì tôi hợp pháp cần cơ sở dữ liệu ở Liên minh châu Âu.
  • Tôi đã đọc về Scalr nhưng không chắc điều đó có hữu ích không và bằng cách nào.
  • Tôi đã thấy rằng nhiều nhà cung cấp dịch vụ lưu trữ đám mây cung cấp các giải pháp mở rộng theo chiều dọc mà tôi nghĩ rằng nó có 0 thời gian chết (không chắc điều đó có thực sự khả thi hay không, theo như tôi biết họ sử dụng Xen hypanneror). Đó có thể là một giải pháp nhưng tôi tự hỏi nếu nó không có thời gian chết và làm thế nào cấu hình MySQL (và nhiều thứ khác trên HĐH) có thể nâng cấp mà không có thời gian chết.
  • Tôi đã thử với các máy chủ nô lệ của MySQL nhưng nó không hữu ích chút nào.
  • Tôi đang sử dụng memcache giúp ích rất nhiều nhưng vẫn chưa đủ. Tôi cần nâng cấp vì viết, không chỉ vì đọc.

Bất kỳ đề xuất? Cảm ơn bạn trước


có vẻ như bạn đang mắc kẹt với cùng một vấn đề như tôi :( Bạn có thể xem xét sao chép đa chủ hoặc thử sử dụng một giải pháp cơ sở dữ liệu khác cho các bảng có ghi nặng. Tôi hiện đang đánh giá voltdb, thay vào đó tôi đang xem xét chuyển một phần bảng sang voltdb của mysql.
Niko SP

Bạn có thể thêm chi tiết xung quanh "Tôi đã thử với máy chủ nô lệ MySQL nhưng nó không hữu ích chút nào". Bạn đã thay đổi kiến ​​trúc theo cách nào, bạn dự đoán điều gì sẽ xảy ra?
nickgrim

1
Phần mềm chúng tôi đang sử dụng đã được thiết kế để sử dụng máy chủ nô lệ MySQL nếu bạn muốn nhưng mặc dù vậy nó không giúp ích gì cả. Tôi nghĩ rằng memcache làm hầu hết tất cả các công việc nô lệ của MySQL (hầu hết các bài đọc). Tôi nghĩ rằng nô lệ MySQL là một vấn đề hơn là một cái gì đó tích cực nhưng dù sao thì nó phụ thuộc vào từng trường hợp, có thể trong một số trường hợp là hữu ích trong khi ở những trường hợp khác thì không.
Zillo

Câu trả lời:


4

Trên thực tế, một giải pháp đơn giản hơn là thử thêm Memcached vào ngăn xếp của bạn để tiết kiệm tải DB. Điều này có thể tiết kiệm đáng kể tải, và đơn giản hơn nhiều so với việc cố gắng giải quyết vấn đề nhanh chóng đứng lên máy chủ (độ khó thấp), và sau đó tìm ra đồng bộ hóa MySQL nhanh (độ khó cao hơn nhiều).

http://toblender.com/?s=memcached

Để giải quyết vấn đề ghi quá nhiều, cách khắc phục phổ biến nhất là thêm bộ nhớ vào máy chủ (có thể giữ bộ làm việc lớn hơn trong RAM), đặt DB của bạn lên các đĩa nhanh hơn (SSD là một giải pháp tốt, nhưng đắt tiền) hoặc shending (đắt tiền trong các máy chủ bổ sung và độ phức tạp).

Một cách khác để giảm tải ghi DB sẽ là kết hợp một kho lưu trữ dữ liệu trong bộ nhớ (như Redis) để xử lý dữ liệu thay đổi thường xuyên và nếu cần định kỳ ghi thay đổi trở lại DB chính của bạn.


bạn có thể đưa ra một ví dụ về cách memcached sẽ giúp giảm tải ghi trên máy chủ mysql không?
Niko SP

1
Lời xin lỗi; Tôi đã không nhìn thấy phần đó.
gWaldo

Cập nhật câu trả lời để giải quyết mối quan tâm về độ trễ ghi.
gWaldo

Đề xuất SSD của bạn là tiền, và SSD không nhất thiết phải đắt cho một cơ sở dữ liệu nhỏ như vậy. Ngay cả với cơ sở dữ liệu lớn hơn, ZFS vẫn có thể lưu trữ tất cả ghi trực tiếp vào flash SLC.
Skyhawk

Bạn đúng; SSD cho DB 12GB hoàn toàn không đắt. Tôi đã suy nghĩ nhiều về trường hợp chung hơn các thông số cụ thể của OP.
gWaldo

3

Bạn nên cân nhắc sử dụng cấu trúc liên kết hình sao

Đây là những gì tôi đang đề xuất

  • Một Master Viết (hay còn gọi là WM)
  • Một Master Master (hay còn gọi là DM)
  • Năm (5) Đọc máy chủ nô lệ (còn gọi là RSS)

Chuẩn bị cấu trúc liên kết như thế này

Bước 01: Thiết lập 5 RSS với các tùy chọn phổ biến này

[mysqld]
skip-innodb
key_buffer_size=1G

Điều này sẽ khiến tất cả các bảng được tạo được tải dưới dạng MyISAM Storage Engine

Bước 02: Thiết lập DM và tất cả các máy chủ RS

  • mysqldump lược đồ của tất cả các bảng từ WM đến tệp schemadump
  • tải tập tin schemadump vào DM và tất cả 5 RSS
  • chạy ALTER TABLE tblname ROW_FORMAT=Fixed;trên tất cả các bảng trong RSS
  • chạy ALTER TABLE tblname ENGINE=BLACKHOLE;trên tất cả các bảng trong DM
  • chỉ dữ liệu mysqldump (sử dụng --no-tạo-thông tin) cho một cơ sở dữ liệu
  • tải dữ liệu trong tất cả 5 RSS

Bước 03: Thiết lập sao chép từ DM sang tất cả 5 RSS

Bước 04: Thiết lập sao chép từ WM sang DM

KẾT THÚC CÀI ĐẶT

Đây là cách cơ chế đọc / ghi của bạn hoạt động

  • Tất cả các ghi của bạn (CHERTN, CẬP NHẬT, XÓA) xảy ra tại WM
  • SQL được ghi lại trong nhật ký nhị phân của DM (Không có dữ liệu thực tế nằm trong DM)
  • Mỗi RSS là một Slave đọc cho DM
  • Tất cả các lần đọc của bạn xảy ra tại RSS

Bây giờ đây là bắt ...

  • Bạn sử dụng RSS 1-4 để đọc ban đầu
  • Sử dụng RSS thứ 5 để quay các RSS khác
    • Bạn chạy service mysql stopở RSS thứ 5
    • Tạo một RSS khác
    • Sao chép / var / lib / mysql và /etc/my.cnf của RSS thứ 5 vào RSS mới được phát hành
    • Bạn chạy service mysql stopở RSS thứ 5
    • Bạn chạy service mysql stopở RSS mới

Bạn có thể sử dụng RSS # 5 để quay vòng máy chủ mới nhiều lần

Trên sidenote, vui lòng không sử dụng XEROUND cho WM hoặc DM vì chúng không hỗ trợ công cụ lưu trữ InnoDB hoặc BLACKHOLE.

Tôi hy vọng những ý tưởng này sẽ giúp.


1

Nếu bạn sử dụng Innodb, bạn nên xem xét nhiều thạc sĩ Mysql do Galera quản lý . Nó làm cho việc thiết lập mysql multi-master dễ dàng hơn và sẽ giúp bạn dễ dàng "bán" quy mô tự động hơn.

Nếu đây là một ứng dụng mà bạn hoặc công ty bạn đang viết, bạn có thể xem xét chuyển sang thiết kế phân vùng (phân vùng) cho ứng dụng. Nhưng shending có thể trở nên phức tạp. Đây là một liên kết để giúp bạn bắt đầu.

Tôi giả sử bạn đã "điều chỉnh" các tệp cấu hình mysql, như trong bộ nhớ phù hợp được phân bổ, v.v.


1

Đây có phải trong một giá mà bạn kiểm soát, hoặc nó trong đám mây? 12GB là một cơ sở dữ liệu rất nhỏ so với kích thước của các đĩa có sẵn. Đặt nó trên một mảng RAID1 hoặc RAID10 của SSD SLC nhỏ và độ trễ ghi của bạn sẽ biến mất.

Các dòng Intel 311 20GB SSD SLC ($ 120 mỗi) sẽ thực hiện công việc rực rỡ.

Nếu cơ sở dữ liệu lớn hơn, bạn có thể đạt được kết quả ngoạn mục tương tự bằng cách di chuyển cơ sở dữ liệu của mình sang mục tiêu iSCSI trên máy chủ ZFS SAN (được xây dựng trên phần cứng máy chủ hàng hóa sử dụng Nexenta, OpenIndiana, FreeNAS hoặc bất cứ thứ gì) và thiết lập một bản sao của SSD tương tự cho bộ đệm ghi ZIL của bạn. Trong tất cả các trường hợp ngoại trừ đặc biệt nhất, Gigabit Ethernet là quá đủ để di chuyển lưu lượng iSCSI cơ sở dữ liệu.

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.