Cấu hình Authentication và Quản lý User
Bước đầu tiên để bảo mật TimescaleDB là giới hạn truy cập từ mạng ngoài và tạo tài khoản người dùng có quyền hạn cụ thể. Mặc định PostgreSQL cho phép kết nối local, nhưng để production cần cấu hình rõ ràng trong file pg_hba.conf.
Sửa file cấu hình /etc/postgresql/16/main/pg_hba.conf để chỉ cho phép kết nối từ IP nội bộ hoặc localhost thông qua chứng thực md5 hoặc scram-sha-256.
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all peer
# IPv4 local connections:
host all all 127.0.0.1/32 scram-sha-256
host all all ::1/128 scram-sha-256
# IPv4 network connections (chỉ cho phép subnet nội bộ 192.168.1.0/24)
host timescaledb timescale_user 192.168.1.0/24 scram-sha-256
Khởi động lại dịch vụ PostgreSQL để áp dụng thay đổi. Kết quả mong đợi là dịch vụ chạy lại mà không báo lỗi, và bạn không thể kết nối từ IP bên ngoài không nằm trong danh sách cho phép.
sudo systemctl restart postgresql@16-main
Tạo user mới timescale_user với mật khẩu mạnh và cấp quyền SELECT trên schema public và timescaledb. Điều này giúp tách biệt quyền admin và quyền đọc dữ liệu.
sudo -u postgres psql -c "CREATE USER timescale_user WITH PASSWORD 'YourSecurePassword123!';"
sudo -u postgres psql -c "GRANT CONNECT ON DATABASE timescaledb TO timescale_user;"
sudo -u postgres psql -c "GRANT USAGE ON SCHEMA public TO timescale_user;"
sudo -u postgres psql -c "GRANT SELECT ON ALL TABLES IN SCHEMA public TO timescale_user;"
Verify bằng cách đăng nhập vào database với user mới. Kết quả mong đợi là bạn có thể truy vấn dữ liệu nhưng bị từ chối khi thực hiện lệnh DROP hoặc DELETE trên các bảng hệ thống.
psql -h 127.0.0.1 -U timescale_user -d timescaledb -c "SELECT version();"
Sao lưu và Khôi phục Dữ liệu TimescaleDB
TimescaleDB là extension của PostgreSQL, do đó sử dụng công cụ chuẩn pg_dump và pg_restore vẫn hoạt động hiệu quả. Tuy nhiên, cần lưu ý về việc backup các hypertable để đảm bảo tính toàn vẹn của cấu trúc phân vùng.
Thực hiện sao lưu toàn bộ database timescaledb sang file .sql. Tham số --verbose giúp xem log chi tiết và --format=custom tạo file nhị phân nhỏ hơn và hỗ trợ khôi phục từng đối tượng.
sudo -u postgres pg_dump --format=custom --verbose --file=/var/backups/timescaledb_backup_$(date +%F).dump timescaledb
Kiểm tra file backup đã được tạo và nén lại bằng gzip để tiết kiệm dung lượng. Kết quả mong đợi là file dump được tạo ra với kích thước hợp lý so với dữ liệu thực tế.
ls -lh /var/backups/timescaledb_backup_*.dump
gzip /var/backups/timescaledb_backup_*.dump
Khôi phục dữ liệu từ file backup vào một database mới hoặc database hiện tại. Lưu ý: Nếu khôi phục vào database mới, cần tạo database đó trước. Lệnh --clean sẽ xóa các đối tượng cũ trước khi tạo mới, tránh xung đột dữ liệu.
sudo -u postgres createdb timescaledb_restore
sudo -u postgres pg_restore --clean --if-not-exists --verbose --dbname=timescaledb_restore /var/backups/timescaledb_backup_*.dump.gz
Verify quá trình khôi phục bằng cách đếm số lượng records trong hypertable chính. Kết quả mong đợi là số lượng records trong database mới bằng với số lượng trước khi backup.
sudo -u postgres psql -d timescaledb_restore -c "SELECT count(*) FROM conditions;"
Kiểm tra Cấu trúc Phân vùng với ts_debug
TimescaleDB tự động chia nhỏ hypertable thành các chunk (phân vùng) dựa trên thời gian và không gian. Hàm ts_debug trong schema timescaledb_debug giúp kiểm tra sức khỏe và cấu trúc của các chunk này mà không cần query trực tiếp vào catalog.
Sử dụng hàm ts_debug_hypertable để xem thông tin tổng quan về hypertable conditions, bao gồm số lượng chunk, kích thước, và chiến lược phân vùng. Kết quả mong đợi là một bảng chi tiết hiển thị các chunk đã được tạo.
sudo -u postgres psql -d timescaledb -c "SELECT * FROM timescaledb_debug.ts_debug_hypertable('conditions');"
Kiểm tra trạng thái nén (compression) của các chunk bằng hàm ts_debug_chunk_compression_status. Điều này xác nhận xem chiến lược compression đã được kích hoạt và áp dụng cho các chunk cũ chưa. Kết quả mong đợi là các chunk cũ có trạng thái COMPRESSED hoặc COMPRESSING.
sudo -u postgres psql -d timescaledb -c "SELECT chunk_name, compression_status, compression_state FROM timescaledb_debug.ts_debug_chunk_compression_status('conditions');"
Phân tích chi tiết một chunk cụ thể để kiểm tra xem dữ liệu đã được tổ chức như thế nào bên trong. Sử dụng ts_debug_chunk để xem metadata của chunk đó. Kết quả mong đợi là thông tin về thời gian bắt đầu/kết thúc của chunk và kích thước trên disk.
sudo -u postgres psql -d timescaledb -c "SELECT * FROM timescaledb_debug.ts_debug_chunk('conditions', '_hypertable_1_chunk_2');"
Giải quyết các lỗi phổ biến: OOM, Deadlocks và Disk Full
Vấn đề OOM (Out Of Memory) thường xảy ra khi thực hiện các truy vấn phức tạp hoặc khi hệ thống không đủ RAM để xử lý buffer pool. Cần điều chỉnh tham số shared_buffers và work_mem trong postgresql.conf.
Chỉnh sửa file /etc/postgresql/16/main/postgresql.conf để giới hạn work_mem và tăng shared_buffers lên khoảng 25% tổng RAM. Điều này ngăn PostgreSQL tiêu thụ hết RAM của hệ thống khi chạy query lớn.
# Ví dụ cho server 16GB RAM
shared_buffers = 4GB
work_mem = 64MB
maintenance_work_mem = 1GB
max_connections = 100
Khởi động lại PostgreSQL để áp dụng. Kết quả mong đợi là hệ thống ổn định hơn, không bị OOM Killer giết tiến trình postgres khi có nhiều truy vấn song song.
sudo systemctl restart postgresql@16-main
Deadlocks xảy ra khi hai transaction giữ khóa trên các tài nguyên khác nhau và chờ đợi lẫn nhau. Để phát hiện, bật log deadlocks trong postgresql.conf và kiểm tra log file.
# Thêm vào postgresql.conf
log_lock_waits = on
deadlock_timeout = 1s
Kiểm tra log để tìm dòng ERROR: deadlock detected. Khi xảy ra deadlock, PostgreSQL tự động rollback transaction gây ra deadlock để giải phóng khóa. Kết quả mong đợi là bạn thấy log chi tiết về các transaction bị xung đột.
sudo tail -f /var/log/postgresql/postgresql-16-main.log | grep -i deadlock
Vấn đề Disk Full thường do dữ liệu tăng quá nhanh hoặc retention policy chưa được cấu hình đúng. Kiểm tra dung lượng disk và kích thước database để xác định nguyên nhân.
df -h
sudo -u postgres psql -c "SELECT pg_size_pretty(pg_database_size('timescaledb'));"
Xử lý tình trạng Disk Full bằng cách kích hoạt chính sách retention (giữ lại dữ liệu 90 ngày) để tự động xóa các chunk cũ. Nếu cần giải quyết ngay lập tức, có thể xóa các chunk đã qua hạn thủ công bằng hàm add_retention_policy và chạy retention.
sudo -u postgres psql -d timescaledb -c "SELECT add_retention_policy('conditions', INTERVAL '90 days');"
sudo -u postgres psql -d timescaledb -c "SELECT timescaledb_experimental.force_retention('conditions');"
Verify rằng dữ liệu cũ đã bị xóa và dung lượng disk đã được giải phóng. Kết quả mong đợi là kích thước database giảm xuống và các chunk cũ biến mất trong danh sách ts_debug_hypertable.
sudo -u postgres psql -d timescaledb -c "SELECT pg_size_pretty(pg_database_size('timescaledb'));"
sudo -u postgres psql -d timescaledb -c "SELECT * FROM timescaledb_debug.ts_debug_hypertable('conditions') WHERE chunk_name LIKE '%_chunk_%';"
Điều hướng series:
Mục lục: Series: Triển khai Database Time-Series với TimescaleDB và Ubuntu 24.04
« Phần 5: Truy vấn dữ liệu chuỗi thời gian với Continuous Aggregate