Các giải pháp chia tỷ lệ cho MySQL (Nhân rộng, Phân cụm)

Tại công ty khởi nghiệp mà tôi đang làm việc, chúng tôi hiện đang xem xét các giải pháp mở rộng quy mô cho cơ sở dữ liệu của chúng tôi. Mọi thứ trở nên hơi khó hiểu (ít nhất là đối với tôi) với MySQL, có cụm MySQL , bản sao và sao chép cụm MySQL (từ phiên bản 5.1.6), là một phiên bản không đồng bộ của cụm MySQL. Hướng dẫn sử dụng MySQL giải thích một số khác biệt trong Câu hỏi thường gặp về cụm của nó , nhưng thật khó để xác định rõ khi nào sử dụng cái này hay cái kia.

Tôi sẽ đánh giá cao bất kỳ lời khuyên nào từ những người quen thuộc với sự khác biệt giữa các giải pháp đó và ưu và nhược điểm là gì, và khi nào bạn nên sử dụng từng giải pháp.

Tôi đã đọc RẤT NHIỀU về các tùy chọn có sẵn. Tôi cũng đã có trong tay phiên bản thứ 2 của MySQL hiệu suất cao, mà tôi thực sự khuyên bạn nên sử dụng.

Đây là những gì tôi đã cố gắng để ghép lại với nhau:

Phân cụm

Clustering theo nghĩa chung là phân phối tải trên nhiều máy chủ xuất hiện cho một ứng dụng bên ngoài như một máy chủ.

MySQL NDB Cluster

MySQL NDB Cluster là một công cụ lưu trữ phân tán, trong bộ nhớ, không chia sẻ gì với tính năng sao chép đồng bộ và phân vùng dữ liệu tự động (xin lỗi, tôi mượn nghĩa đen từ cuốn sách Hiệu suất cao, nhưng họ đặt nó rất đẹp ở đó). Nó có thể là một giải pháp hiệu suất cao cho một số ứng dụng, nhưng ứng dụng web nói chung không hoạt động tốt trên nó.

Vấn đề chính là ngoài các truy vấn rất đơn giản (chỉ chạm vào một bảng), cụm thường sẽ phải tìm kiếm dữ liệu trên một số nút, cho phép độ trễ mạng tăng lên và làm chậm đáng kể thời gian hoàn thành cho các truy vấn. Vì ứng dụng coi cụm như một máy tính nên nó không thể cho nó biết nút nào để tìm nạp dữ liệu từ đó.

Ngoài ra, yêu cầu trong bộ nhớ không khả thi đối với nhiều cơ sở dữ liệu lớn.

Sequoia liên tục

Đây là một giải pháp phân cụm khác cho MySQL, hoạt động như một phần mềm trung gian trên máy chủ MySQL. Nó cung cấp nhân rộng đồng bộ, cân bằng tải và chuyển đổi dự phòng. Nó cũng đảm bảo rằng các yêu cầu luôn nhận được dữ liệu từ bản sao mới nhất, tự động chọn một nút có dữ liệu mới.

Tôi đã đọc một số điều hay về nó, và nhìn chung thì nó có vẻ khá hứa hẹn.

Liên kết

Liên kết tương tự như phân cụm, vì vậy tôi cũng kéo nó ở đây. MySQL cung cấp liên kết thông qua công cụ lưu trữ liên kết. Tương tự như giải pháp cụm NDB, nó chỉ hoạt động tốt với các truy vấn đơn giản - nhưng thậm chí còn tệ hơn với giải pháp cụm phức tạp (vì độ trễ mạng cao hơn nhiều).

Nhân rộng và cân bằng tải

MySQL có khả năng tạo bản sao của cơ sở dữ liệu trên các máy chủ khác nhau. Điều này có thể được sử dụng cho nhiều việc - chia nhỏ tải giữa các máy chủ, sao lưu nóng, tạo máy chủ thử nghiệm và chuyển đổi dự phòng.

Thiết lập cơ bản của sao chép liên quan đến một máy chủ chủ xử lý chủ yếu là ghi và một hoặc nhiều nô lệ xử lý chỉ đọc. Một biến thể nâng cao hơn là cấu hình master-master , cho phép mở rộng quy mô ghi bằng cách có một số máy chủ ghi cùng một lúc.

Mỗi cấu hình đều có ưu và nhược điểm của nó, nhưng một vấn đề mà tất cả chúng đều chia sẻ là độ trễ sao chép - vì sao chép MySQL là không đồng bộ, không phải tất cả các nút đều có dữ liệu mới nhất mọi lúc. Điều này đòi hỏi ứng dụng phải nhận thức được bản sao và kết hợp các truy vấn nhận biết bản sao để hoạt động như mong đợi. Đối với một số ứng dụng, điều này có thể không thành vấn đề, nhưng nếu bạn luôn cần dữ liệu mới nhất, mọi thứ sẽ hơi phức tạp.

