PostgreSQL
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> PostgreSQL

Xây dựng cơ sở dữ liệu khả dụng cao cho Moodle bằng PostgreSQL

Bị ảnh hưởng bởi đại dịch COVID-19, nhiều doanh nghiệp vừa và nhỏ đang chuyển đổi sang các nền tảng trực tuyến. Các lớp học trực diện hoặc thể chất cũng bị ảnh hưởng bởi đại dịch này và nhiều trường học và trường đại học cũng đang chuyển sang trực tuyến và đang tìm kiếm các công cụ có sẵn để sử dụng để tiếp tục phục vụ học sinh hoặc sinh viên, như giáo dục đã không bị cản trở. Một trong những nền tảng nổi tiếng có sẵn cho các mục đích giáo dục trực tuyến hoặc học trực tuyến là Moodle.

Moodle là gì?

Moodle là một phần mềm mã nguồn mở cho hệ thống quản lý học tập trực tuyến, hoặc LMS (còn được gọi là Môi trường Học tập Ảo hoặc VLE) theo giấy phép GPL. Nó cho phép các nhà giáo dục tạo trang web riêng của họ chứa đầy các khóa học động giúp mở rộng việc học, mọi lúc, mọi nơi. Moodle có tất cả hỗ trợ với tính năng và khả năng truy cập dễ dàng cho giáo viên, sinh viên hoặc quản trị viên.

Vì đây là nguồn mở và nền tảng phần mềm miễn phí, bạn có thể sử dụng phần mềm này miễn phí và không tính phí bản quyền giống như các phần mềm nguồn mở khác. Chi phí chỉ phải chịu khi phần mềm này được lưu trữ trên nền tảng lưu trữ trả phí hoặc nếu bạn đang lưu trữ nó bằng Đám mây Moodle của họ. Moodle cũng có sẵn cho các thiết bị cầm tay như điện thoại di động hoặc máy tính bảng.

Tại sao bạn cần một cơ sở dữ liệu có sẵn nhiều?

Vào những năm 1990, một giải pháp rất đơn giản cho Tính khả dụng cao (HA) đã được phát minh, đó là Nhịp tim. Về cơ bản, một cụm Heartbeat có thể thực hiện hai việc:nó giám sát hai nút (và không nhiều hơn hai) và nó được định cấu hình để bắt đầu một hoặc nhiều dịch vụ trên hai nút đó. Nếu nút hiện đang lưu trữ tài nguyên bị lỗi, nó sẽ khởi động lại tài nguyên cụm trên nút còn lại. Mặc dù bản phát hành đầu tiên của Heartbeat không có sự giám sát của bản thân các tài nguyên, nhưng sự thay đổi này cho đến khi phát hành Heartbeat 2.0 vào đầu những năm 2000, nơi nó cho phép quản lý nhiều hơn hai nút trong cụm. Về cơ bản, điều này bao gồm trạng thái phân cụm HA của Linux, phần lớn dựa trên Heartbeat 2.0. Kể từ đó trở đi, rất nhiều giải pháp HA đã được tác động và đã được phát triển và tạo ra để giảm thiểu thời gian ngừng hoạt động, đặc biệt là đối với các tài nguyên quan trọng.

Khả năng sẵn sàng cao không chỉ có nghĩa là giảm thiểu thời gian chết. Nó cũng bao gồm mức độ trách nhiệm để có thể liên tục vận hành và duy trì các dịch vụ mà bạn đang cung cấp và đã hứa với khách hàng của mình. Sẵn sàng phục vụ khách hàng không có nghĩa là bạn cũng có khả năng đáp ứng họ trong trường hợp họ cần trợ giúp. Nó phải đặt ứng dụng và hệ thống kinh doanh của bạn hoạt động đầy đủ như thể nó luôn ở trạng thái hoạt động bình thường ngay cả khi một thảm họa chưa từng có đã xảy ra.

Bạn không thể vận hành ứng dụng VLE của mình bằng Moodle trong khi cơ sở dữ liệu của bạn đang được bảo trì. Nếu bạn chỉ có một máy chủ cơ sở dữ liệu duy nhất, điều này rất phổ biến đối với việc thiết lập ứng dụng đơn giản và nhẹ, khi máy chủ gặp sự cố thì ứng dụng của bạn sẽ dừng lại. Nếu bạn có một cụm cơ sở dữ liệu sử dụng bản sao master-slave sau đó gặp phải một sự cố chưa từng có mà ứng dụng của bạn đang viết trên hai bản chính sau sự cố, thì đó có thể là một mớ hỗn độn lớn gây ra lỗi dữ liệu cho toàn bộ ứng dụng kinh doanh của bạn và lớp dữ liệu. Nếu có các khoản thanh toán liên tục xảy ra vào thời điểm đó, đó có thể là một thảm họa lớn và liên quan đến khối lượng công việc lớn khi thực hiện khôi phục dữ liệu.

