Chúng tôi có thể làm gì trong Bản sao MySQL 5.0 để giải quyết các mối quan tâm về băng thông?

Tôi đang phát triển một ứng dụng để chạy trên PC khách (Win) được cấu hình với phiên bản máy chủ MySQL 5.1 sẽ hoạt động như một nô lệ chỉ đọc cho chủ từ xa. Trình điều khiển từ xa có hàng tá lược đồ, nhưng tôi chỉ cần một lược đồ cho mỗi máy khách nên tôi cung cấp cài đặt sao chép-do-db trong my.ini để chỉ sao chép lược đồ mà máy khách cần. Bản sao này hoạt động, nhưng khi khách hàng của chúng tôi đến các khu vực trên thế giới nơi truy cập internet chỉ khả dụng qua mạng không dây 3G, tính phí bằng cách sử dụng dữ liệu, họ nhanh chóng vượt quá giới hạn gói dữ liệu của họ và gặp phải các vấn đề đắt giá.

Theo tôi hiểu, MySQL ghi tất cả các giao dịch cho tất cả các lược đồ vào một tệp binlog duy nhất, điều đó có nghĩa là mỗi khách hàng phải tải xuống tất cả các giao dịch được thực hiện trên mỗi lược đồ trên bản gốc, sau đó tải xuống, áp dụng bộ lọc cơ sở dữ liệu cho mỗi lần sao chép- cài đặt do-db trong tệp my.ini của máy khách.

Để giảm thiểu sự không hiệu quả này, tôi đã sử dụng cài đặt Slave_compression_protatio = 1 , dường như giảm 50% dữ liệu được truyền, nhưng vẫn khiến khách hàng của chúng tôi nhanh chóng vượt quá giới hạn dữ liệu của họ để tăng hóa đơn 3G.

Tôi không thể tưởng tượng tôi là người duy nhất phải đối mặt với điều này, vì vậy tôi chắc chắn tôi sẽ nhận được rất nhiều câu trả lời về cách đạt được điều này bằng cách đặt x = y. Tuy nhiên, tôi không thể tìm thấy bất kỳ tài liệu nào về cài đặt như vậy, cũng không phải là cách tiếp cận được đề xuất.

Cho đến nay, đây là suy nghĩ của tôi về một giải pháp khả thi, vui lòng cung cấp phản hồi hoặc các tuyến đường thay thế:

1. Thiết lập nô lệ "proxy" cho mỗi lược đồ (trên hộp khác nhau hoặc cùng hộp với một phiên bản / cổng MySQL khác nhau)
2. Định cấu hình nô lệ proxy để sao chép-do-db chỉ một cơ sở dữ liệu mà khách hàng muốn sao chép.
3. Định cấu hình phiên bản MySQL của máy khách làm nô lệ cho nô lệ proxy thích hợp.

Điều này sẽ dẫn đến việc khách hàng chỉ kéo dữ liệu binlog cho lược đồ của họ. Nhược điểm (theo như tôi có thể nói) là nó làm tăng đáng kể sự phức tạp trong thiết lập của chúng tôi, có khả năng làm cho nó dễ vỡ hơn.

Suy nghĩ? Cách tiếp cận này thậm chí sẽ làm việc?

Lưu ý, chúng tôi đang chạy máy chủ MySQL 5.0 trên RedHat, nhưng chúng tôi có thể nâng cấp lên 5.5 nếu nó tạo ra giải pháp.

SUGGESTION # 1: Sử dụng Master phân phối

Một Master Master là một nô lệ mysql có bật log-bin, log-Slave-update được kích hoạt và chỉ chứa các bảng với Công cụ lưu trữ BLACKHOLE . Bạn có thể áp dụng sao chép-do-db cho Phân phối tổng thể và tạo nhật ký nhị phân tại Phân phối chính chỉ chứa (các) lược đồ DB mà bạn muốn binlogged. Bằng cách này, bạn giảm kích thước của các binlog đi từ Master Master phân phối.

Bạn có thể thiết lập một Master Master như sau:

1. mysqldump cơ sở dữ liệu của bạn bằng cách sử dụng tùy chọn --no-data để tạo kết xuất chỉ lược đồ.
2. Tải kết xuất chỉ lược đồ vào Phân phối tổng thể.
3. Chuyển đổi mọi bảng trong Công cụ phân phối sang công cụ lưu trữ BLACKHOLE.
4. Thiết lập sao chép vào Master Master từ một bản gốc với dữ liệu thực.
5. Thêm (các) tùy chọn sao chép-do-db vào /etc/my.cnf của Master Master.

Đối với các bước 2 và 3, bạn cũng có thể chỉnh sửa kết xuất chỉ lược đồ và thay thế Engine = MyISAM và Engine = InnoDB bằng Engine = BLACKHOLE và sau đó tải kết xuất chỉ lược đồ đã chỉnh sửa đó vào Master Master phân phối.

