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

Cơ sở dữ liệu PostgreSQL của tôi đã hết dung lượng đĩa

Dung lượng đĩa ngày nay là một yêu cầu tài nguyên. Thông thường, bạn sẽ muốn lưu trữ dữ liệu lâu nhất có thể, nhưng đây có thể là một vấn đề nếu bạn không thực hiện các hành động cần thiết để ngăn chặn sự cố "hết dung lượng đĩa" tiềm ẩn.

Trong blog này, chúng ta sẽ xem cách chúng ta có thể phát hiện sự cố này đối với PostgreSQL, ngăn chặn nó và nếu quá muộn, một số tùy chọn có thể sẽ giúp bạn khắc phục sự cố.

Cách xác định các vấn đề về dung lượng đĩa PostgreSQL

Nếu không may, bạn gặp phải trường hợp hết dung lượng đĩa này, bạn sẽ có thể thấy một số lỗi trong nhật ký cơ sở dữ liệu PostgreSQL:

2020-02-20 19:18:18.131 UTC [4400] LOG:  could not close temporary statistics file "pg_stat_tmp/global.tmp": No space left on device

hoặc thậm chí trong nhật ký hệ thống của bạn:

Feb 20 19:29:26 blog-pg1 rsyslogd: imjournal: fclose() failed for path: '/var/lib/rsyslog/imjournal.state.tmp': No space left on device [v8.24.0-41.el7_7.2 try http://www.rsyslog.com/e/2027 ]

PostgreSQL có thể tiếp tục hoạt động trong một thời gian chạy các truy vấn chỉ đọc, nhưng cuối cùng, nó sẽ không thành công khi cố gắng ghi vào đĩa, sau đó bạn sẽ thấy một cái gì đó như thế này trong phiên khách hàng của mình:

WARNING:  terminating connection because of crash of another server process

DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.

HINT:  In a moment you should be able to reconnect to the database and repeat your command.

server closed the connection unexpectedly

This probably means the server terminated abnormally

before or while processing the request.

The connection to the server was lost. Attempting reset: Failed.

Sau đó, nếu bạn xem xét dung lượng ổ đĩa, bạn sẽ có kết quả không mong muốn này…

$ df -h

Filesystem                        Size Used Avail Use% Mounted on

/dev/mapper/pve-vm--125--disk--0   30G 30G 0 100% /

Cách Ngăn chặn Vấn đề Dung lượng Ổ đĩa PostgreSQL

Cách chính để ngăn chặn loại sự cố này là theo dõi việc sử dụng dung lượng đĩa và tốc độ tăng trưởng sử dụng cơ sở dữ liệu hoặc đĩa. Đối với điều này, biểu đồ phải là một cách thân thiện để theo dõi sự gia tăng dung lượng đĩa:

Và tương tự đối với tăng trưởng cơ sở dữ liệu:

Một điều quan trọng khác cần theo dõi là trạng thái sao chép. Nếu bạn có một bản sao và vì lý do nào đó, bản sao này ngừng hoạt động, tùy thuộc vào cấu hình, có thể PostgreSQL lưu trữ tất cả các tệp WAL để khôi phục bản sao khi nó hoạt động trở lại.

Tất cả hệ thống giám sát này sẽ vô nghĩa nếu không có hệ thống cảnh báo để biết khi bạn cần thực hiện các hành động:

Cách khắc phục sự cố về dung lượng đĩa của PostgreSQL

Chà, nếu bạn đang gặp phải vấn đề hết dung lượng đĩa này ngay cả khi hệ thống giám sát và cảnh báo được triển khai (hoặc không), thì có nhiều tùy chọn để cố gắng khắc phục sự cố này mà không bị mất dữ liệu (hoặc ít hơn càng tốt).

Tiêu tốn dung lượng đĩa của bạn là gì?

Bước đầu tiên phải xác định dung lượng đĩa của tôi ở đâu. Cách tốt nhất là có các phân vùng riêng biệt, ít nhất một phân vùng riêng biệt để lưu trữ cơ sở dữ liệu của bạn, vì vậy bạn có thể dễ dàng xác nhận xem cơ sở dữ liệu hoặc hệ thống của bạn có đang sử dụng quá nhiều dung lượng đĩa hay không. Một ưu điểm khác của việc này là giảm thiểu thiệt hại. Nếu phân vùng gốc của bạn đã đầy, cơ sở dữ liệu của bạn vẫn có thể ghi vào phân vùng của chính nó mà không gặp sự cố.

Sử dụng Không gian Cơ sở dữ liệu

Bây giờ chúng ta hãy xem một số lệnh hữu ích để kiểm tra việc sử dụng dung lượng đĩa cơ sở dữ liệu của bạn.

Một cách cơ bản để kiểm tra việc sử dụng không gian cơ sở dữ liệu là kiểm tra thư mục dữ liệu trong hệ thống tệp:

$ du -sh /var/lib/pgsql/11/data/

819M /var/lib/pgsql/11/data/

Hoặc nếu bạn có một phân vùng riêng cho thư mục dữ liệu của mình, bạn có thể sử dụng trực tiếp df -h.

Lệnh PostgreSQL “\ l +” liệt kê các cơ sở dữ liệu thêm thông tin kích thước:

$ postgres=# \l+

                                                               List of databases

   Name    | Owner   | Encoding | Collate | Ctype |   Access privileges | Size | Tablespace

|                Description

-----------+----------+-----------+---------+-------+-----------------------+---------+------------

+--------------------------------------------

 postgres  | postgres | SQL_ASCII | C       | C | | 7965 kB | pg_default

| default administrative connection database

 template0 | postgres | SQL_ASCII | C       | C | =c/postgres +| 7817 kB | pg_default

| unmodifiable empty database

           |          | |         | | postgres=CTc/postgres |         |

|

 template1 | postgres | SQL_ASCII | C       | C | =c/postgres +| 7817 kB | pg_default

| default template for new databases

           |          | |         | | postgres=CTc/postgres |         |

|

 world     | postgres | SQL_ASCII | C       | C | | 8629 kB | pg_default

|

(4 rows)

Sử dụng pg_database_size và tên cơ sở dữ liệu, bạn có thể thấy kích thước cơ sở dữ liệu:

postgres=# SELECT pg_database_size('world');

 pg_database_size

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

          8835743

(1 row)

Và việc sử dụng pg_size_pretty để xem giá trị này theo cách con người có thể đọc được thậm chí còn tốt hơn:

postgres=# SELECT pg_size_pretty(pg_database_size('world'));

 pg_size_pretty

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

 8629 kB

(1 row)

Khi bạn biết vị trí của khoảng trống, bạn có thể thực hiện hành động tương ứng để sửa nó. Hãy nhớ rằng chỉ xóa các hàng là không đủ để khôi phục dung lượng đĩa, bạn sẽ cần chạy VACUUM hoặc VACUUM FULL để hoàn thành tác vụ.

Tệp nhật ký

Cách dễ nhất để khôi phục dung lượng ổ đĩa là xóa các tệp nhật ký. Bạn có thể kiểm tra thư mục nhật ký PostgreSQL hoặc thậm chí nhật ký hệ thống để xác minh xem bạn có thể giành được một số dung lượng từ đó hay không. Nếu bạn có một cái gì đó như thế này:

$ du -sh /var/lib/pgsql/11/data/log/

18G /var/lib/pgsql/11/data/log/

Bạn nên kiểm tra nội dung thư mục để xem liệu có vấn đề xoay vòng / lưu giữ nhật ký hoặc điều gì đó đang xảy ra trong cơ sở dữ liệu của bạn hay không và ghi nó vào nhật ký.

$ ls -lah /var/lib/pgsql/11/data/log/

total 18G

drwx------  2 postgres postgres 4.0K Feb 21 00:00 .

drwx------ 21 postgres postgres 4.0K Feb 21 00:00 ..

-rw-------  1 postgres postgres  18G Feb 21 14:46 postgresql-Fri.log

-rw-------  1 postgres postgres 9.3K Feb 20 22:52 postgresql-Thu.log

-rw-------  1 postgres postgres 3.3K Feb 19 22:36 postgresql-Wed.log

Trước khi xóa nhật ký, nếu bạn có một nhật ký lớn, cách tốt là giữ khoảng 100 dòng cuối cùng rồi xóa nó. Vì vậy, bạn có thể kiểm tra điều gì đang xảy ra sau khi tạo dung lượng trống.

$ tail -100 postgresql-Fri.log > /tmp/log_temp.log

Và sau đó:

$ cat /dev/null > /var/lib/pgsql/11/data/log/postgresql-Fri.log

Nếu bạn chỉ xóa nó bằng “rm” và không gian tệp nhật ký đang được sử dụng bởi máy chủ PostgreSQL (hoặc một dịch vụ khác) sẽ không được giải phóng, vì vậy bạn nên cắt bớt tệp này bằng cách sử dụng con mèo / thay vào đó lệnh dev / null.

Hành động này chỉ dành cho PostgreSQL và tệp nhật ký hệ thống. Không xóa nội dung pg_wal hoặc một tệp PostgreSQL khác vì nó có thể gây ra thiệt hại nghiêm trọng cho cơ sở dữ liệu của bạn.

Nởn

Trong hoạt động PostgreSQL bình thường, các bộ giá trị bị xóa hoặc bị che khuất bởi bản cập nhật sẽ không bị xóa khỏi bảng về mặt vật lý; chúng hiện diện cho đến khi một VACUUM được thực hiện. Vì vậy, cần phải thực hiện định kỳ VACUUM (AUTOVACUUM), đặc biệt là trong các bảng được cập nhật thường xuyên.

Vấn đề ở đây là không gian không được trả lại cho hệ điều hành chỉ sử dụng VACUUM, nó chỉ có sẵn để sử dụng trong cùng một bảng.

VACUUM FULL ghi lại bảng thành một tệp đĩa mới, trả lại không gian chưa sử dụng cho hệ điều hành. Thật không may, nó yêu cầu một khóa riêng trên mỗi bảng khi nó đang chạy.

Bạn nên kiểm tra các bảng để xem liệu quy trình VACUUM (FULL) có được yêu cầu hay không.

Vị trí sao chép

Nếu bạn đang sử dụng vị trí sao chép và nó không hoạt động vì một số lý do:

postgres=# SELECT slot_name, slot_type, active FROM pg_replication_slots;

 slot_name | slot_type | active

-----------+-----------+--------

 slot1     | physical  | f

(1 row)

Có thể là vấn đề đối với dung lượng ổ đĩa của bạn vì nó sẽ lưu trữ các tệp WAL cho đến khi tất cả các nút chờ nhận được chúng.

Cách khắc phục là khôi phục bản sao (nếu có thể) hoặc xóa vị trí:

postgres=# SELECT pg_drop_replication_slot('slot1');

 pg_drop_replication_slot

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

(1 row)

Vì vậy, không gian mà các tệp WAL sử dụng sẽ được giải phóng.

Kết luận

Như chúng tôi đã đề cập, hệ thống giám sát và cảnh báo là chìa khóa để tránh những loại vấn đề này. Bằng cách này, ClusterControl có thể giúp bạn thiết lập và chạy hệ thống của mình, gửi cho bạn các cảnh báo khi cần thiết hoặc thậm chí thực hiện hành động khôi phục để giữ cho cụm cơ sở dữ liệu của bạn hoạt động. Bạn cũng có thể triển khai / nhập các công nghệ cơ sở dữ liệu khác nhau và mở rộng chúng nếu cần.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Buổi gặp mặt PostgreSQL ở Prague

  2. Hàm PostgreSQL / Thủ tục được lưu trữ CURRENT_TIMESTAMP không thay đổi

  3. Thực hiện các giao dịch trong khi thực hiện một hàm postgreql

  4. SQLAlchemy nhiều khóa ngoại trong một lớp được ánh xạ tới cùng một khóa chính

  5. Làm cách nào để chuyển ứng dụng ray hiện có của tôi lên heroku? (sqlite đến postgres)