如何在Linux系统中安装和配置PostgreSQL？快速搭建可靠数据库的教程-LINUX-PHP中文网

答案：在Linux系统上安装PostgreSQL需根据发行版选择包管理器安装并初始化数据库集群，随后配置网络监听与访问权限。具体步骤包括使用apt或dnf安装postgresql及相关组件，手动执行初始化（如RHEL系），启动服务后切换至postgres用户设置密码，创建专用用户和数据库，修改postgresql.conf中listen_addresses以允许远程连接，调整pg_hba.conf实现基于IP、用户和认证方法的访问控制，推荐使用scram-sha-256加密方式并避免trust认证，最后重启服务生效配置。为确保安全，应遵循最小权限原则，设置强密码，结合防火墙限制访问源，启用SSL加密通信，定期备份并更新系统。不同发行版在包名、初始化命令及配置路径上略有差异，性能优化则涉及shared_buffers、work_mem等参数调优，合理使用索引，开启autovacuum及硬件升级。

如何在linux系统中安装和配置postgresql？快速搭建可靠数据库的教程

在Linux系统上安装和配置PostgreSQL，核心步骤在于利用系统包管理器完成安装，随后初始化数据库集群（如果包管理器未自动执行），并着手调整访问权限与网络监听设置。这不仅是搭建一个可靠数据库的基础，更是后续所有数据操作的起点。

解决方案

要快速搭建PostgreSQL数据库，首先需要根据你的Linux发行版选择合适的安装方式，然后进行必要的配置以确保其可用性和安全性。

对于基于Debian/Ubuntu的系统，通常的安装流程是：

sudo apt update
sudo apt install postgresql postgresql-contrib

登录后复制

postgresql-contrib

登录后复制

包包含了一些有用的附加模块和工具，建议一并安装。

对于基于RHEL/CentOS/Fedora的系统，可以使用

dnf

登录后复制

（或旧版

yum

登录后复制

）：

sudo dnf install postgresql-server postgresql-contrib
sudo postgresql-setup --initdb # 这一步在某些版本中可能需要手动执行，用于初始化数据库集群
sudo systemctl enable postgresql
sudo systemctl start postgresql

登录后复制

安装完成后，PostgreSQL服务通常会自动启动并创建一个名为

postgres

登录后复制

的默认超级用户。这个用户是数据库管理的关键，但它默认只在系统层面上存在，且没有密码。

核心配置步骤：

切换到
```
postgres
```
登录后复制
用户并设置密码： 这是最关键的第一步。默认情况下，你只能通过系统用户
```
postgres
```
登录后复制
来访问数据库。
```
sudo -i -u postgres
psql
```
登录后复制
进入
```
psql
```
登录后复制
命令行界面后，为数据库的
```
postgres
```
登录后复制
用户设置一个强密码：
```
\password postgres
```
登录后复制
输入并确认你的密码。完成设置后，输入
```
\q
```
登录后复制
退出
```
psql
```
登录后复制
，然后输入
```
exit
```
登录后复制
退出
```
postgres
```
登录后复制
系统用户。
创建新的数据库用户和数据库（可选但推荐）： 直接使用
```
postgres
```
登录后复制
超级用户进行日常操作并不安全。最好为你的应用或特定任务创建专用用户和数据库。
```
sudo -i -u postgres
psql
```
登录后复制
在
```
psql
```
登录后复制
中：
```
CREATE USER your_app_user WITH PASSWORD 'your_strong_password';
CREATE DATABASE your_app_db OWNER your_app_user;
GRANT ALL PRIVILEGES ON DATABASE your_app_db TO your_app_user;
```
登录后复制
根据需要，你可能还需要为该用户授予对特定表的权限。
配置网络监听和客户端认证： PostgreSQL有两个主要的配置文件：
```
postgresql.conf
```
登录后复制
和
```
pg_hba.conf
```
登录后复制
。它们通常位于
```
/etc/postgresql/<version>/main/
```
登录后复制
目录下，例如
```
/etc/postgresql/14/main/
```
登录后复制
。
- ```
postgresql.conf
```
  登录后复制
  ：控制服务器的运行时行为。编辑此文件，找到
