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

Cách theo dõi Hiệu suất PostgreSQL 12 với OmniDB - Phần 1

OmniDB là một công cụ quản lý cơ sở dữ liệu đồ họa, mã nguồn mở được phát triển bởi 2ndQuadrant, công ty hàng đầu thế giới về công nghệ và dịch vụ PostgreSQL. OmniDB là một công cụ máy khách toàn cầu, dựa trên trình duyệt có thể quản lý các công cụ cơ sở dữ liệu chính như PostgreSQL, MariaDB, MySQL và Oracle. Các công cụ sắp được hỗ trợ khác bao gồm SQLite, Firebird, MS SQL Server và IBM DB2.

Giống như bất kỳ phần mềm máy khách cơ sở dữ liệu xuất sắc nào, OmniDB cũng trao quyền cho người dùng với một số tính năng tuyệt vời. Chúng bao gồm khả năng tạo và tùy chỉnh trang tổng quan giám sát hiệu suất cơ sở dữ liệu. Trong loạt bài viết gồm hai phần này, chúng ta sẽ tìm hiểu cách sử dụng các đơn vị giám sát tích hợp của OmniDB - thường được gọi là “widget” trong thuật ngữ bảng điều khiển - để xây dựng các bảng điều khiển kiểm tra tình trạng hiệu suất cho một cụm sao chép PostgreSQL 12.

Môi trường thử nghiệm

Môi trường thử nghiệm của chúng tôi là một cụm PostgreSQL 12 hai nút, chạy trong AWS VPC ở khu vực miền đông-1 chúng tôi. VPC trải dài trên ba vùng khả dụng và có ba mạng con. Mỗi mạng con nằm trong một Vùng sẵn sàng riêng biệt (AZ). Nút chính và nút dự phòng nằm ở hai trong số các mạng con này. Các nút đều là loại phiên bản t2.large EC2 và sẽ chạy PostgreSQL mã nguồn mở 12. Nút chính sẽ sao chép sang nút dự phòng.

Cũng sẽ có một “nút giám sát” chạy phiên bản mới nhất của công cụ quản lý cơ sở dữ liệu OmniDB của 2ndQuadrant. Nút này sẽ không phải là một phần của cụm PostgreSQL, nhưng sẽ được lưu trữ trong mạng con thứ ba của VPC, ở một AZ khác. OmniDB sẽ có thể kết nối với cả nút chính và nút chờ và kiểm tra hiệu suất của chúng. Nút OmniDB sẽ là một phiên bản t2.medium EC2.

Tất cả ba nút sẽ chạy Red Hat Enterprise Linux (RHEL) 8. Hình ảnh dưới đây cho thấy kiến ​​trúc đơn giản hóa:

Kịch bản thử nghiệm

Khi chúng tôi đã thiết lập cụm và OmniDB, chúng tôi sẽ đăng ký cả hai nút PostgreSQL trong OmniDB. Sau đó, chúng ta sẽ làm quen với một số đơn vị giám sát tiêu chuẩn trong OmniDB và xem các số liệu hiệu suất từ ​​cả hai nút cụm. Sau đó, chúng tôi sẽ chạy kiểm tra tải trong nút chính bằng pgbench. Tốt nhất, thử nghiệm tải nên được bắt đầu từ một máy riêng biệt, nhưng trong trường hợp này, chúng tôi sẽ chạy nó cục bộ. Sau đó, chúng ta sẽ xem cách trang tổng quan giám sát của OmniDB hiển thị những thay đổi trong các bộ đếm hiệu suất khác nhau khi tải thay đổi.

Thiết lập Môi trường

Bước 1:Cài đặt Cụm sao chép 12 PostgreSQL

Để tạo một cụm PostgreSQL hai nút, chúng tôi đang làm theo các bước được mô tả trong blog 2ndQuadrant đã xuất bản trước đó. Người đọc có thể kiểm tra bài viết này để biết cách chúng tôi đã cài đặt một cụm ba nút với một nút nhân chứng bằng cách sử dụng một sản phẩm 2ndQuadrant khác có tên là repmgr . Đối với thiết lập hiện tại của chúng tôi, chúng tôi đang làm theo các bước tương tự bằng cách sử dụng repmgr để tạo một cụm hai nút thay vì một cụm ba nút. Ngoài ra, cụm sao sẽ không có bất kỳ nút nhân chứng nào. Để đơn giản hóa mọi thứ, bài viết này không hiển thị các bước cài đặt và cấu hình chi tiết.