Vậy tại sao cơ sở dữ liệu của bạn cần phải có tính sẵn sàng cao? Đó là bởi vì nó phải như vậy,

  • Có thể thực hiện bảo trì hoặc ngừng hoạt động theo kế hoạch một cách khả thi và trong khoảng thời gian bảo trì được phép
  • Thời gian hoạt động rất quan trọng và phải tránh thời gian ngừng hoạt động khi cần thiết
  • SLA quan trọng ở mức độ cao hơn để đạt được dịch vụ khách hàng chất lượng cao
  • Cung cấp dịch vụ liên tục và khả năng sử dụng
  • Không có điểm nào bị lỗi
  • Có thể thực hiện chuyển đổi dự phòng khi bản chính bị hỏng hoặc gặp sự cố
  • Tránh tình huống phân chia não bộ trong đó nhiều bậc thầy đóng vai trò là người viết tích cực cùng một lúc

Xây dựng Cụm Cơ sở dữ liệu

Bây giờ chúng tôi đã nhấn mạnh tầm quan trọng của việc có HA như một kế hoạch và như một giải pháp cho cụm cơ sở dữ liệu của bạn, đặc biệt là cho PostgreSQL, hãy tập trung vào việc xây dựng cụm từ trên xuống dưới để đạt được hiệu quả cao thiết lập có sẵn đã sẵn sàng để thiết lập ứng dụng Moodle.

Cài đặt PostgreSQL

Trước hết, tại sao lại là PostgreSQL? PostgreSQL có lợi thế lớn khi so sánh với các cơ sở dữ liệu khác được hỗ trợ bởi Moodle. Đó là một vấn đề ưu tiên nếu tôi phải tóm tắt vì tất cả các cơ sở dữ liệu được Moodle hỗ trợ đều có khả năng xử lý dữ liệu và cũng là đối tượng để tối ưu hóa. Nó phụ thuộc vào kỹ năng và kinh nghiệm sử dụng cơ sở dữ liệu của bạn. Mặc dù để tóm tắt lý do tại sao sử dụng PostgreSQL, nó là một cơ sở dữ liệu đáng tin cậy và phần mềm mã nguồn mở phức tạp của nó, đặc biệt là trong cơ sở dữ liệu có thể được so sánh với các nhà cung cấp độc quyền khác, chẳng hạn như Oracle và MS SQL. Nó hỗ trợ song song truy vấn, có thể quản lý cơ sở dữ liệu lớn hoặc khổng lồ, hỗ trợ rộng rãi cho JSON và hơn thế nữa. Bạn có thể xem tại đây để biết lý do tại sao nên chọn PostgreSQL. Bây giờ chúng ta hãy tiến hành cài đặt PostgreSQL

Đối với blog này, chúng tôi sẽ sử dụng PostgreSQL 12 bằng Ubuntu 18.04 (Bionic Beaver). Sau đó, để thiết lập Tính sẵn sàng cao, bạn phải có một nút chính và ít nhất là một nút dự phòng (bản sao) mà nó sẽ tiếp quản khi nút chính gặp sự cố.

  • Thiết lập kho lưu trữ và khóa ký
    sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/postgresql.list'
    
    
    
    wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -
  • Cài đặt máy chủ PG 12
    # Update the package lists:
    
    sudo apt-get update
    
    # Install server and client
    
    apt install postgresql-12 postgresql-client-12

Thực hiện việc này trên bản sao đích nhưng bạn cần phải định cấu hình nó ở chế độ chờ hoặc bản sao. Ngoài ra, tôi khuyên bạn nên sử dụng ClusterControl và tải xuống vì nó miễn phí. Sẽ nhanh hơn và nhanh hơn khi cài đặt và thiết lập thiết lập chính / dự phòng. Đối với thiết lập của tôi bằng cách sử dụng ClusterControl và sử dụng tab chế độ xem Topo, tôi nhận được cấu trúc liên kết sau:

Có thiết lập chính / phụ hoặc chính / dự phòng, nó không có nghĩa là bạn được bao phủ đầy đủ cho một cụm cơ sở dữ liệu khả dụng cao. Nó vẫn chưa có tính khả dụng cao. Khi cái chính hoặc cái gặp sự cố, sẽ không có chuyển đổi dự phòng nào nhất định xảy ra. Một điều nữa là, không có sự cân bằng của các kết nối từ các máy khách sẽ đến chủ chống lại nô lệ. Mặc dù cân bằng tải giữa master / slave không yêu cầu rằng nó phải được thiết lập hoặc nó phải được áp dụng để hoàn thành một thiết lập có tính khả dụng cao. Việc cân bằng tải giữa nút chính / chính và phụ / chế độ chờ giúp nút chính của bạn không gây căng thẳng về hiệu suất tải cao, đặc biệt là vào những giờ có lưu lượng truy cập rất cao.

Thiết lập Cân bằng Tải

Như đã đề cập trước đó, cân bằng tải giữa chủ và tớ giúp chủ của bạn không bỏ tải. Sẽ không lý tưởng nếu bạn để chế độ chờ của mình chỉ sử dụng để sao chép hoặc sẽ tiếp quản trong trường hợp bản chính gặp sự cố. Mặc dù điều đó có thể hoạt động, tuy nhiên, điều đó đòi hỏi thời gian chết và công việc thủ công nếu nút chính gặp sự cố, vì bạn cần chuyển vai trò của nút dự phòng sang nút chính. Điều đó cũng tốt nhưng một lần nữa, việc có một bộ cân bằng tải có thể giúp chuyển hướng việc ghi tới cái chính, sau đó định hướng các lần đọc giữa cái chính và nô lệ. Về cơ bản, điều này cung cấp cho bạn khả năng phân chia đọc / ghi. Để làm điều này, có rất nhiều tùy chọn bạn có thể chọn với PostgreSQL. Về cơ bản, cách thiết lập phổ biến nhất nhưng đơn giản và nhẹ là sử dụng HAProxy.

Mặc dù có các tùy chọn như sử dụng PgBouncer hoặc pgpool-II. Để đơn giản hóa blog này, hãy sử dụng HAProxy. Để cài đặt HAProxy, khá đơn giản nếu bạn sử dụng ClusterControl. Hãy làm điều đó thông qua ClusterControl. Để làm điều đó, bạn chỉ cần vào tab Manage, chọn Load Balancer như hình bên dưới,

Vì chúng tôi cần có một thiết lập khả dụng cao cho cụm cơ sở dữ liệu PostgreSQL của bạn, chúng ta nên có ít nhất hai nút. Vì vậy, nếu nút HAProxy chính của bạn gặp sự cố, thì HAProxy thụ động hoặc dự phòng có thể tiếp quản. Hãy xem nó trông như thế nào về phần cuối của tôi,

Mặc dù điều đó có vẻ ổn. Thiết lập này vẫn chưa đủ. Nếu bạn nghĩ rằng chúng tôi tốt cho một thiết lập có tính khả dụng cao với cấu trúc liên kết đó, thì sẽ không có chuyển đổi dự phòng trong trường hợp HAProxy gặp sự cố trên nút 192.168.30.222 tại cổng 9600 hoặc nếu 192.168.30.223:9600 gặp sự cố và nếu ứng dụng của bạn được thiết lập máy chủ lưu trữ, vẫn có thời gian chết nếu không có thiết lập chủ động nào được thực hiện. Bằng cách đó, bạn có thời gian chết nếu nó phải được thiết lập theo cách thủ công. Trong trường hợp này, chúng tôi sẽ sử dụng và thiết lập Keepalived để các phiên bản HAProxy được giám sát chặt chẽ về tình trạng của nó và chuyển đổi dự phòng trong trường hợp nút khác gặp sự cố.

Giữ cho Bộ cân bằng tải luôn khả dụng

Bây giờ chúng tôi đã có bộ cân bằng tải trên cơ sở dữ liệu của mình, nhưng chúng tôi cần HAProxy của chúng tôi luôn hoạt động trong trường hợp nút chính cho điểm cuối ứng dụng gặp sự cố. Về cơ bản, những gì HAProxy có thể làm với thiết lập mà chúng ta có như ở phần trước, các ứng dụng có thể sử dụng 192.168.30.223 hoặc 192.168.30.222 với các cổng 5433 (cổng đọc-ghi) và 5434 (cổng chỉ đọc) tương ứng. Bây giờ có một rắc rối trong trường hợp bạn cần chuyển đổi trong trường hợp các nút khác gặp sự cố, cộng với điều tồi tệ là bạn đang làm tổn hại đến công việc kinh doanh vì nó bao gồm thời gian chết nếu không có chuyển đổi dự phòng tự động để giải quyết. Tránh thời gian chết là cách tốt nhất ở đây trừ khi bạn có SLA rất thấp và RTO và RPO cao.

