Bạn đang muốn bắt đầu với cơ sở dữ liệu nguồn mở phổ biến nhất trên thế giới và tự hỏi bạn nên thiết lập máy chủ MySQL của mình như thế nào? Vì vậy, nhiều người mặc định là Amazon RDS, khi MySQL hoạt động đặc biệt tốt trên Azure Cloud. Mặc dù Microsoft Azure cung cấp một giải pháp được quản lý, Cơ sở dữ liệu Azure, nhưng giải pháp này có một số hạn chế chính mà bạn nên biết trước khi di chuyển các triển khai MySQL của mình. Trong bài đăng này, chúng tôi phác thảo cách tốt nhất để lưu trữ MySQL trên Azure, bao gồm các giải pháp được quản lý, loại phiên bản, sao chép tính khả dụng cao, sao lưu và các loại đĩa để sử dụng để tối ưu hóa hiệu suất cơ sở dữ liệu đám mây của bạn.
MySQL DBaaS so với MySQL tự quản lý
Điều đầu tiên cần xem xét khi cân nhắc giữa tính năng tự quản lý và giải pháp Cơ sở dữ liệu MySQL như một Dịch vụ (DBaaS) là tài nguyên nội bộ bạn có sẵn. Nếu bạn đang đọc bài viết này, bạn có thể đã biết tầm quan trọng của các nhiệm vụ hoạt động liên quan đến việc duy trì triển khai sản xuất, nhưng để tóm tắt nhanh, có cấu hình cấp phép, hủy cấp phép, cấu hình master-slave, sao lưu, mở rộng, nâng cấp, xoay vòng nhật ký, vá hệ điều hành và giám sát để đặt tên cho một số.
Một chuyên gia MySQL nội bộ hoặc một nhóm DBA tùy thuộc vào quy mô ứng dụng của bạn, chắc chắn có thể xử lý những vấn đề này với tổ chức của bạn cho bạn, nhưng câu hỏi sẽ trở thành nơi bạn muốn nỗ lực của nhóm tập trung vào đâu . Nhiều người quyết định chuyển sang MySQL DBaaS để tự động hóa các tác vụ tốn thời gian này để họ có thể tập trung hơn vào việc phát triển và tối ưu hóa cơ sở dữ liệu ứng dụng của họ. Một ví dụ điển hình là phân tích truy vấn chậm. Mặc dù hầu hết mọi DBaaS đều cung cấp công cụ MySQL Slow Query Analyzer để giúp xác định các truy vấn rắc rối, nhưng tác vụ này vẫn đòi hỏi kỹ năng và trực giác của con người để xác định cách tối ưu hóa các truy vấn đó ảnh hưởng đến hiệu suất ứng dụng của họ.
Cho dù bạn là một công ty khởi nghiệp hay một doanh nghiệp 500, bạn sẽ thấy nhiều tổ chức chọn sử dụng DBaaS để tối ưu hóa thời gian DBA của họ, trong khi các loại hình và quy mô kinh doanh giống nhau cũng chọn gắn bó với tự quản nội bộ. Đối với nhiều doanh nghiệp doanh nghiệp, quyết định chủ yếu nằm ở việc tùy chỉnh và kiểm soát. Đây là lý do tại sao chúng tôi đề phòng việc đặt mặc định cho Cơ sở dữ liệu Azure hoặc đối thủ cạnh tranh của AWS, Amazon RDS, vì họ không cho phép bạn giữ quyền truy cập siêu người dùng MySQL hoặc thậm chí quyền truy cập SSH vào máy của bạn. Ngoài ra, khả năng tùy chỉnh thiết lập triển khai của bạn rất hạn chế, chẳng hạn như loại phiên bản, RAM, kích thước đĩa hoặc IOPS mà bạn có thể sử dụng. Bạn sẽ tìm hiểu thêm về các loại phiên bản và đĩa tốt nhất để sử dụng bên dưới và bạn có thể kiểm tra So sánh nhà cung cấp MySQL này để xem những ưu điểm và hạn chế của bốn giải pháp MySQL được quản lý hàng đầu, ScaleGrid, Compose, Azure Database và Amazon RDS.
Triển khai tính khả dụng cao
Nếu bạn đang triển khai trong phiên bản sản xuất, bạn phải luôn thiết lập MySQL dưới dạng triển khai chính-tớ. Các triển khai độc lập là một nút duy nhất mà không có bất kỳ bản sao nào và thực sự chỉ nên được sử dụng cho các môi trường phát triển hoặc thử nghiệm. Với việc triển khai master-slave, bạn có thể định cấu hình tính khả dụng cao, vì vậy nếu một trong các nút của bạn gặp sự cố, bạn có thể chuyển đổi dự phòng thành slave mà không có thời gian chết. Điều này thường được thiết lập dưới dạng 3 nút chủ-tớ-tớ hoặc 2 + 1 nút chủ-tớ-đại biểu. Ưu điểm của việc sử dụng túc số là một giải pháp thay thế có chi phí thấp hơn, nhưng nhược điểm là bạn chỉ có 2 nút mang dữ liệu vì nút còn lại hoạt động như một nút đại biểu để xác định quá trình chuyển đổi dự phòng tốt nhất. Nếu ứng dụng của bạn có thể đọc từ máy chủ, thì bạn cần thực hiện điều chỉnh tỷ lệ đọc để chúng trả về cùng một dữ liệu từ khối lượng cụm với độ trễ tối thiểu.
Cách tốt nhất để lưu trữ MySQL trên Azure CloudNhấp vào Tweet
Khi sử dụng cấu hình MySQL master-slave, chúng tôi khuyên bạn nên thiết lập sao chép bán đồng bộ để cải thiện tính toàn vẹn dữ liệu của bạn với dự phòng dữ liệu. Điều này đảm bảo rằng khi một cam kết trả về thành công, dữ liệu tồn tại cả trong master và slave, vì vậy trong trường hợp trung tâm dữ liệu gặp sự cố, MySQL master của bạn có thể chuyển đổi dự phòng thành slave mà không bị mất dữ liệu. Bạn có thể thực hiện việc này với sao chép không đồng bộ hoặc bán đồng bộ và tìm hiểu thêm về nó trong Bài đăng trên blog về tính khả dụng cao của MySQL được giải thích - Phần II của chúng tôi.
Vì vậy, làm cách nào để định cấu hình tính khả dụng cao cho MySQL trên Azure? Chúng tôi cần phân phối các phiên bản nô lệ của mình trên các vùng khả dụng Azure khác nhau (AZ). Vì vậy, chúng tôi muốn đảm bảo rằng chúng tôi chọn một vùng Azure có ít nhất 3 AZ, đặt mỗi trường hợp vào một AZ khác nhau. Chúng tôi làm điều này vì sự đảm bảo về tính khả dụng trên toàn bộ AZ, vì vậy nếu 1 khu vực gặp sự cố, cơ sở dữ liệu ứng dụng của bạn vẫn có thể trực tuyến thông qua 2 AZ khác. Các khu vực sẵn có là khá mới đối với Azure, vì vậy nếu bạn đang làm việc ở một khu vực không cung cấp AZ, bạn có tùy chọn sử dụng các nhóm khả dụng. Những thứ này yếu hơn AZ một chút, nhưng hãy đảm bảo rằng bạn được triển khai trên các miền và giá đỡ khác nhau để bảo vệ bạn trước khả năng ngừng hoạt động. Ngoài ra còn có tùy chọn để triển khai trên các khu vực, nhưng đây là cách thiết lập phức tạp hơn, vì vậy chúng tôi khuyên bạn nên liên hệ để thảo luận trước khi triển khai.
Mạng ảo Azure
Cách tốt nhất để bảo vệ cơ sở dữ liệu của bạn khỏi Internet là triển khai nó trong một mạng con riêng tư để đảm bảo nó không bị lộ. Azure giúp dễ dàng thiết lập điều này thông qua việc sử dụng Mạng ảo (VNET) có thể được cấu hình cho các máy chủ MySQL của bạn. Với Azure VNET dành cho MySQL, bạn có thể thiết lập thông tin liên lạc an toàn giữa các máy chủ, internet và thậm chí cả mạng đám mây riêng tại cơ sở của bạn. Chúng thường được định cấu hình để giao tiếp trên một mạng duy nhất, nhưng nếu bạn cần kết nối nhiều vùng, bạn có thể tạo nhiều VNET để giao tiếp thông qua Mạng ngang hàng ảo.
Ngoài ra, bạn có thể quản lý kiểm soát truy cập MySQL của mình thông qua các quy tắc Nhóm bảo mật mạng (NSG) mà không cần phải xử lý danh sách IP cho phép. Tính năng này không khả dụng thông qua Cơ sở dữ liệu Azure dành cho MySQL, nhưng cả VNET và NSG đều có thể được định cấu hình thông qua các gói MySQL Mang đến đám mây riêng của bạn (BYOC) trên Azure, nơi bạn có thể lưu trữ các cụm của mình thông qua tài khoản đám mây của riêng bạn.
Loại phiên bản Azure
Một khía cạnh quan trọng khác cần xem xét là hiệu suất của các phiên bản MySQL của bạn trên đám mây công cộng. Đám mây Azure cung cấp nhiều loại phiên bản có thể được sử dụng cho lưu trữ MySQL của bạn, bao gồm Es2 v3, Ds2, v2 và Ls4.
Chúng tôi khuyên bạn nên bắt đầu với loại phiên bản được tối ưu hóa bộ nhớ vì cơ sở dữ liệu yêu cầu nhiều RAM và đang tìm kiếm tốc độ đĩa nhanh nhất có thể để có hiệu suất tốt nhất. Dòng Es2 thường là một điểm khởi đầu tốt cho hầu hết các khối lượng công việc MySQL của ứng dụng. Từ đó, bạn có thể thực hiện một số kiểm tra hiệu suất để xem liệu bạn có yêu cầu nhiều CPU hơn hay không, trong trường hợp đó, các loại phiên bản cân bằng hoặc các loại phiên bản chuyên sâu về CPU có thể phục vụ tốt hơn nhu cầu MySQL của bạn, chẳng hạn như các loại phiên bản Dv3. Các bài kiểm tra hiệu suất của bạn cũng có thể cho thấy rằng bạn cần thêm I / O (đầu vào / đầu ra), bạn có thể chuyển sang loại phiên bản chuyên sâu về đĩa.
Nếu bạn định tận dụng Azure làm nhà cung cấp dịch vụ đám mây MySQL của mình trong 1-3 năm tới và duy trì cấu hình triển khai khá nhất quán, bạn cũng có thể xem xét các phiên bản dành riêng. Về cơ bản, đây là các phiên bản trả trước cho phép bạn tiết kiệm đáng kể chi phí cho dịch vụ lưu trữ MySQL của mình. Trung bình, bạn có thể tiết kiệm khoảng 20% đến 30% cho các phiên bản đặt trước một năm và 40% đến 50% cho các phiên bản đặt trước 3 năm.
Các loại đĩa Azure
Quyết định đầu tiên bạn cần thực hiện khi chọn loại đĩa Azure cho các triển khai MySQL của mình là có nên sử dụng đĩa được quản lý hay không. Các đĩa không được quản lý là các đĩa kế thừa mà Azure cung cấp, nơi bạn phải thiết lập tài khoản lưu trữ, ánh xạ đĩa của bạn với tài khoản lưu trữ và giám sát việc sử dụng IOPS và các giới hạn cho tài khoản lưu trữ đó. Chúng tôi thực sự khuyên bạn nên sử dụng đĩa được quản lý và nếu bạn vẫn đang triển khai với đĩa không được quản lý, bạn nên cân nhắc chuyển sang đĩa được quản lý.
Môi trường thử nghiệm / phát triển MySQL:Đĩa tiêu chuẩn
Có nhiều loại đĩa được quản lý thông qua Azure, mặc định là đĩa tiêu chuẩn. Các đĩa tiêu chuẩn có thể hỗ trợ lên đến 500 IOPS (hoạt động đầu vào / đầu ra mỗi giây) và rất tốt cho các hoạt động phát triển và thử nghiệm vì chúng có thể được thay đổi kích thước động, nhưng không nên được sử dụng để triển khai sản xuất MySQL.
Triển khai sản xuất MySQL:Đĩa cao cấp
Đối với các máy chủ sản xuất MySQL của bạn, chúng tôi thực sự khuyên bạn nên sử dụng đĩa cao cấp Azure. Có rất nhiều loại đĩa cao cấp mà bạn có thể chọn. Đối với mỗi đĩa cao cấp, bạn có thể chọn kích thước tốt nhất và mỗi kích thước đi kèm với các IOPS được cung cấp khác nhau để bạn có thể chọn loại phù hợp nhất với nhu cầu ứng dụng của mình.
Triển khai sản xuất MySQL:SSD cục bộ
Azure Local SSD là giải pháp thay thế hiệu suất cao cho các đĩa cao cấp, thường phù hợp nhất cho các cụm lớn. SSD cục bộ cung cấp hiệu suất I / O cao hơn nhiều và thông lượng tốt nhất trong Azure. Tuy nhiên, chúng có một nhược điểm là chúng là đĩa tạm thời, không phải là nơi lưu trữ vĩnh viễn, vì vậy nếu bạn dừng phiên bản, dữ liệu sẽ biến mất. Chúng tôi khuyên bạn nên sử dụng dòng Ls v2 có tốc độ rất nhanh, nhưng hãy lưu ý rằng CPU thực sự yếu có thể gây ra tắc nghẽn máy.
Bản sao lưu MySQL trên Azure
Cách tốt nhất để sao lưu dữ liệu MySQL của bạn trên Azure là sử dụng ảnh chụp nhanh đĩa được quản lý. Ảnh chụp nhanh là phiên bản chỉ đọc trong thời gian của đĩa. Các bản sao lưu này có thể được đọc, sao chép hoặc xóa, nhưng lưu ý rằng chúng không thể sửa đổi. Bạn nên sao lưu toàn bộ để tất cả cơ sở dữ liệu, người dùng và cài đặt của bạn được sao lưu trên phiên bản này trong trường hợp bạn cần khôi phục cơ sở dữ liệu MySQL. Bạn cũng nên mã hóa ảnh chụp nhanh bản sao lưu của mình để bản sao lưu chỉ có thể được khôi phục trên máy mà bản sao lưu đã được thực hiện.
Các bản sao lưu MySQL của bạn sẽ dẫn đến tính phí lưu trữ dữ liệu Azure bổ sung, trừ khi bạn đang tận dụng giải pháp MySQL trên Azure trọn gói như các gói Lưu trữ Chuyên dụng của chúng tôi tại ScaleGrid. Để kiểm soát chi phí, bạn nên tự động hóa các bản sao lưu của mình thông qua một lịch trình có thể tùy chỉnh cho phép bạn định cấu hình tần suất sao lưu, số lượng bản sao lưu tối đa cần giữ lại và mục tiêu sao lưu của bạn. Tất nhiên, điều này cũng giúp bạn đảm bảo dữ liệu MySQL của mình được sao lưu thường xuyên trong trường hợp mất mát dữ liệu trong quá trình triển khai sản xuất của bạn để bạn có thể nhanh chóng khôi phục bằng bản sao lưu gần đây.
Nếu bạn có bất kỳ câu hỏi nào về cách tốt nhất để lưu trữ MySQL trên Azure, hãy để lại bình luận cho chúng tôi bên dưới hoặc liên hệ với chúng tôi tại support @ scalegrid. io. Bạn cũng có thể bắt đầu dùng thử miễn phí 30 ngày để khám phá những lợi thế của việc tận dụng dịch vụ MySQL được quản lý đầy đủ để cải thiện hiệu suất triển khai của bạn.
