Drupal là Hệ thống Quản lý Nội dung (CMS) được thiết kế để tạo mọi thứ từ các trang web công ty nhỏ đến lớn. Hơn 1.000.000 trang web chạy trên Drupal và nó được sử dụng để tạo nhiều trang web và ứng dụng bạn sử dụng hàng ngày (bao gồm cả trang web này). Drupal có một bộ tính năng tiêu chuẩn tuyệt vời như tạo nội dung dễ dàng, hiệu suất đáng tin cậy và bảo mật tuyệt vời. Điều làm nên sự khác biệt của Drupal là tính linh hoạt của nó vì tính mô-đun là một trong những nguyên tắc cốt lõi của nó.
Drupal cũng là một lựa chọn tuyệt vời để tạo các khung kỹ thuật số tích hợp. Bạn có thể mở rộng nó với hàng ngàn tiện ích bổ sung có sẵn. Các mô-đun này mở rộng chức năng của Drupal. Chủ đề cho phép bạn tùy chỉnh bản trình bày và phân phối nội dung của mình (gói Drupal) là những gói mà bạn có thể sử dụng làm bộ dụng cụ bắt đầu. Bạn có thể sử dụng tất cả các chức năng này để trộn và kết hợp nhằm nâng cao khả năng cốt lõi của Drupal hoặc tích hợp Drupal với các dịch vụ bên ngoài. Đây là phần mềm quản lý nội dung mạnh mẽ và có thể mở rộng.
Drupal sử dụng cơ sở dữ liệu để lưu trữ nội dung web của nó. Khi trang web hoặc ứng dụng dựa trên Drupal của bạn đang gặp phải một lượng lớn lưu lượng truy cập, nó có thể ảnh hưởng đến máy chủ cơ sở dữ liệu của bạn. Khi bạn ở trong tình huống này, bạn sẽ yêu cầu cân bằng tải, tính sẵn sàng cao và kiến trúc dự phòng để giữ cơ sở dữ liệu của bạn trực tuyến.
Khi tôi bắt đầu nghiên cứu blog này, tôi nhận ra rằng có rất nhiều câu trả lời cho vấn đề này trên mạng, nhưng các giải pháp được đề xuất đã rất lỗi thời. Điều này có thể là kết quả của việc WordPress tăng thị phần dẫn đến một cộng đồng mã nguồn mở nhỏ hơn. Những gì tôi đã tìm thấy là một số ví dụ về việc triển khai tính khả dụng cao bằng cách sử dụng Master / Master (Tính khả dụng cao) hoặc Master / Master / Slave (Tính khả dụng cao / Hiệu suất cao).
Drupal cung cấp hỗ trợ cho nhiều loại cơ sở dữ liệu, nhưng ban đầu nó được thiết kế bằng cách sử dụng các biến thể MySQL. Mặc dù việc sử dụng MySQL được hỗ trợ đầy đủ, nhưng bạn có thể thực hiện các cách tiếp cận tốt hơn. Tuy nhiên, việc triển khai các phương pháp tiếp cận khác này, nếu không được thực hiện đúng cách, có thể khiến trang web của bạn gặp phải một lượng lớn thời gian chết, khiến ứng dụng của bạn gặp vấn đề về hiệu suất và có thể dẫn đến vấn đề ghi vào nô lệ của bạn. Việc thực hiện bảo trì cũng sẽ khó khăn vì bạn cần chuyển đổi dự phòng để áp dụng các nâng cấp hoặc bản vá máy chủ (phần cứng hoặc phần mềm) mà không có thời gian chết. Điều này đặc biệt đúng nếu bạn có một lượng lớn dữ liệu, có thể gây ra tác động lớn cho doanh nghiệp của bạn.
Đây là những tình huống bạn không muốn xảy ra, đó là lý do tại sao trong blog này, chúng ta sẽ thảo luận về cách bạn có thể triển khai chuyển đổi dự phòng cơ sở dữ liệu cho cơ sở dữ liệu MySQL hoặc PostgreSQL của mình.
Tại sao trang web Drupal của bạn cần chuyển đổi dự phòng cơ sở dữ liệu?
Từ Wikipedia “chuyển đổi dự phòng là chuyển sang máy chủ máy tính dự phòng hoặc dự phòng, hệ thống, thành phần phần cứng hoặc mạng khi ứng dụng, máy chủ, hệ thống, thành phần phần cứng hoặc mạng đang hoạt động trước đó bị lỗi hoặc kết thúc bất thường. Chuyển đổi dự phòng và chuyển đổi cơ bản là hoạt động giống nhau, ngoại trừ việc chuyển đổi dự phòng là tự động và thường hoạt động mà không cần cảnh báo, trong khi chuyển đổi dự phòng cần có sự can thiệp của con người ”.
Trong hoạt động cơ sở dữ liệu, chuyển đổi cũng là một thuật ngữ được sử dụng để chuyển đổi dự phòng thủ công, có nghĩa là nó yêu cầu một người vận hành chuyển đổi dự phòng. Chuyển đổi dự phòng rất hữu ích cho bất kỳ quản trị viên nào vì nó cô lập các vấn đề không mong muốn như xóa / bỏ bảng ngẫu nhiên, thời gian ngừng hoạt động kéo dài gây ảnh hưởng đến hoạt động kinh doanh, hỏng cơ sở dữ liệu hoặc hỏng cấp hệ thống.
Chuyển đổi dự phòng cơ sở dữ liệu bao gồm nhiều hơn một nút cơ sở dữ liệu duy nhất, về mặt vật lý hoặc ảo. Lý tưởng nhất, vì chuyển đổi dự phòng yêu cầu bạn chuyển sang một nút khác, bạn cũng có thể chuyển sang một máy chủ cơ sở dữ liệu khác, nếu một máy chủ đang chạy nhiều phiên bản cơ sở dữ liệu trên một máy chủ duy nhất. Đó vẫn có thể là chuyển đổi hoặc chuyển đổi dự phòng, nhưng thường thì nó dư thừa nhiều hơn và tính khả dụng cao trong trường hợp có sự cố xảy ra trên máy chủ hiện tại đó.
Chuyển đổi dự phòng MySQL cho Drupal
Thực hiện chuyển đổi dự phòng cho ứng dụng dựa trên Drupal của bạn yêu cầu dữ liệu do cơ sở dữ liệu xử lý không phân biệt hoặc tách biệt. Có một số giải pháp có sẵn và chúng tôi đã thảo luận một số giải pháp trong số chúng trong các blog trước đây của Somenines. Bạn có thể muốn đọc phần Giới thiệu về chuyển đổi dự phòng cho MySQL Replication - Blog 101 của chúng tôi.
Công cụ chuyển mạch chủ-nô lệ
Các phương pháp phổ biến nhất cho Chuyển đổi dự phòng MySQL là sử dụng chuyển đổi chủ-tớ hoặc chuyển đổi dự phòng thủ công. Có hai cách tiếp cận bạn có thể làm ở đây:
- Bạn có thể triển khai cơ sở dữ liệu của mình bằng một bản sao chủ-tớ không đồng bộ điển hình.
- hoặc có thể triển khai với sao chép chủ-tớ không đồng bộ bằng cách sử dụng sao chép dựa trên GTID.
Việc chuyển sang trang cái khác có thể nhanh hơn và dễ dàng hơn. Điều này có thể được thực hiện với cú pháp MySQL sau:
mysql> SET GLOBAL read_only = 1; /* enable read-only */
mysql> CHANGE MASTER TO MASTER_HOST = '<hostname-or-ip>', MASTER_USER = '<user>', MASTER_PASSWORD = '<password>', MASTER_LOG_FILE = '<master-log-file>', MASTER_LOG_POS=<master_log_position>; /* master information to connect */
mysql> START SLAVE; /* start replication */
mysql> SHOW SLAVE STATUS\G /* check replication status */hoặc với GTID, bạn có thể chỉ cần thực hiện,
...
mysql> CHANGE MASTER TO MASTER_HOST = '<hostname-or-ip>', MASTER_USER = '<user>', MASTER_PASSWORD = '<password>', MASTER_AUTO_POSITION = 1; /* master information to connect */
...
WitSử dụng phương pháp không phải GTID, trước tiên bạn phải xác định tệp nhật ký chính và vị trí nhật ký chính. Bạn có thể xác định điều này bằng cách xem trạng thái của nút chính trong nút chính trước khi chuyển sang.
mysql> MASTER STATUS;Bạn cũng có thể xem xét việc tăng cường máy chủ của mình bằng cách thêm sync_binlog =1 và innodb_flush_log_at_trx_commit =1 vì trong trường hợp máy chủ của bạn gặp sự cố, bạn sẽ có cơ hội cao hơn rằng các giao dịch từ máy chủ sẽ không đồng bộ với máy chủ của bạn ( S). Trong trường hợp như vậy, cái được thăng cấp có cơ hội cao hơn trở thành một nút nguồn dữ liệu nhất quán.
Tuy nhiên, đây có thể không phải là cách tiếp cận tốt nhất cho cơ sở dữ liệu Drupal của bạn vì nó có thể gây ra thời gian chết kéo dài nếu không được thực hiện đúng, chẳng hạn như bị gỡ xuống đột ngột. Nếu nút cơ sở dữ liệu chính của bạn gặp lỗi dẫn đến cơ sở dữ liệu gặp sự cố, bạn sẽ cần ứng dụng của mình trỏ đến một cơ sở dữ liệu khác đang chờ ở chế độ chờ làm chủ mới hoặc bằng cách thăng cấp nô lệ của bạn lên làm chủ. Bạn sẽ cần chỉ định chính xác nút nào sẽ tiếp quản và sau đó xác định độ trễ và tính nhất quán của nút đó. Đạt được điều này không dễ dàng như chỉ thực hiện SET GLOBAL read_only =1; ĐỔI TRƯỞNG THÀNH THÀNH… (v.v.), có một số tình huống cần phân tích sâu hơn, xem xét các giao dịch khả thi cần có mặt trong máy chủ dự phòng đó hoặc máy chủ được thăng cấp, để hoàn thành công việc.
Chuyển đổi dự phòng Drupal bằng MHA
Một trong những công cụ phổ biến nhất để chuyển đổi dự phòng tự động và thủ công là MHA. Nó đã xuất hiện từ lâu và đến nay vẫn được nhiều tổ chức sử dụng. Bạn có thể xem các blog trước đây của chúng tôi về chủ đề Các vấn đề thường gặp hàng đầu với MHA và Cách khắc phục các công cụ có tính khả dụng cao của chúng hoặc MySQL - So sánh MHA, MRM và ClusterControl.
Chuyển đổi dự phòng Drupal Sử dụng Trình dàn nhạc
Orchestrator hiện đã được áp dụng rộng rãi và đang được sử dụng bởi các tổ chức lớn như Github và Booking.com. Nó không chỉ cho phép bạn quản lý chuyển đổi dự phòng mà còn quản lý cấu trúc liên kết, khám phá máy chủ lưu trữ, tái cấu trúc và khôi phục. Có một blog bên ngoài rất hay ở đây mà tôi thấy rất hữu ích khi tìm hiểu về cơ chế chuyển đổi dự phòng của nó với Orchestrator. Đó là một loạt blog gồm hai phần; phần một và phần hai.
Chuyển đổi dự phòng Drupal bằng MaxScale
MaxScale không chỉ là một bộ cân bằng tải được thiết kế cho máy chủ MariaDB, nó còn mở rộng tính khả dụng, khả năng mở rộng và bảo mật cao cho MariaDB, đồng thời, đơn giản hóa việc phát triển ứng dụng bằng cách tách nó khỏi cơ sở hạ tầng cơ sở dữ liệu bên dưới. Nếu bạn đang sử dụng MariaDB, thì MaxScale có thể là một công nghệ phù hợp với bạn. Kiểm tra các blog trước đây của chúng tôi về cách bạn có thể sử dụng cơ chế chuyển đổi dự phòng MaxScale.
Chuyển đổi dự phòng Drupal bằng ClusterControl
Somenines 'ClusterControl cung cấp một loạt các giải pháp giám sát và quản lý cơ sở dữ liệu. Một phần của các giải pháp chúng tôi cung cấp là chuyển đổi dự phòng tự động, chuyển đổi dự phòng thủ công và khôi phục cụm / nút. Điều này rất hữu ích như thể nó hoạt động như người quản trị cơ sở dữ liệu ảo của bạn, thông báo cho bạn theo thời gian thực trong trường hợp cụm của bạn ở “chế độ hoảng loạn”, trong khi quá trình khôi phục đang được hệ thống quản lý. Bạn có thể xem blog này Cách tự động chuyển đổi dự phòng cơ sở dữ liệu với ClusterControl để tìm hiểu thêm về chuyển đổi dự phòng ClusterControl.
Các giải pháp MySQL khác
Một số phương pháp cũ vẫn có thể áp dụng khi bạn muốn chuyển đổi dự phòng. Có MMM, MRM hoặc bạn có thể kiểm tra Group Replication hoặc Galera (lưu ý:Galera không sử dụng bản sao không đồng bộ, thay vì đồng bộ). Chuyển đổi dự phòng trong Cụm Galera không hoạt động giống như cách nó làm với sao chép không đồng bộ. Với Galera, bạn chỉ có thể ghi vào bất kỳ nút nào hoặc, nếu bạn triển khai phương pháp tiếp cận chủ-tớ, bạn có thể hướng ứng dụng của mình đến một nút khác sẽ là người viết hoạt động cho cụm.
Chuyển đổi dự phòng Drupal PostgreSQL
Vì Drupal hỗ trợ PostgreSQL, chúng tôi cũng sẽ kiểm tra các công cụ để triển khai quy trình chuyển đổi dự phòng hoặc chuyển đổi cho PostgreSQL. PostgreSQL sử dụng tính năng Sao chép trực tuyến được tích hợp sẵn, tuy nhiên bạn cũng có thể đặt nó để sử dụng Bản sao lôgic (được thêm vào làm phần tử cốt lõi của PostgreSQL trong phiên bản 10).
Chuyển đổi dự phòng Drupal bằng pg_ctlcluster
Nếu môi trường của bạn là Ubuntu, sử dụng pg_ctlcluster là một cách đơn giản và dễ dàng để thực hiện chuyển đổi dự phòng. Ví dụ:bạn chỉ có thể chạy lệnh sau:
$ pg_ctlcluster 9.6 pg_7653 promotehoặc với RHEL / Centos, bạn có thể sử dụng lệnh pg_ctl giống như,
$ sudo -iu postgres /usr/lib/postgresql/9.6/bin/pg_ctl promote -D /data/pgsql/slave/data
server promotingBạn cũng có thể kích hoạt chuyển đổi dự phòng máy chủ dự phòng đăng nhập bằng cách tạo tệp kích hoạt với tên tệp và đường dẫn được chỉ định bởi trigger_file trong recovery.conf.
Bạn phải cẩn thận với quảng cáo ở chế độ chờ hoặc quảng bá nô lệ ở đây vì bạn có thể phải đảm bảo rằng chỉ có một chủ chấp nhận yêu cầu đọc-ghi. Điều này có nghĩa là, trong khi thực hiện chuyển đổi, bạn có thể phải đảm bảo rằng trang cái trước đó đã được thả lỏng hoặc dừng.
Việc xử lý chuyển đổi hoặc chuyển đổi dự phòng thủ công từ máy chủ chính sang máy chủ dự phòng có thể nhanh chóng, nhưng cần một chút thời gian để chuẩn bị lại cụm chuyển đổi dự phòng. Thường xuyên chuyển từ chế độ chính sang chế độ chờ là một thực tiễn hữu ích vì nó cho phép mỗi hệ thống ngừng hoạt động thường xuyên để bảo trì. Đây cũng là một bài kiểm tra cơ chế chuyển đổi dự phòng, để đảm bảo rằng nó sẽ thực sự hoạt động khi bạn cần. Các thủ tục hành chính bằng văn bản luôn được khuyến cáo.
Chuyển đổi dự phòng tự động Drupal PostgreSQL
Thay vì cách tiếp cận thủ công, bạn có thể yêu cầu chuyển đổi dự phòng tự động. Điều này đặc biệt cần thiết khi máy chủ gặp sự cố do lỗi phần cứng hoặc máy ảo bị hỏng. Bạn cũng có thể yêu cầu một ứng dụng tự động thực hiện chuyển đổi dự phòng để giảm bớt thời gian ngừng hoạt động của ứng dụng Drupal của bạn. Bây giờ chúng ta sẽ điểm qua một số công cụ này có thể được sử dụng để chuyển đổi dự phòng tự động.
Chuyển đổi dự phòng Drupal bằng Patroni
Patroni là mẫu để bạn tạo giải pháp tùy chỉnh, tính khả dụng cao của riêng mình bằng Python và - để có khả năng truy cập tối đa - một cửa hàng cấu hình phân tán như ZooKeeper, etcd, Consul hoặc Kubernetes. Các kỹ sư cơ sở dữ liệu, DBA, kỹ sư DevOps và SRE, những người đang tìm cách triển khai nhanh chóng HA PostgreSQL trong trung tâm dữ liệu - hoặc bất kỳ nơi nào khác - hy vọng sẽ thấy nó hữu ích
Chuyển đổi dự phòng Drupal bằng Pgpool
Pgpool-II là một phần mềm proxy nằm giữa máy chủ PostgreSQL và máy khách cơ sở dữ liệu PostgreSQL. Ngoài việc tự động chuyển đổi dự phòng, nó còn có nhiều tính năng bao gồm gộp kết nối, cân bằng tải, sao chép và hạn chế các kết nối vượt quá. Bạn có thể đọc thêm về công cụ này là blog ba phần của chúng tôi; phần một, phần hai, phần ba.
Chuyển đổi dự phòng Drupal Sử dụng pglookout
pglookout là một trình nền giám sát sao chép và chuyển đổi dự phòng của PostgreSQL. pglookout giám sát các nút cơ sở dữ liệu, trạng thái sao chép của chúng và hoạt động theo trạng thái đó. Ví dụ:gọi một lệnh chuyển đổi dự phòng được xác định trước để thăng cấp một cái mới trong trường hợp cái trước đó bị mất.
pglookout hỗ trợ hai loại nút khác nhau, loại được cài đặt trên chính các nút db và loại nút quan sát có thể được cài đặt ở bất kỳ đâu. Mục đích của việc có pglookout trên các nút PostgreSQL DB là để theo dõi trạng thái sao chép của cụm và hành động theo đó, những người quan sát có giới hạn hơn:họ chỉ quan sát trạng thái cụm để đưa ra quan điểm khác cho trạng thái cụm.
Chuyển đổi dự phòng Drupal Sử dụng repmgr
repmgr là bộ công cụ mã nguồn mở để quản lý sao chép và chuyển đổi dự phòng trong một cụm máy chủ PostgreSQL. Nó tăng cường khả năng chờ nóng tích hợp của PostgreSQL với các công cụ để thiết lập máy chủ dự phòng, giám sát sao chép và thực hiện các tác vụ quản trị như chuyển đổi dự phòng hoặc hoạt động chuyển đổi thủ công.
repmgr đã cung cấp hỗ trợ nâng cao cho các cơ chế sao chép tích hợp sẵn của PostgreSQL kể từ khi chúng được giới thiệu trong phiên bản 9.0. Dòng repmgr hiện tại, repmgr 4, hỗ trợ những phát triển mới nhất về chức năng sao chép được giới thiệu từ PostgreSQL 9.3 như sao chép theo tầng, chuyển đổi dòng thời gian và sao lưu cơ sở thông qua giao thức sao chép.
Chuyển đổi dự phòng Drupal bằng ClusterControl
ClusterControl hỗ trợ chuyển đổi dự phòng tự động cho PostgreSQL. Nếu bạn gặp sự cố, nô lệ của bạn có thể tự động được thăng cấp lên trạng thái chủ. Với ClusterControl, bạn cũng có thể triển khai cơ sở dữ liệu PostgreSQL độc lập, sao chép hoặc nhóm. Bạn cũng có thể dễ dàng thêm hoặc xóa một nút chỉ bằng một thao tác.
Các giải pháp chuyển đổi dự phòng PostgreSQL Drupal khác
Chắc chắn có các giải pháp chuyển đổi dự phòng tự động mà tôi có thể đã bỏ qua trên blog này. Nếu tôi đã làm vậy, vui lòng thêm nhận xét của bạn bên dưới để chúng tôi có thể biết suy nghĩ và kinh nghiệm của bạn về việc triển khai và thiết lập chuyển đổi dự phòng, đặc biệt là đối với các trang web hoặc ứng dụng Drupal.
Các giải pháp bổ sung cho chuyển đổi dự phòng Drupal
Mặc dù các công cụ tôi đã đề cập trước đó chắc chắn xử lý giải pháp cho các vấn đề của bạn với chuyển đổi dự phòng, nhưng việc thêm một số công cụ giúp chuyển đổi dự phòng trở nên dễ dàng hơn, an toàn hơn và có sự cách ly hoàn toàn giữa các lớp cơ sở dữ liệu của bạn có thể đạt yêu cầu.
Chuyển đổi dự phòng Drupal bằng ProxySQL
Với ProxySQL, bạn chỉ có thể trỏ các trang web hoặc ứng dụng Drupal của mình tới máy chủ lưu trữ máy chủ ProxySQL và nó sẽ chỉ định nút nào sẽ nhận ghi và nút nào sẽ nhận lần đọc. Điều kỳ diệu xảy ra một cách minh bạch trong lớp TCP và không cần thay đổi đối với cấu hình ứng dụng / trang web của bạn. Ngoài ra, ProxySQL cũng hoạt động như bộ cân bằng tải cho các yêu cầu ghi và đọc đối với lưu lượng cơ sở dữ liệu của bạn. Điều này chỉ áp dụng nếu bạn đang sử dụng các biến thể cơ sở dữ liệu MySQL.
Chuyển đổi dự phòng Drupal bằng HAProxy với Keepalived
Sử dụng HAProxy và Keepalived bổ sung thêm tính khả dụng và dự phòng cao hơn trong cơ sở dữ liệu Drupal của bạn. Nếu bạn muốn chuyển đổi dự phòng, nó có thể được thực hiện mà ứng dụng của bạn không biết điều gì đang xảy ra trong lớp cơ sở dữ liệu của bạn. Chỉ cần trỏ ứng dụng của bạn đến IP vrrp mà bạn đã thiết lập trong Keepalived và mọi thứ sẽ được xử lý hoàn toàn với ứng dụng của bạn. Việc có một chuyển đổi dự phòng tự động sẽ được ứng dụng của bạn xử lý một cách minh bạch và không chủ ý, vì vậy không có thay đổi nào phải xảy ra một lần, chẳng hạn như một thảm họa đã xảy ra và một khôi phục hoặc chuyển đổi dự phòng đã được áp dụng. Điều tốt về thiết lập này là nó có thể áp dụng cho cả cơ sở dữ liệu MySQL và PostgreSQL. Tôi khuyên bạn nên xem blog Cân bằng tải PostgreSQL của chúng tôi bằng HAProxy &Keepalived để tìm hiểu thêm về cách thực hiện việc này.
Tất cả các tùy chọn trên đều được hỗ trợ bởi ClusterControl. Bạn có thể triển khai hoặc nhập cơ sở dữ liệu rồi triển khai ProxySQL, MaxScale hoặc HAProxy &Keepalived. Mọi thứ sẽ được quản lý, giám sát và sẽ được thiết lập tự động mà không cần bạn cấu hình thêm. Tất cả đều diễn ra ở chế độ nền và tự động tạo bản sẵn sàng cho sản xuất.
Kết luận
Có một trang web hoặc ứng dụng Drupal luôn hoạt động, đặc biệt nếu bạn đang mong đợi một lượng lớn lưu lượng truy cập, có thể phức tạp để tạo. Tuy nhiên, nếu bạn có công cụ phù hợp, thiết lập phù hợp và công nghệ phù hợp, bạn có thể đạt được tính khả dụng và dự phòng cao.
Và nếu bạn thì không? Sau đó, ClusterControl sẽ thiết lập và duy trì nó cho bạn. Ngoài ra, bạn có thể tạo một thiết lập bằng cách sử dụng các công nghệ được đề cập trong blog này, hầu hết trong số đó là các công cụ miễn phí, mã nguồn mở phục vụ cho nhu cầu của bạn.