Khi cụm của chúng tôi được thiết lập, chúng tôi có thể xác nhận nó đang hoạt động bằng cách truy vấn chế độ xem pg_stat_replication từ nút chính:

 CHỌN tên sử dụng, client_addr, application_name, state, sent_lsn, write_lsn, replay_lsnFROM pg_stat_replication; 

Bước 2:Cài đặt và định cấu hình máy chủ OmniDB

OmniDB được truy cập bằng cách sử dụng một URL, có nghĩa là đằng sau hậu trường, nó chạy một máy chủ web của riêng mình. Có hai hương vị của OmniDB:

  • Ứng dụng OmniDB :Điều này thường được chạy từ một máy trạm và hoạt động giống như một ứng dụng máy tính để bàn bình thường. OmniDB chạy máy chủ web trên một cổng ngẫu nhiên và không cần thiết lập thêm.
  • Máy chủ OmniDB :Đây là cách cài đặt OmniDB trên máy chủ mạng cho chế độ nhiều người dùng. Ở chế độ máy chủ, chúng tôi có thể chỉ định số cổng để truy cập URL, mã hóa SSL của URL, cân bằng tải và proxy ngược, quyền truy cập thông qua SSH vào các nút cơ sở dữ liệu và tạo tài khoản người dùng để truy cập.

Đối với kịch bản thử nghiệm của chúng tôi, chúng tôi sẽ cài đặt một máy chủ OmniDB trong nút OmniDB EC2. Đầu tiên, chúng tôi đang tải xuống gói mới nhất từ ​​trang OmniDB:

 # wget https://www.omnidb.org/dist/2.17.0/omnidb-server_2.17.0-centos7-amd64.rpm 

Tiếp theo, chúng ta bắt đầu cài đặt. Ở đây, chúng tôi đang cài đặt OmniDB với tư cách là người dùng root, nhưng bạn có thể sử dụng bất kỳ người dùng nào khác miễn là người dùng đó có các quyền chính xác:

 # rpm -ivh omnidb-server_2.17.0-centos7-amd64.rpm Đang xác minh ... ############################## #### [100%] Đang chuẩn bị ... #################################### [100%] Đang cập nhật / cài đặt ... 1:omnidb-server-2.17.0-0 ################################### [ 100%] 

Khi gói được cài đặt, chúng tôi có thể khởi động OmniDB từ dấu nhắc lệnh:

 # omnidb-server 

Điều này cho thấy máy chủ đang bắt đầu:

 Khởi động OmniDB websocket ... Kiểm tra tính khả dụng của cổng ...  Khởi động máy chủ websocket tại cổng 25482  Khởi động máy chủ OmniDB ... Đang kiểm tra tính khả dụng của cổng ...  Đang khởi động máy chủ OmniDB 2.17.0 tại 127.0.0.1:8000  Bắt đầu di chuyển cơ sở dữ liệu người dùng từ phiên bản 0.0.0 sang phiên bản 2.17.0 ... OmniDB đã di chuyển thành công cơ sở dữ liệu người dùng từ phiên bản 0.0.0 sang phiên bản 2.17.0Mở OmniDB trong trình duyệt yêu thích của bạn Nhấn Ctrl + C để thoát 

Chúng ta có thể thấy OmniDB đã chọn cổng máy chủ web mặc định là 8000 và máy chủ websocket mặc định ở cổng 25482.

Chúng tôi nhấn Ctrl + C để dừng quá trình máy chủ và duyệt đến thư mục chính của người dùng root. Chúng tôi có thể thấy có một thư mục ẩn tên là .omnidb . Bên dưới thư mục này, có một thư mục con được gọi là omnidb-server . Bên trong thư mục con omnidb-server, có một số tệp:

 #  ls -la ~  drwxr-xr-x. 3 root root 27 Jun 13 02:49 .omnidb  …… #  ls -la ~ / .omnidb  drwxr-xr-x. 2 root root 106 Jun 13 02:49 omnidb-server  #  ls -la ~ / .omnidb / omnidb-server /  … -Rw-r - r--. 1 root root 131072 Jun 13 02:49 db.sqlite3  -rw-r - r--. 1 root root 1209 Jun 13 02:49 omnidb.conf   -rw-r - r--. 1 root root 116736 Jun 13 02:49 omnidb.db  -rw-r - r--. 1 root root 0 Jun 13 02:49 omnidb.db.bak_2.17.0-rw-r - r--. 1 root root 579 Jun 13 02:49 omnidb.log 

