Di chuyển cơ sở dữ liệu của bạn sang một trung tâm dữ liệu mới có thể là một quá trình rủi ro cao và tốn thời gian. Cơ sở dữ liệu chứa trạng thái và có thể khó di chuyển hơn nhiều so với máy chủ web, hàng đợi hoặc máy chủ bộ nhớ cache.
Trong bài đăng trên blog này, chúng tôi sẽ cung cấp cho bạn một số mẹo về cách di chuyển dữ liệu của bạn từ nhà cung cấp dịch vụ này sang nhà cung cấp dịch vụ khác. Quá trình này hơi giống với bài đăng trước của chúng tôi về cách nâng cấp MySQL, nhưng có một vài điểm khác biệt quan trọng.
Bản sao MySQL hay Cụm Galera?
Việc chuyển sang nhà cung cấp dịch vụ khác (ví dụ:chuyển từ AWS sang Rackspace hoặc từ máy chủ được định vị sang đám mây) thường có nghĩa là một người sẽ xây dựng một cơ sở hạ tầng hoàn toàn mới song song, đồng bộ hóa nó với cơ sở hạ tầng cũ và sau đó chuyển sang nó. Để kết nối và đồng bộ hóa chúng, bạn có thể muốn sử dụng tính năng sao chép MySQL.
Nếu bạn đang sử dụng Galera Cluster, việc di chuyển các nút Galera của bạn sang một trung tâm dữ liệu khác có thể dễ dàng hơn. Tuy nhiên, lưu ý rằng toàn bộ cụm vẫn phải được coi như một cơ sở dữ liệu duy nhất. Điều này có nghĩa là trang web sản xuất của bạn có thể phải chịu thêm độ trễ khi kéo dài Cụm Galera qua mạng WAN. Có thể giảm thiểu tác động bằng cách điều chỉnh cài đặt mạng trong cả Galera và hệ điều hành, nhưng không thể loại bỏ hoàn toàn tác động. Thay vào đó, bạn cũng có thể thiết lập Bản sao MySQL không đồng bộ giữa cụm cũ và cụm mới, nếu tác động của độ trễ là không thể chấp nhận được.
Thiết lập kết nối an toàn
MySQL Replication không được mã hóa và do đó không an toàn khi sử dụng qua mạng WAN. Có nhiều cách để đảm bảo rằng dữ liệu của bạn sẽ được chuyển một cách an toàn. Bạn nên điều tra xem liệu có thể thiết lập kết nối VPN giữa cơ sở hạ tầng hiện tại và nhà cung cấp dịch vụ mới của bạn hay không. Hầu hết các nhà cung cấp (ví dụ như cả Rackspace và AWS) đều cung cấp dịch vụ như vậy - bạn có thể kết nối phần "có mây" với trung tâm dữ liệu hiện có của mình thông qua mạng riêng ảo.
Nếu vì lý do nào đó, giải pháp này không phù hợp với bạn (có thể nó yêu cầu phần cứng mà bạn không có quyền truy cập), bạn có thể sử dụng phần mềm để xây dựng VPN - một trong số chúng sẽ là OpenVPN. Công cụ này sẽ hoạt động hiệu quả để thiết lập các kết nối được mã hóa giữa các trung tâm dữ liệu của bạn.
Nếu OpenVPN không phải là một tùy chọn, có nhiều cách hơn để đảm bảo sao chép sẽ được mã hóa. Ví dụ:bạn có thể sử dụng SSH để tạo đường hầm giữa các trung tâm dữ liệu cũ và mới, đồng thời chuyển tiếp cổng 3306 từ máy chủ MySQL hiện tại (hoặc chính) đến nút mới. Nó có thể được thực hiện một cách rất đơn giản miễn là bạn có kết nối SSH giữa các máy chủ:
$ ssh -L local_port:old_dc_host:mysql_port_in_old_dc [email protected]_dc_host -N &Ví dụ:
$ ssh -L 3307:10.0.0.201:3306 [email protected] -N &Bây giờ, bạn có thể kết nối với máy chủ từ xa bằng cách sử dụng 127.0.0.1:3307
$ mysql -P3307 -h 127.0.0.1Nó sẽ hoạt động tương tự đối với bản sao, chỉ cần nhớ sử dụng 127.0.0.1 cho master_host và 3307 cho master_port
Cuối cùng nhưng không kém phần quan trọng, bạn có thể mã hóa bản sao của mình bằng SSL. Bài đăng trên blog trước đây giải thích cách nó có thể được thực hiện và loại tác động của nó đối với hiệu suất sao chép.
Nếu bạn quyết định sử dụng bản sao Galera trên cả hai trung tâm dữ liệu, các đề xuất trên cũng áp dụng tại đây. Khi nói đến SSL, trước đây chúng tôi đã viết blog về cách mã hóa lưu lượng sao chép Galera. Để có giải pháp hoàn thiện hơn, bạn có thể muốn mã hóa tất cả các kết nối cơ sở dữ liệu từ các ứng dụng khách và bất kỳ cơ sở hạ tầng quản lý / giám sát nào.
Thiết lập cơ sở hạ tầng mới
Khi bạn có kết nối, bạn cần bắt đầu xây dựng cơ sở hạ tầng mới. Đối với điều đó, bạn có thể sẽ sử dụng xtrabackup hoặc mariabackup. Có thể hấp dẫn khi kết hợp việc di chuyển với nâng cấp MySQL, sau khi tất cả bạn đang thiết lập môi trường hoàn toàn mới ở vị trí mới. Chúng tôi không khuyên bạn nên làm điều đó. Việc di chuyển sang một cơ sở hạ tầng mới là đủ quan trọng đối với bản thân nó, vì vậy việc kết hợp nó với một thay đổi lớn khác sẽ làm tăng độ phức tạp và rủi ro. Điều đó cũng đúng với những thứ khác - bạn muốn thực hiện từng bước cách tiếp cận để thay đổi. Chỉ bằng cách thay đổi từng thứ một, bạn mới có thể hiểu được kết quả của những thay đổi và cách chúng tác động đến khối lượng công việc của bạn - nếu bạn thực hiện nhiều thay đổi tại một thời điểm nhất định, bạn không thể chắc chắn cái nào chịu trách nhiệm cho một cái đã cho (mới ) hành vi mà bạn đã quan sát.
Khi bạn thiết lập và chạy một phiên bản MySQL mới trong trung tâm dữ liệu mới, bạn cần bổ sung nó khỏi nút trong trung tâm dữ liệu cũ - để đảm bảo rằng dữ liệu trong cả hai trung tâm dữ liệu sẽ luôn đồng bộ. Điều này sẽ trở nên hữu ích khi bạn chuẩn bị cho bước cắt cuối cùng. Đó cũng là một cách hay để đảm bảo rằng môi trường mới có thể xử lý tải ghi của bạn.
Bước tiếp theo sẽ là xây dựng một cơ sở hạ tầng hoàn chỉnh ở vị trí mới và thực hiện các bài kiểm tra và điểm chuẩn. Đây là bước rất quan trọng không nên bỏ qua - vấn đề ở đây là bạn, với tư cách là DBA, phải hiểu năng lực của cơ sở hạ tầng của bạn. Khi bạn thay đổi nhà cung cấp, mọi thứ cũng thay đổi. Phần cứng / vm mới nhanh hơn hoặc chậm hơn. Có nhiều hơn hoặc ít bộ nhớ hơn cho mỗi trường hợp. Bạn cần phải hiểu lại khối lượng công việc của mình sẽ phù hợp với phần cứng bạn sẽ sử dụng như thế nào. Để làm được điều đó, bạn có thể sẽ sử dụng Percona Playback hoặc pt-log-player để phát lại một số truy vấn trong đời thực trên hệ thống dàn dựng. Bạn sẽ muốn kiểm tra hiệu suất và đảm bảo rằng nó ở mức có thể chấp nhận được đối với bạn. Bạn cũng muốn thực hiện tất cả các kiểm tra chấp nhận tiêu chuẩn mà bạn chạy trên các bản phát hành mới của mình - chỉ để xác nhận rằng mọi thứ đã bắt đầu và đang chạy. Nói chung, tất cả các ứng dụng phải được xây dựng theo cách mà chúng không phụ thuộc vào cấu hình phần cứng và thiết lập hiện tại. Nhưng có điều gì đó đã xảy ra và ứng dụng của bạn có thể phụ thuộc vào một số điều chỉnh cấu hình hoặc giải pháp phần cứng mà bạn không có trong môi trường mới.
Cuối cùng, khi bạn hài lòng với các thử nghiệm của mình, bạn sẽ muốn xây dựng cơ sở hạ tầng sẵn sàng sản xuất. Sau khi hoàn tất, bạn có thể muốn chạy một số kiểm tra chỉ đọc để xác minh lần cuối. Đây sẽ là bước cuối cùng trước khi chuyển đổi.
Cắt giảm
Sau khi tất cả các thử nghiệm đó đã được thực hiện và sau khi cơ sở hạ tầng được coi là đã sẵn sàng sản xuất, bước cuối cùng là cắt lưu lượng truy cập khỏi cơ sở hạ tầng cũ.
Nói trên bình diện toàn cầu, đây là một quá trình phức tạp nhưng khi chúng ta xem xét tầng cơ sở dữ liệu, nó ít nhiều giống với chuyển đổi dự phòng tiêu chuẩn - điều mà bạn có thể đã làm nhiều lần trong quá khứ. Chúng tôi đã trình bày chi tiết về vấn đề này trong một bài đăng trước đó, các bước ngắn gọn là:dừng lưu lượng, đảm bảo nó đã dừng, đợi trong khi ứng dụng đang được chuyển đến trung tâm dữ liệu mới (bản ghi DNS thay đổi hoặc không), thực hiện một số kiểm tra khói để đảm bảo tất cả đều có vẻ ổn, hiển thị trực tuyến, hãy theo dõi chặt chẽ trong một thời gian.
Việc cắt bỏ này sẽ yêu cầu một số thời gian chết, như chúng ta có thể thấy. Vấn đề là đảm bảo rằng chúng tôi có trạng thái nhất quán trên trang cũ và trang mới. Nếu chúng ta muốn làm điều đó mà không mất thời gian chết, thì chúng ta sẽ cần thiết lập bản sao tổng thể chủ. Lý do là khi chúng tôi làm mới DNS và chuyển các phiên từ trang cũ sang trang mới, cả hai hệ thống sẽ được sử dụng cùng một lúc - cho đến khi tất cả các phiên được chuyển hướng đến trang mới. Trong thời gian chờ đợi, bất kỳ thay đổi nào trên trang web mới cần được phản ánh trên trang web cũ.
Sử dụng Galera Cluster, như được mô tả trong bài đăng blog này, cũng có thể là một cách để giữ cho dữ liệu giữa hai trang web được đồng bộ hóa.
Chúng tôi biết rằng đây là một mô tả rất ngắn gọn về quá trình di chuyển dữ liệu. Hy vọng rằng nó sẽ đủ để chỉ cho bạn một hướng đi tốt và giúp bạn xác định những thông tin bổ sung mà bạn cần tìm kiếm.
