Có đáng để sử dụng một máy chủ MySQL riêng biệt không?

Một câu hỏi tương tự đã biến thành món súp ý kiến ở đây : Vì vậy, có thể không có câu trả lời 'đúng' cho vấn đề này, nhưng tôi muốn kiểm tra với cộng đồng.

Khách hàng của tôi sắp tung ra một quảng cáo truyền hình. Họ đang mong đợi lưu lượng truy cập trong bộ phận 7 chữ số trong tháng tới. Công việc của tôi là đảm bảo máy chủ không bị đổ.

Câu hỏi của tôi: có đáng để chia cơ sở dữ liệu MySQL thành một máy chủ riêng biệt, chỉ phục vụ cơ sở dữ liệu. Sau đó tôi muốn có nhiều máy chủ chứa codebase và phục vụ apache, giao tiếp với hộp cơ sở dữ liệu. Tất cả sẽ là container ảo.

Tôi KHÔNG (nghĩ) Tôi muốn sử dụng nhiều máy chủ DB - dường như nó sẽ giới thiệu sự phức tạp không cần thiết và các lỗi / tắc nghẽn tiềm ẩn không cần thiết.

Tôi có lầm không? Sẽ hoan nghênh một số ý kiến ​​kinh nghiệm về điều này. Cảm ơn.

Chúng tôi đã sử dụng một máy chủ MySQL riêng trong một số trường hợp các cửa hàng đang phải đối mặt với lưu lượng truy cập cao. Có một vài lợi thế của nó

1. Các máy chủ cơ sở dữ liệu chuyên dụng có thể được điều chỉnh theo các nhu cầu cụ thể của MySQL, khác với máy chủ web
2. Thật dễ dàng để thêm một máy chủ cơ sở dữ liệu thứ hai (tải cân bằng) vào cụm khi cần
3. Khi cơ sở dữ liệu của bạn bị hỏng, nó không bị sập giao diện để bạn có thể hiển thị trang cảnh báo hoặc lỗi chính xác.

Khi Magento được lưu trữ đúng cách với Varnish hoặc bất kỳ tiện ích mở rộng FPC nào khác, nút cổ chai chính sẽ là cơ sở dữ liệu từ những gì tôi đã trải nghiệm. Sức mạnh thực sự sẽ được yêu cầu cho cơ sở dữ liệu của bạn. Bằng cách này, bạn có thể bắt đầu với một máy chủ web tương đối nhỏ và đầu tư nhiều hơn vào máy chủ cơ sở dữ liệu.

Bảo vệ:

Ngoài câu trả lời của Sander, tôi sẽ nói thêm rằng ở một số mức độ tuân thủ PCI nhất định, đây là một yêu cầu :

Các máy chủ cơ sở dữ liệu và web riêng biệt CHD được lưu trữ hàng loạt trong cơ sở dữ liệu, làm cho nó trở thành mục tiêu có giá trị cao cho kẻ tấn công. Máy chủ cơ sở dữ liệu riêng biệt có nghĩa là quyền truy cập có thể được kiểm soát chặt chẽ (hạn chế tiếp xúc). Yêu cầu theo Mục 1 của PCI DSS.

Nguồn: http : //www.f Focusonpci.com/site/index.php/PCI-101/technical-requirements.html

Bằng cách tách biệt nhiệm vụ web và cơ sở dữ liệu, bạn sẽ hạn chế tiếp xúc. Thông thường, db của bạn nằm trong một phân khúc riêng của mạng và không thể truy cập công khai.

Một kết nối VPN tĩnh cũng được đề xuất, trong PCI, giữa web / db của bạn và phát hiện xâm nhập được đề xuất mạnh mẽ trên thiết bị mạng của bạn. Trong trường hợp thỏa hiệp, db sẽ bị cô lập và kết nối VPN bị chấm dứt, mặc dù ứng dụng và khóa mã hóa của bạn hiện đã bị xâm phạm, quyền truy cập vào kho lưu trữ dữ liệu đã bị khóa và không thể truy cập được.

Tính sẵn sàng cao / Phục hồi thảm họa:

Sander về điểm ở đây. Đi bầu anh lên. Tôi sẽ nói thêm rằng trong trường hợp thậm chí là một nhiệm vụ bảo trì nhỏ như sao lưu hệ thống tập tin hoặc cơ sở dữ liệu, thì tốt nhất là db của bạn sẽ bị giới hạn chỉ đọc trong một thời gian. Trong các trường hợp cực đoan, tôi đã thấy thời gian chờ khóa và hàng đợi xử lý lấp đầy rằng tất cả các kết nối có sẵn được xếp hàng hoặc bị hủy. Các trang web "đi xuống", có hiệu quả.

Bạn có thể giảm thiểu điều này bằng cách tách db và lên lịch cho máy chủ web của bạn để đặt trang web vào chế độ bảo trì trong các cửa sổ sao lưu này mà không có bất kỳ hậu quả nào đối với hệ thống tệp của máy chủ web.