Khi quá trình máy chủ bắt đầu, OmniDB sẽ khởi tạo các tệp này. Cơ sở dữ liệu siêu dữ liệu OmniDB được gọi là omnidb.db . Đây là cơ sở dữ liệu SQLite và chứa thông tin về các kết nối cơ sở dữ liệu, người dùng OmniDB, v.v. omnidb.conf tệp chứa các tùy chọn cấu hình cho máy chủ OmniDB. Nếu chúng tôi mở tệp này trong một trình chỉnh sửa, nó sẽ trông giống như sau:

 # Tập tin cấu hình máy chủ OmniDB [máy chủ web] # Máy chủ web lắng nghe địa chỉ nào, 0.0.0.0 lắng nghe tất cả các địa chỉ liên kết với máy  nghe_address =127.0.0.1  # Cổng máy chủ trang web, nếu cổng đang được sử dụng, một cổng ngẫu nhiên khác sẽ được chọn  listening_port =8000  # Cổng websocket, nếu cổng đang được sử dụng, một cổng ngẫu nhiên khác sẽ được chọn  websocket_port =25482  # Cổng Websocket bên ngoài, sử dụng tham số này nếu OmniDB không được ứng dụng khách nhìn thấy trực tiếp # external_websocket_port =25482 # Tham số bảo mật # is_ssl =True yêu cầu tham số ssl_certificate_file và ssl_key_file # Điều này rất được khuyến khích để bảo vệ thông tin  is_ssl =False   ssl_certificate_file =/ path / to / cert_file   ssl_key_file =/ path / to / key_file  # Nguồn gốc đáng tin cậy, sử dụng tham số này nếu OmniDB được định cấu hình bằng SSL và đang được truy cập bởi một miền kháccsrf_trusted_origins =origin1, origin2, origin3 # Đường dẫn url để truy cập OmniDB, mặc định là trống  đường dẫn = [queryserver] # Số chuỗi tối đa có thể được sử dụng bởi mỗi yêu cầu tìm kiếm đối tượng nâng cao  thread_pool_max_workers =2  # Số giây giữa mỗi lần yêu cầu mật khẩu nhắc nhở. Mặc định:30 phút  pwd_timeout_total =1800  

OmniDB chạy hai quy trình máy chủ. Một là máy chủ web hiển thị giao diện người dùng, một là máy chủ websocket. Máy chủ websocket được sử dụng bởi một số tính năng của ứng dụng, như truy vấn, bảng điều khiển và gỡ lỗi.

Từ tệp cấu hình, chúng ta có thể thấy rằng theo mặc định máy chủ OmniDB chấp nhận lưu lượng cục bộ (127.0.0.1) trên cổng máy chủ web 8000. Chúng tôi sẽ thay đổi điều này thành TẤT CẢ địa chỉ IP. Trừ khi máy sử dụng proxy ngược, bạn rất nên sử dụng mã hóa SSL cho các kết nối HTTP tới máy chủ. Tuy nhiên, trong ví dụ của chúng tôi, chúng tôi sẽ để lại is_ssl tham số thành “False” vì chúng tôi sẽ phá bỏ chiếc máy này sau khi các bài kiểm tra của chúng tôi được thực hiện xong. Chúng tôi cũng sẽ thay đổi cổng máy chủ web thành 8080 và giữ cổng máy chủ websocket ở giá trị mặc định là 25482.

Sau khi thực hiện các thay đổi, tệp cấu hình sẽ giống như sau:

 [webserver] listening_address =0.0.0.0listening_port =8080websocket_port =25482is_ssl =Falsessl_certificate_file =/ path / to / cert_filessl_key_file =/ path / to / key_filecsrf_trusted_origins =origin1, threadout_ 2, origin3path =prepool> 