Việc sao chép yêu cầu một số cân bằng tải để phân chia tải giữa các nút. Điều này có thể đơn giản như một số sửa đổi đối với mã ứng dụng hoặc sử dụng các giải pháp phần cứng và phần mềm chuyên dụng.

Làm sắc nét và chia nhỏ

Sharding là cách tiếp cận thường được sử dụng để mở rộng các giải pháp cơ sở dữ liệu. Bạn chia dữ liệu thành các mảnh nhỏ hơn và rải chúng xung quanh các nút máy chủ khác nhau. Điều này đòi hỏi ứng dụng phải nhận thức được việc sửa đổi để lưu trữ dữ liệu hoạt động hiệu quả, vì nó cần biết nơi để tìm thông tin mà nó cần.

Có sẵn các khuôn khổ trừu tượng để giúp xử lý dữ liệu sharding, chẳng hạn như Hibernate Shard , một phần mở rộng cho Hibernate ORM (tiếc là trong Java. Tôi đang sử dụng PHP). HiveDB là một giải pháp khác cũng hỗ trợ tái cân bằng phân đoạn.

Khác

Nhân sư

Sphinx là một công cụ tìm kiếm toàn văn, có thể được sử dụng cho nhiều mục đích hơn là tìm kiếm thử nghiệm. Đối với nhiều truy vấn, nó nhanh hơn nhiều so với MySQL (đặc biệt là để phân nhóm và sắp xếp), đồng thời có thể truy vấn hệ thống từ xa song song và tổng hợp kết quả - điều này rất hữu ích khi sử dụng với sharding.

Nói chung, sphinx nên được sử dụng với các giải pháp mở rộng quy mô khác để có thêm phần cứng và cơ sở hạ tầng sẵn có. Nhược điểm là một lần nữa bạn cần mã ứng dụng để nhận biết về nhân sư để sử dụng nó một cách khôn ngoan.

Tóm lược

Các giải pháp chia tỷ lệ khác nhau tùy thuộc vào nhu cầu của ứng dụng cần nó. Đối với chúng tôi và đối với hầu hết các ứng dụng web, tôi tin rằng sao chép (có thể là đa chủ) là cách để đi với bộ cân bằng tải phân phối tải. Làm sắc nét các khu vực vấn đề cụ thể (các bảng lớn) cũng là điều cần thiết để có thể mở rộng quy mô theo chiều ngang.

Tôi cũng sẽ thử xem xét Continuent Sequoia và xem liệu nó có thực sự làm được những gì nó hứa hẹn không vì nó sẽ liên quan đến ít thay đổi nhất đối với mã ứng dụng.

Tuyên bố từ chối trách nhiệm: Tôi chưa sử dụng MySQL Cluster, vì vậy tôi chỉ đi từ những gì tôi đã nghe.

MySQL Cluster là một giải pháp HA (tính khả dụng cao). Nó nhanh chóng, bởi vì tất cả đều nằm trong bộ nhớ, nhưng điểm bán hàng thực sự là tính khả dụng. Không có một điểm thất bại nào. Mặt khác, với bản sao, nếu bản chính bị lỗi, bạn phải thực sự chuyển sang bản sao và có thể có một khoảng thời gian ngắn. (mặc dù giải pháp DRBD là một giải pháp thay thế khác có tính khả dụng cao)

Cluster yêu cầu toàn bộ cơ sở dữ liệu của bạn nằm gọn trong bộ nhớ. Điều đó có nghĩa là mỗi máy trong cụm cần có đủ bộ nhớ để lưu toàn bộ cơ sở dữ liệu. Vì vậy, đây không phải là một giải pháp khả thi cho các cơ sở dữ liệu rất lớn (hoặc ít nhất nó là một giải pháp rất tốn kém).

Tôi nghĩ rằng trừ khi HA là siêu quan trọng (đọc: có thể là không), nó sẽ phức tạp hơn (và tiền bạc) hơn giá trị của nó. Nhân rộng thường xuyên là cách tốt hơn để đi.

Chỉnh sửa: Tôi cũng quên đề cập rằng Cluster không cho phép khóa ngoài và quá trình quét phạm vi chậm hơn so với các công cụ khác. Đây là một liên kết nói về những hạn chế đã biết của MySQL Cluster

Có một số cuộc thảo luận tốt về cách những người duy trì drupal.org đã cấu trúc máy chủ cơ sở dữ liệu của họ:

• Blog của Dries Buytaert
• Blog WorkHabits

