Việc cơ sở dữ liệu được phân phối trên nhiều vị trí địa lý là điều khá phổ biến. Một tình huống để thực hiện kiểu thiết lập này là phục hồi sau thảm họa, trong đó trung tâm dữ liệu dự phòng của bạn được đặt ở một vị trí riêng biệt với trung tâm dữ liệu chính của bạn. Nó cũng có thể được yêu cầu để cơ sở dữ liệu được đặt gần người dùng hơn.
Thách thức chính để đạt được thiết lập này là thiết kế cơ sở dữ liệu theo cách giảm nguy cơ xảy ra các vấn đề liên quan đến phân vùng mạng. Một trong những giải pháp có thể là sử dụng Galera Cluster thay vì sao chép không đồng bộ (hoặc bán đồng bộ) thông thường. Trong blog này, chúng tôi sẽ thảo luận về những ưu và nhược điểm của phương pháp này. Đây là phần đầu tiên trong một loạt hai blog. Trong phần thứ hai, chúng tôi sẽ thiết kế Cụm Galera được phân phối theo địa lý và xem cách ClusterControl có thể giúp chúng tôi triển khai môi trường như vậy.
Tại sao Cụm Galera Thay vì Sao chép Không đồng bộ cho Cụm được Phân phối theo Địa lý?
Chúng ta hãy xem xét những điểm khác biệt chính giữa Galera và sao chép thông thường. Việc sao chép thông thường cung cấp cho bạn chỉ một nút để ghi vào, điều này có nghĩa là mọi ghi từ trung tâm dữ liệu từ xa sẽ phải được gửi qua Mạng diện rộng (WAN) để đến được chủ. Điều đó cũng có nghĩa là tất cả các proxy nằm trong trung tâm dữ liệu từ xa sẽ phải có khả năng giám sát toàn bộ cấu trúc liên kết, mở rộng trên tất cả các trung tâm dữ liệu có liên quan vì chúng phải có khả năng cho biết nút nào hiện là nút chính.
Điều này dẫn đến số lượng các vấn đề. Đầu tiên, nhiều kết nối phải được thiết lập trên mạng WAN, điều này làm tăng thêm độ trễ và làm chậm bất kỳ quá trình kiểm tra proxy nào có thể đang chạy. Ngoài ra, điều này làm tăng thêm chi phí không cần thiết trên proxy và cơ sở dữ liệu. Hầu hết thời gian bạn chỉ quan tâm đến việc định tuyến lưu lượng truy cập đến các nút cơ sở dữ liệu cục bộ. Ngoại lệ duy nhất là chính và chỉ vì proxy này buộc phải theo dõi toàn bộ cơ sở hạ tầng thay vì chỉ một phần nằm trong trung tâm dữ liệu cục bộ. Tất nhiên, bạn có thể cố gắng khắc phục điều này bằng cách sử dụng proxy để chỉ định tuyến các CHỌN, trong khi sử dụng một số phương pháp khác (tên máy chủ dành riêng cho cấp chính do DNS quản lý) để trỏ ứng dụng đến chế độ chính, nhưng điều này làm tăng thêm mức độ phức tạp và các bộ phận chuyển động không cần thiết, có thể ảnh hưởng nghiêm trọng đến khả năng của bạn trong việc xử lý nhiều lỗi mạng và nút mà không làm mất tính nhất quán của dữ liệu.
Galera Cluster có thể hỗ trợ nhiều người viết. Độ trễ cũng là một yếu tố, vì tất cả các nút trong cụm Galera phải phối hợp và giao tiếp để xác nhận các bản ghi, nó thậm chí có thể là lý do khiến bạn có thể quyết định không sử dụng Galera khi độ trễ quá cao. Nó cũng là một vấn đề trong các cụm sao chép - trong các cụm sao chép, độ trễ chỉ ảnh hưởng đến việc ghi từ các trung tâm dữ liệu từ xa trong khi các kết nối từ trung tâm dữ liệu nơi đặt chính sẽ được hưởng lợi từ cam kết độ trễ thấp.
Trong MySQL Replication, bạn cũng phải tính đến trường hợp xấu nhất và đảm bảo rằng ứng dụng vẫn ổn khi ghi chậm. Master luôn có thể thay đổi và bạn không thể chắc chắn rằng bạn sẽ luôn ghi vào một nút cục bộ.
Một sự khác biệt khác giữa sao chép và Galera Cluster là việc xử lý độ trễ sao chép. Các cụm phân tán theo địa lý có thể bị ảnh hưởng nghiêm trọng bởi độ trễ:độ trễ, thông lượng hạn chế của kết nối WAN, tất cả những điều này sẽ ảnh hưởng đến khả năng theo kịp việc nhân rộng của một cụm sao chép. Xin lưu ý rằng sao chép tạo ra một cho tất cả lưu lượng truy cập.
Tất cả nô lệ phải nhận toàn bộ lưu lượng sao chép - lượng dữ liệu bạn có để gửi đến các nô lệ từ xa qua mạng WAN sẽ tăng lên với mọi nô lệ từ xa mà bạn thêm vào. Điều này có thể dễ dàng dẫn đến bão hòa liên kết WAN, đặc biệt nếu bạn thực hiện nhiều sửa đổi và liên kết WAN không có thông lượng tốt. Như bạn có thể thấy trên sơ đồ trên, với ba trung tâm dữ liệu và ba nút trong mỗi trung tâm, tổng thể phải gửi gấp 6 lần lưu lượng sao chép qua kết nối WAN.
Với cụm Galera, mọi thứ hơi khác một chút. Đối với người mới bắt đầu, Galera sử dụng điều khiển luồng để giữ cho các nút được đồng bộ hóa. Nếu một trong các nút bắt đầu tụt lại phía sau, nó có khả năng yêu cầu phần còn lại của cụm chạy chậm lại và để nó bắt kịp. Chắc chắn, điều này làm giảm hiệu suất của cả cụm, nhưng vẫn tốt hơn là khi bạn không thể thực sự sử dụng nô lệ cho các CHỌN vì chúng có xu hướng bị trễ theo thời gian - trong những trường hợp như vậy, kết quả bạn nhận được có thể lỗi thời và không chính xác.
Một tính năng khác của Galera Cluster, có thể cải thiện đáng kể hiệu suất của nó khi được sử dụng hơn WAN, là các phân đoạn. Theo mặc định, Galera sử dụng tất cả cho tất cả các giao tiếp và mọi tập ghi được gửi bởi nút tới tất cả các nút khác trong cụm. Hành vi này có thể được thay đổi bằng cách sử dụng các phân đoạn. Phân đoạn cho phép người dùng chia cụm Galera thành nhiều phần. Mỗi phân đoạn có thể chứa nhiều nút và nó chọn một trong số chúng làm nút chuyển tiếp. Nút như vậy nhận các bản ghi từ các phân đoạn khác và phân phối lại chúng trên các nút Galera cục bộ cho phân đoạn. Kết quả là, như bạn có thể thấy trên biểu đồ trên, có thể giảm lưu lượng sao chép qua WAN ba lần - chỉ có hai “bản sao” của luồng nhân bản đang được gửi qua WAN:một trên mỗi trung tâm dữ liệu so với một trên mỗi nô lệ trong MySQL Replication.
Xử lý Phân vùng Mạng Cụm Galera
Nơi Galera Cluster tỏa sáng là việc xử lý phân vùng mạng. Galera Cluster liên tục giám sát trạng thái của các nút trong cụm. Mọi nút đều cố gắng kết nối với các đồng nghiệp của nó và trao đổi trạng thái của cụm. Nếu không thể truy cập được tập hợp con của các nút, Galera sẽ cố gắng chuyển tiếp thông tin liên lạc để nếu có cách nào đó để tiếp cận các nút đó, chúng sẽ được tiếp cận.
Có thể thấy một ví dụ trên sơ đồ trên:DC 1 mất kết nối với DC2 nhưng DC2 và DC3 có thể kết nối. Trong trường hợp này, một trong các nút trong DC3 sẽ được sử dụng để chuyển tiếp dữ liệu từ DC1 sang DC2, đảm bảo rằng liên lạc nội bộ có thể được duy trì.
Galera Cluster có thể thực hiện các hành động dựa trên trạng thái của cụm. Nó thực hiện túc số - phần lớn các nút phải có sẵn để cụm có thể hoạt động. Nếu nút bị ngắt kết nối khỏi cụm và không thể kết nối với bất kỳ nút nào khác, nó sẽ ngừng hoạt động.
Như có thể thấy trên sơ đồ trên, có một phần mất kết nối mạng trong DC1 và nút bị ảnh hưởng bị xóa khỏi cụm, đảm bảo rằng ứng dụng sẽ không truy cập vào dữ liệu đã lỗi thời.
Điều này cũng đúng ở quy mô lớn hơn. DC1 đã bị cắt tất cả liên lạc của nó. Do đó, toàn bộ trung tâm dữ liệu đã bị xóa khỏi cụm và không nút nào của nó sẽ phục vụ lưu lượng truy cập. Phần còn lại của cụm duy trì đa số (6 trong số 9 nút có sẵn) và nó tự cấu hình lại để giữ kết nối giữa DC 2 và DC3. Trong sơ đồ trên, chúng tôi giả định rằng ghi chạm vào nút trong DC2 nhưng xin lưu ý rằng Galera có khả năng chạy với nhiều trình ghi.
MySQL Replication không có bất kỳ loại nhận thức cụm nào, khiến việc xử lý các vấn đề mạng trở nên khó khăn. Nó không thể tự tắt khi mất kết nối với các nút khác. Không có cách nào dễ dàng để ngăn chặn máy chủ cũ hiển thị sau khi chia tách mạng.
Khả năng duy nhất được giới hạn ở lớp proxy hoặc thậm chí cao hơn. Bạn phải thiết kế một hệ thống, hệ thống này sẽ cố gắng hiểu trạng thái của cụm và thực hiện các hành động cần thiết. Một cách khả thi là sử dụng các công cụ nhận biết cụm như Orchestrator và sau đó chạy các tập lệnh sẽ kiểm tra trạng thái của cụm Orchestrator RAFT và dựa trên trạng thái này, thực hiện các hành động cần thiết trên lớp cơ sở dữ liệu. Điều này là không lý tưởng vì bất kỳ hành động nào được thực hiện trên lớp cao hơn cơ sở dữ liệu, sẽ làm tăng thêm độ trễ:có thể xảy ra sự cố và tính nhất quán của dữ liệu bị xâm phạm trước khi có thể thực hiện hành động chính xác. Mặt khác, Galera thực hiện các hành động ở cấp độ cơ sở dữ liệu, đảm bảo phản ứng nhanh nhất có thể.