Để giảm bớt thảm họa hoặc thời gian chết như vậy, chúng tôi khuyên bạn nên thiết lập Keepalived trên HAProxy. Về cơ bản, HAProxy sẽ cân bằng tải giữa đọc và ghi cung cấp cho bạn khả năng phân tách đọc-ghi và Keepalived chỉ theo dõi tình trạng của các nút HAProxy và sẽ quản lý để chọn nút khỏe nhất theo cấu hình mong muốn của nó. Keepalived là một công cụ bạn có thể sử dụng để làm cho các nút HAProxy được giám sát, mặc dù nó không phức tạp để quản lý cơ sở dữ liệu. Keepalived sử dụng VIP (IP ảo) gán cho nút HAProxy chính mặc định và sau đó chỉ định lại VIP đó trong trường hợp nút HAProxy chính bị lỗi và trỏ nó đến nút HAProxy dự phòng hoặc tiếp theo.

Bây giờ, hãy thiết lập điều này bằng cách sử dụng ClusterControl vì nó nhanh hơn và dễ dàng hơn để quản lý với ClusterControl. Để làm điều này, về cơ bản nó giống như cách chúng tôi thiết lập HAProxy nhưng thay vào đó chọn Keepalived như hình dưới đây,

Về cơ bản, nếu bạn cài đặt Keepalived theo cách thủ công, chúng tôi sẽ chọn thứ cấp trong trường hợp HAProxy chính không thành công. Hãy xem chế độ xem Topo của chúng ta trông như thế nào,

Điều này có vẻ rất hứa hẹn. Về cơ bản, ứng dụng khách Moodle sẽ kết nối với VIP, tức là 192.168.30.201 theo các cổng 5433 (cổng đọc-ghi) và 5434 (cổng chỉ đọc). Ví dụ:xác minh nó trên một máy chủ bên ngoài mà tôi có,

[[email protected] ~]# psql -h 192.168.30.201 -U dbapgadmin -W postgres -p 5433

Password:

psql (11.2, server 12.4 (Ubuntu 12.4-1.pgdg18.04+1))

WARNING: psql major version 11, server major version 12.

         Some psql features might not work.

SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)

Type "help" for help.



postgres=# select inet_server_addr();

 inet_server_addr

------------------

 192.168.30.221

(1 row)

tiết lộ rằng chỉ có nút người viết mà tôi mới trỏ đến nút chính của mình, tức là 192.168.30.22. Sau đó, cổng chỉ đọc của tôi phải đi cả nút chính và nút phụ như được hiển thị bên dưới,

[[email protected] ~]# psql -h 192.168.30.201 -U dbapgadmin -W postgres -p 5434

Password:

psql (11.2, server 12.4 (Ubuntu 12.4-1.pgdg18.04+1))

WARNING: psql major version 11, server major version 12.

         Some psql features might not work.

SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)

Type "help" for help.



postgres=# select inet_server_addr();

 inet_server_addr

------------------

 192.168.30.221

(1 row)



postgres=# \q

[[email protected] ~]# psql -h 192.168.30.201 -U dbapgadmin -W postgres -p 5434

Password:

psql (11.2, server 12.4 (Ubuntu 12.4-1.pgdg18.04+1))

WARNING: psql major version 11, server major version 12.

         Some psql features might not work.

Type "help" for help.



postgres=# select inet_server_addr();

 inet_server_addr

------------------

 192.168.30.222

(1 row)

Điều này cho thấy rằng cả nút chính và nút dự phòng của tôi đều được xác định là nút "đọc cơ sở dữ liệu".

Bây giờ điều này có vẻ rất hứa hẹn như những gì tôi đã nói trước đó. Tuy nhiên, có một phần còn thiếu ở đây mà thực sự là một phần rất quan trọng. Không có cơ chế chuyển đổi dự phòng cơ sở dữ liệu nào sẵn sàng cho kiểu thiết lập này. Tuy nhiên, chúng tôi có Keepalived theo dõi HAProxy và sau đó thực hiện chuyển đổi dự phòng bằng cách chuyển đổi VIP trong trường hợp HAProxy chính bị lỗi hoặc chết. Tuy nhiên, Keepalived không được thiết lập để xử lý thiết lập phức tạp mà PostgreSQL có. Có một cái rất tốt có sẵn và miễn phí để thiết lập cái này. Bạn có thể sử dụng Slony-I, một hệ thống sao chép của bên thứ ba.

Có Cơ chế Chuyển đổi Dự phòng cho Cụm PostgreSQL của bạn