Chỉ trong bước 3, nếu bạn muốn kịch bản chuyển đổi tất cả các bảng MyISAM và InnoDB thành BLACKHOLE trong Master Master, hãy chạy truy vấn sau và xuất nó thành tệp văn bản:

mysql -h... -u... -p... -A --skip-column-names -e"SELECT CONCAT('ALTER TABLE ',table_schema,'.',table_name', ENGINE=BLACKHOLE;') BlackholeConversion FROM information_schema.tables WHERE table_schema NOT IN ('information_schema','mysql') AND engine <> 'BLACKHOLE'" > BlackholeMaker.sql

Một phần thưởng bổ sung cho kịch bản chuyển đổi bảng sang công cụ lưu trữ BLACKHOLE là các bảng công cụ lưu trữ MEMORY cũng được chuyển đổi. Trong khi bảng công cụ lưu trữ MEMOR không chiếm dung lượng đĩa để lưu trữ dữ liệu, nó sẽ chiếm bộ nhớ. Chuyển đổi bảng MEMOR thành BLACKHOLE sẽ giữ cho bộ nhớ trong Master Master không bị xáo trộn.

Miễn là bạn không gửi bất kỳ DDL nào vào Master Master phân phối, bạn có thể truyền bất kỳ DML nào (CHERTN, CẬP NHẬT, XÓA) mà bạn mong muốn trước khi cho phép khách hàng sao chép thông tin DB mà họ muốn.

Tôi đã viết một bài đăng trong một trang web StackExchange khác thảo luận về việc sử dụng Master Master .

SUGGESTION # 2: Sử dụng Nhật ký nhị phân nhỏ hơn và Nhật ký chuyển tiếp

Nếu bạn đặt max_binlog_size thành một cái gì đó nhỏ một cách lố bịch, thì binlog có thể được thu thập và vận chuyển trong các phần nhỏ hơn. Ngoài ra còn có một tùy chọn riêng để đặt kích thước của nhật ký chuyển tiếp, max_relay_log_size . Nếu max_relay_log_size = 0, nó sẽ mặc định thành bất cứ điều gì max_binlog_size được đặt thành.

SUGGESTION # 3: Sử dụng Sao chép bán đồng bộ (chỉ dành cho MySQL 5.5)

Thiết lập cơ sở dữ liệu chính của bạn và nhiều Master phân phối như MySQL 5.5. Cho phép nhân rộng bán đồng bộ để cơ sở dữ liệu chính có thể nhanh chóng gửi binlog đến Master Master phân phối. Nếu TẤT CẢ nô lệ của bạn là Master phân phối, bạn có thể không cần Sao chép bán đồng bộ hoặc MySQL 5.5. Nếu bất kỳ nô lệ nào, ngoài Phân phối chính, có dữ liệu thực để báo cáo, tính sẵn sàng cao, dự phòng thụ động hoặc mục đích sao lưu, thì hãy sử dụng MySQL 5.5 kết hợp với Sao chép bán đồng bộ.

SUGGESTION # 4: Sử dụng Nhật ký nhị phân dựa trên câu lệnh KHÔNG dựa trên hàng

Nếu một câu lệnh SQL cập nhật nhiều hàng trong một bảng, Nhật ký nhị phân dựa trên câu lệnh (SBBL) chỉ lưu trữ câu lệnh SQL. Câu lệnh SQL tương tự sử dụng Ghi nhật ký nhị phân dựa trên hàng (RBBL) sẽ ghi lại thực tế thay đổi hàng cho mỗi hàng. Điều này cho thấy rõ rằng việc truyền các câu lệnh SQL sẽ tiết kiệm không gian trên các bản ghi nhị phân thực hiện SBBL qua RBBL.

Một vấn đề khác là sử dụng RBBL kết hợp với sao chép-do-db trong đó tên bảng có cơ sở dữ liệu được chuẩn bị trước . Điều này không thể tốt cho một nô lệ, đặc biệt là đối với một Master Master phân phối. Do đó, đảm bảo rằng tất cả DML không có cơ sở dữ liệu aa và một khoảng thời gian trước bất kỳ tên bảng nào.

Max_binlog_size không liên quan - dữ liệu binlog được truyền đi liên tục.

Lưu ý về "Master Master phân phối" - đó là "một điểm thất bại duy nhất". Đó là, nếu nó chết, tất cả (các) nô lệ ngoài nó sẽ không nhận được dữ liệu và việc xây dựng lại rơle sẽ mất công.

SBR vs RBR - nó phụ thuộc vào truy vấn. Hoặc có thể tốt hơn hoặc xấu hơn so với người khác.

Đặt Master phân phối trên cùng một máy với Master thực hoặc trên máy "gần" Master. Sử dụng các cổng riêng biệt để giữ các trường hợp riêng biệt.