标签: postgresql

我想在 postgresql 上设置复制系统，如 #1 MASTER SERVER 和两个复制服务器：#2 SERVER in realtime（用于负载平衡），#3 SERVER 延迟一些时间偏移（例如 2 天）以防止应用程序和人为错误数据更新/删除

有人对这种设置有经验吗？该解决方案在现实生活中的缺点和问题是什么？

我的 Postgres-Server 运行了很长时间，可能包含 4-5 GB 的数据。

备份是使用转储完成的，这可以正常工作。虽然不是最有效，但它只是有效。

由于未来的增长，我喜欢激活 PITR 备份（如 Oracle 中的 RMAN）。

这可能和/或推荐吗？或者我最好预先使用正确的设置重新创建数据库？

我有一个非常大的表，带有 blob 字段，称为data. 我试图弄清楚为什么它没有被很好地缓存并且重复的SELECTs 很慢：

=> SELECT pg_size_pretty(pg_total_relation_size('data'));
157 GB

这看起来有点大，所以我试着总结一下数据：

=> SELECT pg_size_pretty(pg_relation_size('data'));
19 GB

随着指数：

SELECT pg_size_pretty(pg_relation_size('data_pkey'));
757 MB   
SELECT pg_size_pretty(pg_relation_size('data_file_end_date_idx'));
766 MB   
SELECT pg_size_pretty(pg_relation_size('data_file_end_date_idx'));
766 MB
SELECT pg_size_pretty(pg_relation_size('data_merged_idx'));
854 MB
SELECT pg_size_pretty(pg_relation_size('data_owner_idx'));
794 MB
SELECT pg_size_pretty(pg_relation_size('data_session_format_idx'));
779 MB

数据和索引大小的总和约为 26 GB，但总关系大小接近 160 GB。该表刚刚从转储中恢复，此后没有进行任何写入。

• 这种差异的解释是什么？
• 有什么办法可以减少浪费的磁盘空间？聚类会有帮助吗？

我想知道某个 PostgreSQL 表是否是任何继承关系的一部分（即是其他表的父表还是子表）。

有查询吗？继承数据存储在哪里？

我在三台服务器上使用 pgpool-II + PostgreSQL 8.4：主 + 备用 1 + 备用 2。复制模式为“on”负载均衡模式为“on”（在主备1之间）

我按照官方教程使用 PITR 配置在线恢复：http : //pgpool.projects.postgresql.org/pgpool-II/doc/pgpool-en.html#online-recovery

脚本“copy-base-backup”中有一个 tar 命令：

tar -C /data -zcf pgsql.tar.gz pgsql

所以我所有的 PG 集群目录都在脚本运行时被复制：

ls -1 /srv/pg/data/
PG_VERSION 
archive # directory with postgres archive files
backup_label.old
base
global
pg_clog
pg_hba.conf
pg_ident.conf
pg_log
pg_multixact
pg_stat_tmp
pg_subtrans
pg_tblspc
pg_twophase
pg_xlog
pgpool_recovery
pgpool_recovery_pitr
pgpool_remote_start
postgresql.conf
postmaster.opts
postmaster.pid
recovery.conf
recovery.done

如何从主节点和备用节点安全地删除旧的存档日志？我的节点上每天大约有 30Gb 的档案。

我在 Ubuntu LTS 10.04.02 服务器版本上使用 PostgreSQL 8.4。我使用 pg_standby 来恢复数据，并为数据库恢复创建了一个 recovery.conf 并将其放在 /etc/postgresql/8.4/main 上，其中存在其余的 conf 文件，并尝试使用

sudo service postgresql start

希望服务能够识别出我正在使用 recovery.conf 进行恢复。我发现这个文件被忽略了。然后，我不得不将所有 *.conf 文件复制到我的数据目录（在我的例子中是 /dbdata/data），然后，我不得不从 'postgres' 用户启动数据库，而不是使用 init.d 中的脚本

/usr/lib/postgresql/8.4/bin/pg_ctl -D /dbdata/proddata  -l /var/log/postgresql/postgresql-8.4-main.log start

如何让我的恢复过程服从 /etc/init.d/postgresql start|stop|restart 或让 pg_ctl 命令查找 conf 文件 /etc/postgresql/8.4/main ？