Cả hai đều có từ năm 2007, vì vậy hỗ trợ Clustering có thể mạnh hơn bây giờ, nhưng tại thời điểm đó họ đã chọn nhân rộng.

Điều thú vị về việc nhân rộng là nó rất dễ dàng. Chỉ cần thiết lập 2 hộp mysql, thay đổi serverID trên hộp thứ hai, sau đó trỏ hộp thứ hai vào hộp đầu tiên bằng lệnh thay đổi tổng thể.

Đây là cấu hình my.cnf nô lệ mẫu có liên quan

#
#       Log names
#

log-bin=binlog
relay-log=relaylog
log-error=errors.log

#
#       Log tuning
#

sync_binlog = 1
binlog_cache_size = 1M

#
#       Replication rules (what are we interested in listening for...)
#
#       In our replicants, we are interested in ANYTHING that isn't a permission table thing
#

replicate-ignore-db =      mysql
replicate-wild-ignore-table=mysql.%

#
#       Replication server ID
#

server-id      =        2

Vì vậy, hãy đảm bảo mỗi máy chủ nhận được một serverID tăng 1 (vì vậy máy chủ tiếp theo là máy chủ 3)

thiết lập tên người dùng và mật khẩu mà máy chủ có thể kết nối, Sau đó chạy thay đổi chủ thành MASTER_HOST = 'xxxx'; thay đổi cái thành MASTER_PASSWORD = "xxxxx";

và như thế.

cuối cùng, chạy "start slave;"

Lên đến nô lệ của bạn và bắt đầu sao chép. ngọt ngào hả!

Điều này giả sử bạn bắt đầu với 2 máy chủ trống. Sau đó, bạn có thể kết xuất db của mình vào máy chủ chính và khi nó tải ở đó, nó cũng sẽ tải trên máy chủ.

Bạn có thể kiểm tra trạng thái nô lệ bằng cách chạy:

hiển thị trạng thái nô lệ \ G

Hãy vui vẻ với nó .. quá dễ dàng ...

Trong khi thực hiện nghiên cứu Tính khả dụng cao, tôi đã tìm ra nhiều giải pháp và có lẽ trong trường hợp của chúng tôi là hệ thống ghi chuyên sâu hơn, tôi thấy cụm DRBD tốt hơn cụm NDB vì nó cung cấp nhiều giao dịch hơn mỗi giây.

Mysql Replication có thể cung cấp cho bạn một máy dự phòng có thể được sử dụng như máy đọc nô lệ hoặc có thể được sử dụng trong trường hợp khôi phục sau thảm họa.

Với các chế độ khác nhau về quản lý giao dịch do DRBD cung cấp, bạn có thể làm giảm hiệu suất do sao chép dữ liệu qua mạng ở cấp độ thiết bị. Đối với hệ thống đáng tin cậy không bị mất bất kỳ giao dịch nào trong trường hợp không thành công, hãy sử dụng chế độ C, còn chế độ B.

Tôi đã cố gắng liệt kê một số kiến ​​thức tôi đã thực hiện trong quá trình thiết lập cụm DRBD tại http://www.techiegyan.com/?p=132

Nó hoạt động thực sự tốt trên kết nối chuyên dụng để sao chép, tức là dành riêng các giao diện tốc độ cao riêng biệt trên cả hai máy chỉ để sao chép drbd. Heartbeat có thể điều khiển cụm độc đáo với tất cả các dịch vụ, tức là địa chỉ IP, phân vùng, drbd và mysql.

Tôi vẫn chưa khám phá ra cấu hình Master-Master trên DRBD. Sẽ cập nhật khi tôi nhận được thành công trong đó.

Cảm ơn.

theo quan điểm của tôi, sự nhầm lẫn ở đây chỉ đưa tôi trở lại Mnesia. Với cách xử lý chỉ mục phân mảnh, khai báo và thực dụng, tính minh bạch về vị trí của các Bản sao cơ sở dữ liệu, v.v.

Trong thiết lập của chúng tôi, Chúng tôi chạy cả MySQL Cluster và Mnesia. Dữ liệu của chúng tôi là theo mùa. Vì vậy, những gì xảy ra là sau một thời gian, chúng tôi giải phóng dữ liệu không còn được sử dụng nữa và ném nó vào cụm MYSQL. Điều này giữ cho sự mất trí nhớ của chúng tôi hiệu quả. Ngoài ra, chúng tôi có các ứng dụng được triển khai bằng các ngôn ngữ dòng chính (Python, Clojure, v.v.) sử dụng dữ liệu trực tiếp từ MySQL.