```
listen_addresses
```
  登录后复制
  这一行。默认可能被注释掉或设置为
```
localhost
```
  登录后复制
  。为了允许远程连接，你需要将其修改为服务器的IP地址或
```
*
```
  登录后复制
  （监听所有可用网络接口）。
```
listen_addresses = '*' # 允许所有IP连接，生产环境应指定具体IP或网段
# listen_addresses = 'localhost' # 仅允许本地连接
# listen_addresses = '192.168.1.100' # 仅允许指定IP连接
```
  登录后复制
- ```
pg_hba.conf
```
  登录后复制
  ：控制客户端认证。这是PostgreSQL安全的核心。这个文件决定了哪些用户可以从哪些IP地址通过何种认证方式连接到哪个数据库。
```
# 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
# IPv6 local connections:
host    all             all             ::1/128                 scram-sha-256
# Allow connections from specific network (example)
host    your_app_db     your_app_user   192.168.1.0/24          scram-sha-256
# Allow all remote connections (DANGEROUS FOR PRODUCTION WITHOUT FIREWALL)
# host    all             all             0.0.0.0/0               scram-sha-256
```
  登录后复制
  - ```
  TYPE
```
  登录后复制
  :
```
  local
```
  登录后复制
  (Unix socket),
```
  host
```
  登录后复制
  (TCP/IP)。
- ```
DATABASE
```
    登录后复制
    :
```
all
```
    登录后复制
    (所有数据库),
```
your_app_db
```
    登录后复制
    (特定数据库)。
  - ```
  USER
```
  登录后复制
  :
```
  all
```
  登录后复制
  (所有用户),
```
  your_app_user
```
  登录后复制
  (特定用户)。
- ```
ADDRESS
```
    登录后复制
    :
```
127.0.0.1/32
```
    登录后复制
    (本地IPv4),
```
0.0.0.0/0
```
    登录后复制
    (所有IPv4地址),
```
192.168.1.0/24
```
    登录后复制
    (特定子网)。
  - ```
  METHOD
```
  登录后复制
  :
```
  peer
```
  登录后复制
  (基于OS用户身份),
```
  ident
```
  登录后复制
  (基于ident服务),
```
  md5
```
  登录后复制
  (MD5加密密码),
```
  scram-sha-256
```
  登录后复制
  (更安全的加密密码),
```
  trust
```
  登录后复制
  (无需密码，极度不安全)。推荐使用
```
  scram-sha-256
```
  登录后复制
  或
```
  md5
```
  登录后复制
  。
修改完这两个文件后，务必重启PostgreSQL服务以使更改生效：
```
  sudo systemctl restart postgresql
```
登录后复制

至此，你的PostgreSQL数据库应该已经安装并完成了基本的配置，可以接受本地或远程连接了。

如何确保PostgreSQL数据库的安全性，避免常见配置陷阱？

数据库安全从来都不是小事，尤其是像PostgreSQL这样承载核心数据的系统。我在实际工作中，见到过不少因为初期配置疏忽而导致的安全隐患，有些甚至酿成了不小的麻烦。所以，在快速搭建之后，回头审视并加固安全性是至关重要的一步。

一个常见的陷阱就是过度信任默认配置，或者为了图方便而采取过于宽松的策略。比如，将

pg_hba.conf

登录后复制

中的认证方法设置为

trust

登录后复制

，或者将

listen_addresses

登录后复制

直接设为

登录后复制

而没有配合防火墙。这简直是给潜在的攻击者敞开大门。

要确保PostgreSQL的安全性，以下几点是我的经验总结：