注意：我对 PostgreSQL 和一般的数据库管理比较陌生

应用程序正在写入遵循 EAV 结构的数据库，类似于：

CREATE TABLE item (
    id INTEGER PRIMARY KEY,
    description TEXT
);

CREATE TABLE item_attr (
    item INTEGER REFERENCES item(id),
    name TEXT,
    value INTEGER,
    PRIMARY KEY (item, name)
);

INSERT INTO item VALUES (1, 'Item 1');
INSERT INTO item_attr VALUES (1, 'height', 20);
INSERT INTO item_attr VALUES (1, 'width', 30);
INSERT INTO item_attr VALUES (1, 'weight', 40);
INSERT INTO item VALUES (2, 'Item 2');
INSERT INTO item_attr VALUES (2, 'height', 10);
INSERT INTO item_attr VALUES (2, 'weight', 35); …

我已经从大约 7500 万行的 PostgreSQL 表中删除了大约 6500 万行。删除查询一完成，CPU 就骤降到 100%，持续约五分钟。

删除行的表有多个索引，并且在删除期间和删除之后被大量使用。不幸的是，我没有办法重现这个问题，因为它发生在生产环境中。

autovacuum 是否可能启动？如果是，它是否可以将具有 32 个 CPU 核心的数据库驱动到 100% CPU 使用率？如果是这样，是否有办法限制 autovacuum 的摄入量，以便在大量删除查询后不会降低数据库性能？

我正在使用 PostgreSQL 版本 14.8。

我需要向一个高流量的大型 PostgreSQL 表（大约 2TB）添加主键。这是一项关键操作，我正在寻找如何有效地完成该操作的指导。

我已经尝试过以下步骤：

-- Step 1: Add id identity column 
ALTER TABLE users
ADD COLUMN id BIGINT GENERATED ALWAYS as IDENTITY;

-- Step 2: Add unique index on (id, user_id) concurrently
CREATE UNIQUE INDEX CONCURRENTLY id_user_id_idx
   ON users (id, user_id);

-- verify that step 2 is completed
-- Step 3: Add primary key
ALTER TABLE users
   ADD CONSTRAINT users_pkey PRIMARY KEY USING INDEX id_user_id_idx;

我面临两个问题：

• 表完全锁定在“步骤 1”本身上。

  我知道这是预料之中的，但如果有任何选择可以避免这种情况，请提出建议。

• 我收到以下错误，

错误：无法扩展文件“base/16401/90996”：设备上没有剩余空间提示：检查可用磁盘空间。

但600GB我的服务器上还有剩余的存储空间。

由于表将被锁定在“第 1 步”，并且如果没有选项可以避免这种情况，我可以利用停机时间id先添加列，然后运行其他两个脚本。 …

我有一个表定义如下

CREATE TABLE details_search (
    id int4 NOT NULL PRIMARY KEY,
    "search" tsvector NULL
);
CREATE INDEX details_search_idx ON details_search USING gin (search);

我运行这个来了解它的大小：

SELECT pg_size_pretty(pg_relation_size('details_search')) relation_size,
       pg_size_pretty(pg_total_relation_size('details_search')) total_relation_size,
       pg_size_pretty(pg_table_size('details_search')) table_size,
       pg_size_pretty(pg_indexes_size('details_search')) indexes_size;

这些是结果

relation_size|total_relation_size|table_size|indexes_size|
-------------+-------------------+----------+------------+
800 MB       |64 GB              |57 GB     |6830 MB     |

我只对执行短语搜索感兴趣，并且这些搜索是聚合使用的。当我使用不常见术语执行短语搜索时，一切正常。现在，当我使用具有常用术语的短语时，性能会受到很大影响。

这个查询花了 192 秒：

SELECT COUNT(id)
FROM   details_search
WHERE  search @@ phraseto_tsquery('simple', 'data management') 

这是查询计划（这里是一个漂亮的界面中的查询计划）：

  Output: count(id)
  Buffers: shared hit=25942383 read=6354221 written=4588
  I/O Timings: shared/local read=512605.708 write=122.864
  ->  Gather  (cost=178176.43..178176.64 rows=2 …