Có nhiều cách để cung cấp cơ chế chuyển đổi dự phòng cho PostgreSQL của bạn. Slony-I hay thường được gọi là Slony là một trong những công cụ phổ biến được sử dụng. Mặc dù Slony yêu cầu thiết lập của bạn phải là một bản sao hợp lý vì nó yêu cầu thiết lập nhà xuất bản / người đăng ký, nhưng nó có thể không lý tưởng cho các thiết lập khác đang sử dụng bản sao truyền trực tuyến tiêu chuẩn. Nhược điểm của việc sử dụng Slony là nó không cung cấp bất kỳ phát hiện tự động nào đối với các hệ thống bị lỗi hoặc không có hỗ trợ hàng rào nút. Do đó, một STONITH thường được gọi là STONITH (bắn vào đầu nút khác hoặc bắn vào đầu nút bị lỗi) về cơ bản loại bỏ lỗi không thành công để tránh các tình huống phân chia não bộ trong đó nhiều nút chính (nút người viết đang hoạt động) đang chấp nhận ghi tại cùng thời gian. Mặc dù điều này có thể được thiết lập một cách thích hợp nhưng vẫn có thể tốn thời gian và phức tạp nếu nó được tạo ra với ít kinh nghiệm và hiểu biết sâu sắc về những tình huống nào nhất định xảy ra cho PostgreSQL khi thảm họa xảy ra. Đối với Slony, việc từ bỏ các giao dịch đã cam kết là một quyết định kinh doanh mà hệ thống cơ sở dữ liệu không thể thực hiện được. Nếu ai đó muốn đặt các lệnh bên dưới thành một tập lệnh được thực thi tự động từ hệ thống giám sát mạng, thì bạn cứ tùy ý sử dụng rằng đó là dữ liệu của bạn và đó là chính sách chuyển đổi dự phòng của bạn.

Ngoài ra, nếu bạn đang tìm kiếm các tùy chọn doanh nghiệp nhưng có thể lấy tiền của bạn với chi phí hợp lý, thì ClusterControl có tính năng tự động khôi phục cho các cụm PostgreSQL. Về cơ bản, tính năng tự động phục hồi giải đáp các vấn đề đã nêu ở trên với Slony. Mặc dù quá trình khôi phục tự động của chúng tôi được kiểm tra tốt nhất với tính năng sao chép trực tuyến và chỉ được hỗ trợ cho loại nhân bản trực tuyến của thiết lập PostgreSQL. Vì vậy, làm thế nào nó hoạt động? Về cơ bản, bạn chỉ cần bật các nút khôi phục tự động giống như bên dưới,

Điều này hỗ trợ hàng rào nút có nghĩa là nó sẽ loại bỏ nút bị lỗi trong trường hợp nút hoạt động trở lại vì một số lý do không được dự đoán trước. Bên cạnh đó, tính năng tự động phục hồi của ClusterControl hỗ trợ khôi phục nút và cụm mà nếu một nút chính hoặc nút phụ vô tình bị tắt hoặc bị giết, ClusterControl sẽ cố gắng khôi phục điều đó, đặc biệt nếu nó xảy ra bên ngoài cửa sổ bảo trì hoặc ngừng hoạt động theo kế hoạch. Tính năng này vừa giúp bạn tránh khỏi nỗi sợ hãi về cơ sở dữ liệu, đồng thời cũng cung cấp cho bạn khả năng giám sát chủ động để thông báo cho bạn về một số thảm họa có thể xảy ra trước khi quá muộn để khôi phục.

Kết luận

Các thiết lập sẵn có cho cụm cơ sở dữ liệu của bạn, đặc biệt là đối với Moodle, có thể khác nhau tùy thuộc vào loại thiết lập và yêu cầu bạn cần. Cho dù đó là hoàn toàn dựa vào các công nghệ mã nguồn mở và miễn phí hay có các tùy chọn khác đáng giá tiền để đầu tư cho ứng dụng doanh nghiệp của bạn miễn là ngân sách có thể đáp ứng được vì nó có thể cung cấp cho bạn tình huống đôi bên cùng có lợi, đặc biệt nếu bạn chỉ muốn tập trung hơn về khía cạnh kinh doanh của mọi thứ hơn là tập trung vào các công cụ khác như quản trị và loại công việc.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Sao chép cơ sở dữ liệu PostgreSQL sang một máy chủ khác

  2. Phương ngữ cần được cung cấp rõ ràng kể từ v4.0.0

  3. Có cách nào để tắt cập nhật / xóa nhưng vẫn cho phép trình kích hoạt thực hiện chúng không?

  4. [Video] Giới thiệu về các kiểu dữ liệu JSON trong PostgreSQL

  5. Làm thế nào để khai báo các biến cục bộ trong postgresql?