Cơ sở dữ liệu sao chép để dự phòng sử dụng một cơ sở dữ liệu miễn phí và Java với mùa xuân & Hibernate ứng dụng web

Question

Tôi có điều này trong tâm trí:

On mỗi máy chủ: (họ tất cả được thiết lập hệt)

• Cơ sở dữ liệu miễn phí như MySQL hoặc PostgreSQL.
• Tomcat 6.x để lưu trữ Servlet ứng dụng dựa trên Java
• Hibernate 3.x như công cụ ORM
• Spring 2,5 cho lớp kinh doanh
• Wicket 1.3.2 cho các lớp trình bày

Tôi đặt cân bằng tải ở phía trước máy chủ và bộ cân bằng tải thay thế trong trường hợp cân bằng tải chính của tôi bị hỏng.

Tôi sử dụng Terracotta để có thông tin phiên được sao chép giữa các máy chủ. Nếu một máy chủ bị hỏng, người dùng có thể tiếp tục công việc của họ tại một máy chủ khác, lý tưởng là nếu không có gì xảy ra. Những gì còn lại để "giải quyết" (như tôi đã không thực sự thử nghiệm này và ví dụ không biết những gì tôi nên sử dụng như là một cân bằng tải) là nhân rộng cơ sở dữ liệu đó là cần thiết.

Nếu người dùng tương tác với ứng dụng và cơ sở dữ liệu thay đổi, thì thay đổi đó phải được sao chép vào máy chủ cơ sở dữ liệu trên các máy chủ khác. Tôi nên làm thế nào? Tôi có nên sử dụng MySQL PostgreSQL hay cái gì khác (lý tưởng là miễn phí vì chúng tôi có ngân sách hạn chế)? Những thứ khác trên âm thanh có hợp lý không?

Làm rõ: Tôi cụm để có tính sẵn sàng cao đầu tiên và quan trọng nhất và tôi muốn có thể thêm máy chủ và sử dụng tất cả cùng một lúc để có khả năng mở rộng cao.

Answer 1

Vì bạn đã sử dụng Terracotta và bạn tin rằng DB thứ hai là một ý tưởng hay (đã đồng ý), bạn có thể xem xét mở rộng vai trò của Terracotta. Chúng tôi có những khách hàng sử dụng Terracotta để sao chép cơ sở dữ liệu. Dưới đây là một ví dụ ngắn gọn/mô tả nhưng tôi nghĩ rằng họ đã ngừng hỗ trợ khách hàng cho sản phẩm này .:

http://www.terracotta.org/web/display/orgsite/TCCS+Asynchronous+Data+Replication

Answer 2

Đây là một ý tưởng. Đọc sách của Theo Schlossnagle Salable Internet Architectures.

Điều bạn đang đề xuất không phải là ý tưởng hay nhất.

Bộ cân bằng tải đắt và không có giá trị như chúng xuất hiện. Sử dụng một cái gì đó đơn giản hơn để phân phối tải giữa các máy chủ của bạn (giống như Wackamole).

Thay vì đánh lừa xung quanh với nhân rộng DB, hãy tiêu tiền của bạn trên một máy chủ DB đáng tin cậy tách biệt với máy chủ web mặt trước của bạn. Thực hiện sao lưu thường xuyên và trong rất sự kiện không chắc xảy ra lỗi DB, hãy chạy lại nhanh nhất có thể từ bản sao lưu thông thường.

Answer 3

Đối với trang web (Perl-driven) của tôi, tôi đang sử dụng MySQL trên hai máy chủ có nhân rộng cơ sở dữ liệu. Mỗi máy chủ MySQL là slave và master cùng một lúc. Tôi đã làm điều này cho redudancy, không cho hiệu suất, nhưng các thiết lập đã làm việc tốt cho 3 năm qua, chúng tôi đã gần như không có thời gian chết ở tất cả trong thời gian này.

Về câu hỏi/nhận xét của Kent: Tôi đang sử dụng bản sao chuẩn đi kèm với MySQL.

Về cơ chế chuyển đổi dự phòng: Tôi đang sử dụng DNSMadeEasy.chức năng chuyển đổi dự phòng của com. Tôi có một kịch bản Perl chạy mỗi 5 phút thông qua cron kiểm tra nếu nhân rộng vẫn đang chạy (và cũng có rất nhiều thứ khác như tải máy chủ, HDD sanity, sử dụng RAM, vv). Trong quá trình hoạt động bình thường, nhanh hơn của hai máy chủ cung cấp tất cả các trang web. Nếu kịch bản phát hiện thấy có sự cố với máy chủ (hoặc nếu máy chủ chỉ đơn giản là xuống), DNSMadeEasy chuyển các mục DNS sao cho máy chủ phụ trở thành chính. Khi máy chủ chính "thực" được sao lưu, MySQL sẽ tự động bắt kịp các thay đổi cơ sở dữ liệu bị thiếu và DNSMadeEasy sẽ tự động chuyển trở lại.

Answer 4

Bạn đang cố gắng để tạo ra một bản sao multi-master, đó là một ý tưởng rất xấu, như bất kỳ thay đổi bất kỳ cơ sở dữ liệu nào phải sao chép vào mọi cơ sở dữ liệu khác. Điều này là cực kỳ chậm - trên một máy chủ bạn có thể nhận được vài trăm giao dịch mỗi giây bằng cách sử dụng một vài đĩa nhanh và RAID1 hoặc RAID10. Nó có thể được nhiều hơn nữa nếu bạn có một bộ điều khiển RAID tốt với bộ nhớ đệm được hỗ trợ pin. Nếu bạn thêm chi phí liên lạc với tất cả các máy chủ của mình, bạn sẽ nhận được tối đa hàng chục giao dịch mỗi giây.

Nếu bạn muốn tính sẵn sàng cao, bạn nên sử dụng giải pháp dự phòng ấm, nơi bạn có máy chủ được sao chép nhưng không được sử dụng - khi máy chủ chính chết thay thế. Bạn có thể mất một số giao dịch gần đây nếu máy chủ chính của bạn bị chết.

Bạn cũng có thể thực hiện một bản sao chính, nhiều bản sao không đồng bộ. Mọi thay đổi đối với một cơ sở dữ liệu sẽ phải được thực hiện trên một máy chủ chủ. Nhưng bạn có thể có một số nô lệ, máy chủ chỉ đọc. Dữ liệu trên máy chủ nô lệ này có thể là một số giao dịch phía sau máy chủ để bạn cũng có thể mất một số giao dịch gần đây trong trường hợp máy chủ chết.

PostgreSQL không có cả hai loại sao chép - chế độ chờ ấm bằng cách sử dụng tính năng vận chuyển nhật ký và một bản chính, nhiều lần sử dụng dấu gạch chéo.

Chỉ khi bạn có số lượng ghi rất nhỏ, bạn có thể thực hiện sao chép đồng bộ. Điều này cũng có thể được thiết lập cho PostgreSQL bằng cách sử dụng PgPool-II hoặc Sequoia.

Vui lòng đọc High Availability, Load Balancing, and Replication chương trong tài liệu Postgres để biết thêm.

Answer 5

AFAIK, MySQL làm tốt hơn việc có thể mở rộng được. Xem tài liệu http://dev.mysql.com/doc/mysql-ha-scalability/en/ha-overview.html

Và có một blog, nơi bạn có thể có một cái nhìn vào các ví dụ thực tế đời sống: http://highscalability.com/tags/mysql