强密码策略： 为所有数据库用户（特别是
```
postgres
```
登录后复制
超级用户和应用专用用户）设置复杂且唯一的密码。定期更换密码也是个好习惯。不要使用弱密码，比如
```
123456
```
登录后复制
、
```
password
```
登录后复制
或
```
admin
```
登录后复制
。
最小权限原则： 这是数据库安全的基础。你的应用用户不应该拥有
```
ALL PRIVILEGES
```
登录后复制
，除非它确实需要。只授予用户完成其任务所需的最小权限。例如，一个Web应用可能只需要对特定表进行
```
SELECT
```
登录后复制
,
```
INSERT
```
登录后复制
,
```
UPDATE
```
登录后复制
,
```
DELETE
```
登录后复制
权限，而不需要创建或删除数据库的权限。
精确控制
pg_hba.conf
登录后复制
：
- 避免
  trust
  登录后复制
  认证：除非你百分之百确定，否则永远不要在
```
pg_hba.conf
```
  登录后复制
  中使用
```
trust
```
  登录后复制
  认证方法，尤其对于远程连接。即使是本地连接，也推荐使用
```
peer
```
  登录后复制
  或
```
scram-sha-256
```
  登录后复制
  。
- 使用
  scram-sha-256
  登录后复制
  或
  md5
  登录后复制
  ：
```
scram-sha-256
```
  登录后复制
  是目前推荐的最安全的密码认证方式。如果客户端兼容性有问题，退而求其次选择
```
md5
```
  登录后复制
  。
- 限制IP地址范围： 不要轻易使用
```
0.0.0.0/0
```
  登录后复制
  允许所有IP连接。你应该明确指定允许连接的IP地址或IP段。例如，如果你的应用服务器IP是
```
192.168.1.10
```
  登录后复制
  ，那么
```
pg_hba.conf
```
  登录后复制
  中就应该写
```
host your_app_db your_app_user 192.168.1.10/32 scram-sha-256
```
  登录后复制
  。
配置防火墙： 即使
```
pg_hba.conf
```
登录后复制
配置得再严格，一个操作系统级别的防火墙（如
```
ufw
```
登录后复制
或
```
firewalld
```
登录后复制
）也是不可或缺的。只允许来自信任IP地址的入站流量通过PostgreSQL的默认端口5432。
- ```
sudo ufw allow from 192.168.1.0/24 to any port 5432
```
  登录后复制
  (允许特定子网)
- ```
sudo ufw enable
```
  登录后复制
  (启用ufw)
启用SSL/TLS加密： 对于生产环境中的远程连接，强烈建议配置SSL/TLS来加密客户端和服务器之间的通信。这可以防止中间人攻击和数据窃听。这需要生成证书并在
```
postgresql.conf
```
登录后复制
中设置
```
ssl = on
```
登录后复制
，以及在
```
pg_hba.conf
```
登录后复制
中指定
```
hostssl
```
登录后复制
。
定期备份与恢复演练： 安全的数据库不仅仅是防止入侵，更要能从意外中恢复。定期进行全量和增量备份，并定期演练恢复过程，确保在灾难发生时数据可以被找回。
保持软件更新： 及时安装PostgreSQL及其所在操作系统的安全补丁。软件漏洞是攻击者常用的入口点。
日志审计： 开启详细的日志记录，并定期审查日志文件，以便发现异常活动或潜在的入侵尝试。
```
postgresql.conf
```
登录后复制
中的
```
log_destination
```
登录后复制
,
```
logging_collector
```
登录后复制
,
```
log_min_duration_statement
```
登录后复制
等参数可以帮助你。

记住，数据库安全是一个持续的过程，没有一劳永逸的解决方案。

360智图

AI驱动的图片版权查询平台

143

查看详情

在不同Linux发行版上安装PostgreSQL有哪些细微差别？

虽然PostgreSQL的核心功能和配置方式在所有Linux发行版上都是一致的，但在安装和管理层面，确实存在一些细微但可能让人困惑的差异。这些差异主要源于各个发行版对软件包的管理哲学和系统初始化方式的不同。

我自己就经常在Ubuntu服务器和CentOS服务器之间切换，每次都要稍微调整一下思路，才能顺利完成安装。这些“小坑”虽然不致命，但足以让你浪费一些时间去查阅文档。

