Cụm người theo dõi là một tính năng ScaleGrid cho phép bạn đồng bộ hóa hai hệ thống cơ sở dữ liệu độc lập (cùng loại). Không giống như sao chép hoặc sao chép, điều này cho phép bạn duy trì một bản sao hoạt động, kịp thời của dữ liệu sản xuất của bạn. Cụm bổ sung này, được gọi là cụm theo dõi, có thể được tận dụng cho nhiều trường hợp sử dụng, bao gồm để phân tích, tối ưu hóa và kiểm tra hiệu suất ứng dụng của bạn cho MongoDB, MySQL và PostgreSQL. Trong bài đăng blog này, chúng tôi sẽ đề cập đến ba trường hợp hàng đầu để tận dụng các nhóm người theo dõi cho ứng dụng của bạn.
Các cụm người theo dõi khác nhau như thế nào so với việc nhân rộng?
Không giống như bản sao tĩnh, dữ liệu này nhập theo lịch trình đã định để cụm người theo dõi của bạn luôn đồng bộ với cụm sản xuất của bạn. Dưới đây là một số cách quan trọng mà nó khác với sao chép:
- Bạn có thể kiểm soát tần suất hệ thống đích đồng bộ hóa từ nguồn - mỗi tuần một lần, mỗi ngày một lần hoặc thậm chí ít thường xuyên hơn. Điều này giúp giảm tải cho hệ thống nguồn.
- Vì chúng là hai hệ thống độc lập, bạn có thể linh hoạt hơn nhiều đối với dữ liệu được đồng bộ hóa. Bạn có thể có các thông tin đăng nhập người dùng khác nhau và thậm chí xóa một số dữ liệu khỏi đích dựa trên các yêu cầu bảo mật (lưu ý:Điều này yêu cầu tập lệnh phía người dùng - đây không phải là tính năng được tích hợp sẵn của các nhóm người theo dõi).
- Hệ thống "follower" có thể ghi được, vì vậy bạn có thể sử dụng nó làm môi trường tổ chức để kiểm tra các thay đổi ứng dụng của mình. Đây không phải là điều bạn có thể làm trên một nút bản sao.
Lưu ý:ScaleGrid triển khai các cụm người theo dõi bằng cách sử dụng ảnh chụp nhanh bộ nhớ. Nó không có sẵn cho các dịch vụ cơ sở dữ liệu trong bộ nhớ của chúng tôi như lưu trữ cho Redis ™ *.
1. Thiết lập thử nghiệm / nhà phát triển cơ sở dữ liệu
Tất cả chúng ta đều đã ở đó - một đoạn mã được cho là đã được thử nghiệm tốt được triển khai trong quá trình sản xuất, và sau đó mọi thứ sẽ tan vỡ. Quy trình sản xuất không thành công hoặc quá chậm về cơ bản là không thể sử dụng được. Các kỹ sư được đánh thức khỏi giường của họ để bắt đầu hoạt động chữa cháy toàn diện. Nhiều đêm mất ngủ sau đó, nguyên nhân sâu xa đáng sợ đó xuất hiện.
Ứng dụng hoạt động khác nhau trên các thiết lập sản xuất và kỹ thuật.
Nói cách khác, chúng tôi đã thử nghiệm nó trên “dữ liệu thử nghiệm”. Hóa ra không giống như dữ liệu sản xuất. Tất cả.
Cách rõ ràng để tránh tình trạng này là chạy thử nghiệm trên dữ liệu sản xuất của bạn. Tất nhiên, không phải sản xuất thực tế - điều đó sẽ dẫn đến thảm họa. Trên một bản sao của dữ liệu sản xuất. Mặc dù các mối quan tâm xung quanh quyền riêng tư và bảo mật dữ liệu khiến điều này không thể thực hiện được trong nhiều trường hợp, nhưng các yêu cầu về quyền riêng tư cho phép, thì đây là giải pháp tốt nhất. Chúng tôi không còn cần phải dựa vào các kỹ sư tạo ra các tập dữ liệu thích hợp - nếu nó chuyển sang dữ liệu thử nghiệm, nó sẽ chuyển sang dữ liệu sản xuất.
Tức là cho đến khi dữ liệu thử nghiệm không đồng bộ với quá trình sản xuất đến mức nó không còn là một ước tính tốt nữa. Và chúng ta trở lại hình vuông.
Đây là nơi các nhóm người theo dõi xuất hiện.
Bằng cách sử dụng các cụm người theo dõi, bạn có thể định kỳ nhập dữ liệu từ cơ sở dữ liệu sản xuất của mình vào cơ sở dữ liệu dev / test. Và vì toàn bộ quá trình nhập được thực hiện bằng cách sử dụng ảnh chụp nhanh bộ nhớ, thay vì kết xuất hợp lý, nên quá trình này gần như ngay lập tức. Bạn có thể lập lịch nhập mỗi 24 giờ một lần, mỗi tuần một lần hoặc bất kỳ tần suất nào phù hợp với tình huống cụ thể của bạn.
Với các cụm phát triển và QA của bạn được thiết lập để tuân theo cụm sản xuất, bạn có thể yên tâm. Nếu ứng dụng của bạn vượt qua tập dữ liệu thử nghiệm, nó chắc chắn phù hợp để triển khai trong sản xuất!
2. Phân tích dữ liệu
Nếu bạn đã từng làm việc với tư cách là DBA, bạn có thể đã trò chuyện với nhóm của mình về việc hiệu suất hệ thống bị chậm lại một cách "bí ẩn" tại một số thời điểm nhất định. Trong hầu hết các trường hợp, thủ phạm hóa ra là một công việc phân tích đang truy cập vào hàng tấn dữ liệu và kết thúc là làm chậm toàn bộ hệ thống.
Với tư cách là nhà cung cấp DBaaS, chúng tôi đã có cuộc trò chuyện này nhiều lần với khách hàng của mình. Dưới đây là hai tùy chọn chúng tôi thường đề xuất:
- Nếu công việc phân tích đang chạy trên máy chủ chính / chính, hãy chuyển nó sang máy chủ phụ / bản sao.
- Nếu công việc phân tích đã chạy trên một nút phụ và việc giảm hiệu suất là không thể chấp nhận được, chúng tôi khuyên bạn nên chuyển công việc sang một cụm phân tích chuyên dụng.
Sử dụng tính năng cụm người theo dõi của chúng tôi, rất dễ dàng để giữ cho nhóm phân tích luôn cập nhật dữ liệu sản xuất thực tế. Bạn có thể tạo lịch trình theo dõi để đồng bộ hóa dữ liệu mới nhất từ quá trình sản xuất ngay trước khi công việc phân tích của bạn bắt đầu.
Phần hay nhất? Đồng bộ hóa người theo dõi không thực hiện bất kỳ hoạt động cấp cơ sở dữ liệu nào - nó chỉ khôi phục ảnh chụp nhanh mới nhất! Vì vậy, không có tác động nào đến cụm sản xuất của bạn.
3. Báo cáo
Một trường hợp sử dụng phổ biến khác mà khách hàng của chúng tôi sử dụng tính năng cụm người theo dõi là để tạo báo cáo. Các quy trình báo cáo thường chạy không thường xuyên, nhưng truy cập vào số lượng lớn dữ liệu và chiếm hầu hết các tài nguyên của cụm cơ sở dữ liệu. Khi sự suy giảm hiệu suất là không thể chấp nhận được, chúng tôi khuyên khách hàng của chúng tôi nên chuyển khối lượng công việc báo cáo sang một cụm mới.
Vì hoạt động báo cáo không thường xuyên, nhiều khách hàng của chúng tôi thích sử dụng tính năng tạm dừng / tiếp tục của chúng tôi để ‘tạm dừng’ các cụm báo cáo khi chúng không được sử dụng. Điều này giúp tiết kiệm hàng loạt chi phí cơ sở hạ tầng. Thông thường, các cụm báo cáo cũng “nhỏ hơn” nhiều (CPU / RAM ít hơn), để giúp giảm chi phí.
Sau khi bạn đã tạo nhóm người theo dõi từ giao diện người dùng của chúng tôi, bạn có thể sử dụng quy trình làm việc này để tự động hóa quy trình báo cáo của mình:
- Sử dụng API sơ yếu lý lịch của chúng tôi để tiếp tục nhóm.
- Chờ cho đến khi cụm ở trạng thái chạy trở lại (bạn có thể sử dụng API trạng thái nhận của mình cho mục đích này).
- Kích hoạt sao lưu trên cụm sản xuất của bạn, nếu được yêu cầu (thông thường, nếu các bản sao lưu thường xuyên được lên lịch trong quá trình sản xuất của bạn, bạn có thể bỏ qua bước này. Tuy nhiên, nếu bạn muốn báo cáo của mình chạy trên dữ liệu mới nhất, thì điều này là cần thiết).
- Chờ quá trình sao lưu hoàn tất.
- Kích hoạt công việc đồng bộ hóa trên người theo dõi - điều này sẽ tìm thấy ảnh chụp nhanh mới nhất trên cụm nguồn và khôi phục về đích.
- Chờ công việc đồng bộ hóa hoàn tất.
- Chạy các tác vụ báo cáo của bạn.
- Sử dụng API tạm dừng của chúng tôi để tạm dừng cụm cho đến công việc báo cáo tiếp theo của bạn!
Bạn có nghĩ rằng các cụm người theo dõi phù hợp với trường hợp người dùng cụ thể của bạn không? Bạn có thể tìm hiểu tất cả về cách triển khai và quản lý các cụm người theo dõi cho MongoDB, MySQL và PostgreSQL trong tài liệu trợ giúp của chúng tôi!
Nếu bạn không chắc liệu các cụm người theo dõi có phải là giải pháp chính xác cho trường hợp sử dụng của bạn hay không, hãy để lại nhận xét hoặc liên hệ với chúng tôi tại [email protected] - chúng tôi rất vui khi thảo luận về tính năng nào phù hợp nhất với yêu cầu của bạn.