Với các thay đổi được thực hiện và lưu, chúng tôi chạy một ứng dụng khác có tên là omnidb-config-server . Công cụ này có thể được sử dụng để thực hiện một số cấu hình bổ sung như:

  • Hút bụi cơ sở dữ liệu OmniDB của cơ sở dữ liệu SQLite
  • Đặt lại cơ sở dữ liệu cũ và tạo một cơ sở dữ liệu mới
  • Xóa các tệp tạm thời
  • Tạo thư mục chính mới cho cơ sở dữ liệu và tệp cấu hình
  • Tạo siêu người dùng để đăng nhập vào OmniDB

Mặc dù chúng tôi sẽ đăng nhập vào OmniDB bằng tài khoản người dùng quản trị được tạo theo mặc định, chúng tôi sẽ tạo một siêu người dùng khác tại đây. Điều này có thể hữu ích nếu chúng tôi muốn tạo tài khoản DBA cá nhân trong OmniDB. Đoạn mã dưới đây cho thấy điều này:

 # omnidb-config-server --createsuperuser =dba [email protected]$$w0rd123 Tạo siêu người dùng ... Đã tạo siêu người dùng. 

Với superuser được tạo, chúng tôi bắt đầu lại quy trình omnidb-server:

 # omnidb-server Bắt đầu OmniDB websocket ... Đang kiểm tra tính khả dụng của cổng ... Đang khởi động máy chủ websocket tại cổng 25482. Khởi động máy chủ OmniDB ... Đang kiểm tra tính khả dụng của cổng ... Đang khởi động máy chủ OmniDB 2.17.0 tại 0.0.0.0:8080. Cơ sở dữ liệu người dùng phiên bản 2.17.0 đã khớp với phiên bản máy chủ. Mở OmniDB trong trình duyệt yêu thích của bạn Nhấn Ctrl + C để thoát 

Trước khi chúng tôi truy cập giao diện OmniDB, chúng tôi cũng thêm cổng 8080 và cổng 25482 vào nhóm bảo mật của phiên bản EC2:

Bước 3:Truy cập Giao diện OmniDB

Duyệt đến địa chỉ công cộng và nút OmniDB hiện hiển thị màn hình đăng nhập:

Chúng tôi chỉ định tên người dùng mặc định là “admin” và mật khẩu của nó, “admin”. Điều này cho phép chúng tôi đăng nhập vào giao diện OmniDB chính. Màn hình đầu tiên được hiển thị bên dưới:

Tiếp theo, chúng ta nhấp vào biểu tượng “Quản lý người dùng” ở góc trên cùng bên phải của màn hình:

Và thay đổi mật khẩu mặc định của người dùng quản trị:

Sau khi hoàn tất, chúng ta nhấp vào nút “Lưu dữ liệu” để cập nhật mật khẩu. Như bạn thấy, chúng tôi cũng có thể tạo người dùng mới từ màn hình này.

Từ góc trên bên trái của màn hình, chúng tôi nhấp vào liên kết “Kết nối”, sau đó từ hộp thoại hiện ra, nhấp vào nút “Kết nối mới”:

Sau đó, chúng tôi chỉ định chi tiết kết nối cho nút PostgreSQL chính và nhấp vào nút “Lưu dữ liệu”:

Sau khi kết nối được lưu, chúng tôi nhấp vào biểu tượng kết nối (dấu tích màu xanh lục) từ cột “Tác vụ”.

Thao tác này sẽ mở ra một tab mới hiển thị kết nối cơ sở dữ liệu. Như được hiển thị ở đây, chúng tôi được kết nối với nút PostgreSQL chính tại đây:

Chúng tôi làm theo quy trình tương tự để đăng ký nút chờ:

Bước 4:Khôi phục cơ sở dữ liệu mẫu