包管理器差异：
- Debian/Ubuntu： 使用
```
apt
```
  登录后复制
  。包名通常是
```
postgresql
```
  登录后复制
  （主服务）和
```
postgresql-contrib
```
  登录后复制
  （附加模块）。安装后，服务通常会自动启动并初始化数据库集群。
- RHEL/CentOS/Fedora： 使用
```
dnf
```
  登录后复制
  （新版）或
```
yum
```
  登录后复制
  （旧版）。包名通常是
```
postgresql-server
```
  登录后复制
  （主服务）和
```
postgresql-contrib
```
  登录后复制
  。一个显著的区别是，在这些系统上，安装
```
postgresql-server
```
  登录后复制
  后，你可能需要手动运行
```
sudo postgresql-setup --initdb
```
  登录后复制
  来初始化数据库集群，然后才能启动服务。
- Arch Linux： 使用
```
pacman
```
  登录后复制
  。包名是
```
postgresql
```
  登录后复制
  。初始化数据库集群通常也需要手动执行
```
initdb -D /var/lib/postgres/data
```
  登录后复制
  。
版本可用性与更新：
- 发行版自带仓库： 大多数发行版自带的仓库可能不会提供最新版本的PostgreSQL，尤其是一些LTS（长期支持）版本。它们倾向于提供经过充分测试的稳定版本。
- PostgreSQL官方APT/YUM仓库： 如果你需要安装最新或特定版本的PostgreSQL，官方提供的仓库是更好的选择。例如，在Debian/Ubuntu上，你可以添加
```
apt.postgresql.org
```
  登录后复制
  的仓库；在RHEL/CentOS上，也有相应的
```
yum/dnf
```
  登录后复制
  仓库。这会让你能够选择安装PostgreSQL 14、15、16等特定版本，而不是发行版仓库里可能较旧的版本。
服务管理命令：
- 现代Linux发行版普遍采用
```
systemd
```
  登录后复制
  作为初始化系统，所以
```
systemctl
```
  登录后复制
  命令是通用的，例如
```
sudo systemctl start postgresql
```
  登录后复制
  、
```
sudo systemctl enable postgresql
```
  登录后复制
  。
- 然而，在一些较旧的系统或非主流发行版上，你可能还会遇到
```
service
```
  登录后复制
  命令或直接操作
```
/etc/init.d/postgresql
```
  登录后复制
  脚本的情况。
配置文件路径：
- 虽然大体结构相似（
```
/etc/postgresql/<version>/main/
```
  登录后复制
  ），但路径中的版本号会根据你安装的PostgreSQL版本而变化。例如，PostgreSQL 14的配置在
```
/etc/postgresql/14/main/
```
  登录后复制
  ，而PostgreSQL 15则在
```
/etc/postgresql/15/main/
```
  登录后复制
  。
- 某些发行版可能会将数据目录放在不同的位置，例如
```
/var/lib/pgsql/data
```
  登录后复制
  或
```
/var/lib/postgresql/<version>/main
```
  登录后复制
  。
默认用户和权限：
- ```
postgres
```
  登录后复制
  系统用户是PostgreSQL的默认数据库管理员，这一点在所有发行版上都是一致的。
- 但默认创建的数据库集群的权限和所有者可能会有细微差别，通常是由
```
postgres
```
  登录后复制
  用户拥有。

这些细微差别往往需要一点耐心去适应。最好的办法是，在安装前快速查阅一下你当前Linux发行版针对PostgreSQL的官方文档或最佳实践，这样可以避免不必要的弯路。

如何优化PostgreSQL性能，以应对高并发和大数据量场景？

面对高并发和大数据量，PostgreSQL的默认配置往往是不足以支撑的。它被设计成一个通用数据库，开箱即用，但要发挥其最大潜力，性能调优是不可避免的。这就像买了一辆高性能跑车，你不能指望它在出厂设置下就能跑出最佳成绩，你得根据赛道和驾驶风格进行精细调校。