Tóm lại, chúng tôi chạy mnesia trên MySQL Cluster. MySQL Cluster có thể xử lý các tập dữ liệu lớn, một cơ sở dữ liệu có thể phát triển lên đến 50GB cộng thêm. Chúng tôi có mnesia cấp nguồn cho các ứng dụng Erlang / OTP . Java và PHP truy cập dữ liệu từ mnesia qua các API REST (gần đây là Thrift ) được điều chỉnh bằng cách sử dụng JSON và XML làm định dạng trao đổi.

Lớp truy cập dữ liệu có quyền truy cập trừu tượng vào dữ liệu trong Mnesia và dữ liệu đã vận chuyển cũ trong MySQL Cluster nếu cần. Về cơ bản, Mnesia ở đây để cung cấp năng lượng cho các ứng dụng Erlang / OTP. Lớp truy cập dữ liệu có thể truy cập cả dữ liệu trong mnesia và MySQL trong một API được trừu tượng hóa thay mặt cho tất cả các ứng dụng.

Điều tôi có thể nói ở đây là Mnesia là lựa chọn tốt nhất cho chúng tôi. Các bảng được phân mảnh và lập chỉ mục cao, các truy vấn hoạt động rất tốt và cơ sở dữ liệu được nhân rộng trên 2 vị trí, được kết nối qua một đường hầm.

Trước đó, chúng tôi sợ rằng mất trí nhớ có thể không xử lý được nhiều bản ghi nhất có thể do giới hạn về kích thước bảng. Nhưng chúng tôi thấy tuyên bố này sai. Với khả năng điều chỉnh tốt (phân mảnh), cơ sở dữ liệu mất trí nhớ của chúng tôi giữ trung bình khoảng 250 triệu bản ghi mỗi năm.

Chúng tôi đã được hưởng lợi từ cấu trúc dữ liệu phức tạp của Erlang và thực tế là Mnesia có thể nuốt chửng nó không thay đổi. Các ứng dụng Erlang / OTP hiệu quả nhất so với tất cả các ứng dụng khác bằng các ngôn ngữ kế thừa và với hệ thống của chúng tôi, chúng tôi đang có kế hoạch chuyển tất cả sang công nghệ Erlang / OTP. Từ Erlang, chúng tôi dường như truy cập dữ liệu từ MySQL Cluster và thực thi các truy vấn trên máy chủ của nó một cách vô cùng tuyệt vời.

Mnesia đã làm việc rất tốt cho chúng tôi.Mnesia đã thay đổi hoàn toàn cách chúng tôi nhìn vào cơ sở dữ liệu vì hiệu suất đáng kinh ngạc của nó. Lõi CPU máy chủ Solaris của chúng tôi luôn bận rộn với mức sử dụng trung bình khoảng 48% vào giờ cao điểm.

Tôi khuyên bạn nên kiểm tra mnesia và ai biết được, nó có thể đáp ứng một số nhu cầu phân phối hoặc nhân rộng của bạn.

Tôi chưa sử dụng chúng, nhưng từ các tài liệu, tôi muốn nói rằng sao chép là giải pháp ưu tiên nếu tải lớn nhất là đọc từ cơ sở dữ liệu.

Giới hạn "trong bộ nhớ" ngăn chúng tôi sử dụng MySQL cluster cho gần 50Gb dữ liệu của chúng tôi, vì vậy chúng tôi đang sử dụng DRBD cộng với linux Heartbeat .

Nó giống như một mảng đột kích giữa hai (hoặc nhiều) hộp giữ cho cơ sở dữ liệu / nhật ký / cấu hình được đồng bộ hóa (nhưng chỉ có một máy chủ có thể "hoạt động" tại một thời điểm). Chuyển đổi dự phòng là tự động, sử dụng cùng một địa chỉ IP và nhanh chóng khi khởi động lại mysql, vì vậy đó là một giải pháp tốt cho chúng tôi.

MySQL cluster là một yếu tố kỳ lạ và mỗi khi chúng tôi đánh giá nó đều hoạt động rất tệ hoặc không đáng tin cậy.

Việc thiết lập rất phức tạp (bạn cần ít nhất ba nút, có thể nhiều hơn). Ngoài ra, không có điều khoản nào về việc khách hàng bị lỗi, vì vậy bạn phải tự làm điều đó (Hoặc sử dụng thứ gì khác để hoạt động như một proxy, v.v.).

Nó cực kỳ thông minh, bởi vì nó thực hiện phân vùng băm tự động trên khóa chính cho phép bạn chia tỷ lệ các lần ghi và cũng bởi vì nó không có điểm nào bị lỗi.

Nhưng tôi thực sự nghĩ rằng nó phù hợp hơn với những trường hợp mục đích rất đặc biệt mà nó được thiết kế. Trong hầu hết các trường hợp, nó không thể thay thế một công cụ cơ sở dữ liệu khác (ví dụ: InnoDB) về hiệu suất hoặc tính năng.