Bây giờ chúng tôi đang khôi phục một cơ sở dữ liệu mẫu trong phiên bản PostgreSQL chính. Cơ sở dữ liệu này được gọi là “DVDRental” và có thể tải xuống miễn phí từ trang PostgreSQL Tutorial. Chúng tôi đã giải nén tệp đã tải xuống và trích xuất các tệp nguồn vào một thư mục con trong thư mục / tmp của nút chính:

 [[email protected] dvdrental] # ls -latotal 2796drwxr-xr-x. 2 gốc root 280 Jun 16 11:32 .drwxrwxrwt. 9 gốc rễ 257 Jun 16 11:31 ..- rw -------. 1 postgres postgres 57147 Tháng Năm 12 2019 3055.dat-rw -------. 1 postgres postgres 8004 Tháng Năm 12 2019 3057.dat-rw -------. 1 postgres postgres 483 Tháng Năm 12 2019 3059.dat-rw -------. 1 postgres postgres 333094 12 Tháng Năm 2019 3061.dat-rw -------. 1 postgres postgres 149469 12 Tháng Năm 2019 3062.dat-rw -------. 1 postgres postgres 26321 Tháng Năm 12 2019 3063.dat-rw -------. 1 postgres postgres 46786 12 Tháng Năm 2019 3065.dat-rw -------. 1 postgres postgres 21762 ngày 12 tháng 5 năm 2019 3067.dat-rw -------. 1 postgres postgres 3596 12 Tháng Năm 2019 3069.dat-rw -------. 1 postgres postgres 140422 Tháng Năm 12 2019 3071.dat-rw -------. 1 postgres postgres 263 Tháng Năm 12 2019 3073.dat-rw -------. 1 postgres postgres 718644 Tháng Năm 12 2019 3075.dat-rw -------. 1 postgres postgres 1214420 Ngày 12 tháng 5 năm 2019 3077.dat-rw -------. 1 postgres postgres 271 Tháng Năm 12 2019 3079.dat-rw -------. 1 postgres postgres 57 May 12, 2019 3081.dat-rw -------. 1 postgres postgres 45872 ngày 12 tháng 5 năm 2019 restore.sql-rw -------. 1 postgres postgres 55111 May 12, 2019 toc.dat 

Tiếp theo, chúng tôi chạy các lệnh shell sau trong phiên bản PostgreSQL chính (PG-Node1). Các lệnh này thực hiện một số thay đổi đối với tệp restore.sql:

  • Xóa tất cả các lần xuất hiện của “$$ PATH $$ /”. Điều này đảm bảo tập lệnh có thể tìm thấy tất cả các tệp dữ liệu trong cùng một thư mục
  • Thay đổi tất cả các lần xuất hiện của “English_United States.1252” thành “en_US.UTF-8”. Điều này đảm bảo không có lỗi do thiếu ngôn ngữ khi tập lệnh chạy.
  • Thay đổi lệnh “DROP DATBASE dvdrental” thành “DROP DATBASE IF EXISTS dvdrental” để không có lỗi cơ sở dữ liệu không hợp lệ hiển thị.
 # sed -i 's / $$ PATH $$ \ // \ / tmp \ / dvdrental \ // g' /tmp/dvdrental/restore.sql# sed -i 's / English_United States.1252 / en_US .UTF-8 / g '/tmp/dvdrental/restore.sql# sed -i' s / DROP DATABASE dvdrental; / DROP DATABASE NẾU TỒN TẠI dvdrental; / g '/tmp/dvdrental/restore.sql 

Tiếp theo, chúng tôi chuyển sang người dùng postgres và chạy lệnh sau từ dấu nhắc trình bao:

 $ psql -U postgres -d postgres -f /tmp/dvdrental/restore.sql 

Điều này khôi phục cơ sở dữ liệu mẫu trong nút chính. Nếu chúng tôi kiểm tra từ OmniDB, chúng tôi có thể thấy cơ sở dữ liệu được tạo:

Kết luận

Bây giờ chúng ta có một cụm PostgreSQL hoạt động đầy đủ và một phiên bản OmniDB đang chạy trong AWS. OmniDB có thể kết nối với cả hai nút của cụm. Chúng tôi cũng đã khôi phục cơ sở dữ liệu trong nút chính đang được sao chép sang chế độ chờ.

Môi trường đã thiết lập xong. Trong phần thứ hai của bài viết này, chúng tôi sẽ bắt đầu tạo trang tổng quan giám sát hiệu suất cho phiên bản chính.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Cách duy trì dữ liệu trong cơ sở dữ liệu postgres dày đặc bằng cách sử dụng khối lượng

  2. Chuyển từ Oracle sang PostgreSQL - Điều bạn nên biết

  3. Cách chèn vào mảng trong PostgreSQL

  4. Chỉ mục đa cột trên 3 trường có kiểu dữ liệu không đồng nhất

  5. Sử dụng row_to_json () với các phép nối lồng nhau