我记得有一次处理一个电商平台的促销活动，流量瞬间暴增，数据库响应开始变慢，整个系统都受到了影响。那次经历让我深刻体会到，性能调优不是锦上添花，而是高并发场景下的生命线。

以下是一些关键的优化策略：

```
postgresql.conf
```
登录后复制
参数调优： 这是性能优化的核心战场。
- shared_buffers
  登录后复制
  ：这是PostgreSQL用于缓存数据页的内存区域。通常建议设置为系统总RAM的25%。过小会导致频繁的磁盘I/O，过大则可能与操作系统文件缓存竞争，反而降低效率。
- work_mem
  登录后复制
  ：用于排序操作和哈希表操作的内存。这是每个会话（session）的私有内存。如果你的查询包含大量排序或哈希操作，增加此值可以避免将数据写入临时磁盘文件，但也要注意，如果并发连接数很高，总的
```
work_mem
```
  登录后复制
  消耗可能会非常大。
- maintenance_work_mem
  登录后复制
  ：用于
```
VACUUM
```
  登录后复制
  ,
```
CREATE INDEX
```
  登录后复制
  ,
```
ALTER TABLE
```
  登录后复制
  等维护操作的内存。可以设置得比
```
work_mem
```
  登录后复制
  大，因为它通常只由一个或少数进程使用。
- wal_buffers
  登录后复制
  ：用于预写日志（WAL）的内存。通常设置为16MB或32MB就足够了，过大意义不大。
- max_connections
  登录后复制
  ：最大并发连接数。根据服务器硬件和应用需求设置，过高会消耗大量内存，过低则可能导致连接排队。
- effective_cache_size
  登录后复制
  ：告诉查询规划器操作系统有多少可用的磁盘缓存。这有助于规划器更好地估计磁盘I/O成本。通常设置为系统总RAM的50%-75%。
- random_page_cost
  登录后复制
  和
  seq_page_cost
  登录后复制
  ：这两个参数影响查询规划器对随机磁盘访问和顺序磁盘访问的成本估算。调整它们可以影响规划器选择索引扫描还是顺序扫描。SSD硬盘的
```
random_page_cost
```
  登录后复制
  应该设置得更低。
索引优化：
- 正确选择索引类型： B-tree索引最常用，适用于等值查询和范围查询。但对于全文搜索、几何数据等，可能需要GIN、GiST、BRIN等特殊索引。
- 避免过度索引： 索引虽然能加速查询，但会增加写入操作的开销，并占用磁盘空间。只为那些经常用于WHERE子句、JOIN条件或ORDER BY子句的列创建索引。
- 使用
  EXPLAIN ANALYZE
  登录后复制
  ：这是诊断慢查询的利器。通过它，你可以看到查询规划器是如何执行查询的，以及每个步骤的实际耗时，从而找出性能瓶颈。
VACUUM和Autovacuum：
- PostgreSQL使用MVCC（多版本并发控制），更新和删除操作并不会立即移除旧数据，而是将其标记为“死元组”。这些死元组会占用空间，影响查询性能。
- ```
VACUUM
```
  登录后复制
  操作负责回收这些死元组占用的空间。
- ```
Autovacuum
```
  登录后复制
  守护进程会自动运行
```
VACUUM
```
  登录后复制
  和
```
ANALYZE
```
  登录后复制
  ，确保数据库的健康。务必确保
```
Autovacuum
```
  登录后复制
  是开启的，并根据负载调整其参数（如
```
autovacuum_vacuum_scale_factor
```
  登录后复制
  ,
```
autovacuum_vacuum_threshold
```
  登录后复制
  等），以避免表膨胀和性能下降。
硬件优化：
- 快速存储： SSD是现代数据库的标配。NVMe SSD能提供更低的延迟和更高的IOPS。
- 充足的RAM： 更多的内存意味着更多的数据可以被缓存，减少磁盘I/O。
- 强大的CPU： 对于复杂的查询和高并发，CPU性能同样重要。