小编Nyx*_*nyx的帖子

我正在尝试将表planet_osm_polygon从一个数据库复制osm到另一个数据库test。我su postgres并执行了pg_dump.

问题：但是我收到错误could not change directory to "/root"并且Password:提示出现了两次！有没有办法pg_dump在登录时执行root？

root@lalaland:~# su postgres
postgres@lalaland:/root$ pg_dump -h localhost "osm" --table "public.planet_osm_polygon" | 
    psql -h localhost "test" --table "staging.planet_osm_polygon"
could not change directory to "/root"
could not change directory to "/root"
Password: Password:

更新

问题#2：public即使我通过了 flag ，表似乎也被复制到了模式中--table="staging.planet_osm_polygon"。为什么不将其复制到 schema staging？

redis 服务器 v2.8.4 在 Ubuntu 14.04 VPS 上运行，具有 8 GB RAM 和 16 GB 交换空间（在 SSD 上）。但是htop显示redis单独占用22.4 G内存！

redis-server最终因为内存不足而崩溃。Mem并且Swp两者都命中 100% 然后redis-server与其他服务一起被杀死。

来自dmesg：

[165578.047682] Out of memory: Kill process 10155 (redis-server) score 834 or sacrifice child
[165578.047896] Killed process 10155 (redis-server) total-vm:31038376kB, anon-rss:5636092kB, file-rss:0kB

redis-server从 OOM 崩溃或service redis-server force-reload导致内存使用量下降到 <100MB 的情况下重新启动。

问题：为什么会redis-server占用越来越多的内存直到崩溃？我们怎样才能防止这种情况发生？

设置是不是真的maxmemory不行，因为一旦redis达到maxmemory限制，它就会开始删除数据？

重启 redis-server 后 …

我需要在 Ubuntu 18.04 系统上使用pg_basebackup/pg_dump程序连接到远程 PostgreSQL 11.6 服务器。

但是目前系统只包含pg_basebackup10.10，远程数据库使用的是PostgreSQL 11.6。运行pg_basebackup给出错误

pg_basebackup：不兼容的服务器版本 11.6

尝试pg_basebackup使用以下命令安装正确版本：

apt install postgresql-client-11

但是找不到apt包。只有postgresql-client，postgresql-client-10和postgresql-client-common可用于系统的 apt 存储库。

问题：如何在pg_basebackup不从远程数据库服务器复制过来的情况下安装正确的版本，并且在这台机器上不安装PostgreSQL 11.6？

在下面的查询中，为什么我们必须使用WHERE foo.row_num < 3子查询之外的子句foo而不是子查询内的子句来限制从每个 Partition 返回的结果WHERE row_num < 3？

询问

SELECT pid, land_type, row_num, road_name, round(CAST(dist_km AS numeric), 2) AS dist_km

FROM (
    SELECT ROW_NUMBER() 
    OVER (
        PARTITION by loc.pid
        ORDER BY ST_Distance(r.the_geom, loc.the_geom)
    ) as row_num,
    loc.pid, loc.land_type, r.road_name, 
    ST_Distance(r.the_geom, loc.the_geom)/1000 as dist_km
    FROM ch05.land AS loc
    LEFT JOIN ch05.road AS r
    ON ST_DWithin(r.the_geom, loc.the_geom, 1000)
    WHERE loc.land_type = 'police station'
) AS foo

WHERE foo.row_num < 3
ORDER BY pid, row_num;

不工作的查询 …

专门运行 PostgreSQL 11.2 服务器（带有 TimescaleDB 扩展）的 Ubuntu 18.04 服务器将很快耗尽磁盘空间，因此需要向计算机添加新的 SSD 磁盘以支持不断增长的数据库大小。

数据预计将以相同/更高的速率继续增加，因此需要不断增加存储硬件，直到机器用完 2.5 英寸驱动器托架。只有这时才会考虑将数据库分布在多台机器上，因为所涉及的复杂性增加。

想法

1. 联合文件系统mergerfs可以将驱动器集中在一起，轻松解决存储扩展问题。但这会增加数据库操作的延迟，因此不建议这样做。可以通过底层 RAID-1/5/6/10 或使用 SnapRAID 添加冗余。

2. RAID-0 和 RAID-10 允许将 RAID 阵列扩展到新添加的驱动器中，并通过条带化提高性能。然而，每个添加的驱动器都会增加一个故障点。此外，许多人声称镜像 SSD 的用途有限，因为RAID-0 中的两个 SSD 可能会同时发生故障。所以也许这意味着 RAID-10 并不比 RAID-0 更好。此外，故障率随着每增加一个 SSD 而线性增加。

3. RAID-5/6 由于奇偶校验计算和写入 2 个驱动器而降低了性能，从而使有效 IOPS 降低了 75%。对于数据库来说似乎是一个糟糕的选择。

4. PostgreSQLTABLESPACES可用于将每个表分配到特定驱动器。然而，使用表空间会使恢复变得非常复杂。此外，是否可以在新驱动器上创建新表空间并让 Postgres 自动决定将新记录写入何处？

5. ZFS、BTRFS？对他们不熟悉，愿意探索他们是否合适。

问题： 2020年推荐的PostgreSQL机器扩容方法是什么，如果扩容频繁（一年1-2次），性能应该不会受到太大影响，恢复也不会太复杂可能会导致数据丢失？

RAID-10 对我来说似乎是一个好主意，但 RAID-1 的使用似乎有限，同时会导致“损失”一半的磁盘空间，随着驱动器数量的增加，故障点也会增加，情况会变得更糟。

由于预算限制，我们无法一次性将 2U 机箱中的 16 个驱动器托架全部装满 SSD，因此必须逐步完成。

任何意见是极大的赞赏！

编辑：在研究了 ZFS 之后，这似乎可能是我的案例的解决方案之一。

• 仅包含镜像 ZFS vdev（每个 …

当从被黑的 Ubuntu 12.04 服务器恢复 Postgresql 数据库时，我将数据目录复制到另一个位置，重新安装操作系统和 PostgreSQL，停止 PostgreSQL 服务，删除数据目录中的内容并从以前的安装中复制回内容。

问题： PostgreSQL 现在无法启动，显示以下错误。为什么会发生这种情况，我们如何解决这个问题？

service postgresql restart
* Restarting PostgreSQL 9.1 database server                                     

* Error: could not exec /usr/lib/postgresql/9.1/bin/pg_ctl /usr/lib/postgresql/9.1/bin/pg_ctl start -D /var/lib/postgresql/9.1/main -l /var/log/postgresql/postgresql-9.1-main.log -s -o -c config_file="/etc/postgresql/9.1/main/postgresql.conf" :

更新

现在重新启动 PostgreSQL 服务会出现错误：

* Restarting PostgreSQL 9.1 database server                                     
* The PostgreSQL server failed to start. Please check the log output:
2013-04-16 01:52:10 EDT PANIC:  could not open control file "global/pg_control": Permission denied

为什么 pgAdmin3postgres在创建和设置表时自动设置表所有者OIDS=FALSE？我是 PostgreSQL 的新手，想知道这种默认行为背后的原因。

-- Table: staging.mytable

-- DROP TABLE staging.mytable;

...

WITH (
  OIDS=FALSE
);

ALTER TABLE staging.mytable
OWNER TO postgres;

我使用以下命令在 PostgreSQL 11.6（带有 TimescaleDB 1.60 扩展）中创建了数据库的备份pg_dump：

PGPASSWORD=mypassword pg_dump -h 127.22.0.4 -p 5432 -U postgres -Z0 -Fc database_development

并将其恢复到运行相同版本的 PostgreSQL 11.6（带有 TimescaleDB 1.60 扩展）的新服务器pg_restore。对于恢复，以psql用户身份执行以下命令postgres：

CREATE DATABASE database_development;
\c database_development
CREATE EXTENSION timescaledb;
SELECT timescaledb_pre_restore();

\! time pg_restore -Fc -d database_development /var/lib/postgresql/backups/database_development_2020-02-29

SELECT timescaledb_post_restore();

原始数据库的数据库大小为 389 GB，但恢复的数据库为 229 GB。这些尺寸是通过运行获得的

select pg_size_pretty(pg_database_size('database_development'))

一些差异：

旧数据库存储在 ext4 分区上，而新数据库存储在禁用压缩的 ZFS 文件系统上。两个数据库实例都在具有 Ubuntu 18.04 主机的 Docker 容器内运行。

问题：我们如何解释数据库大小的差异？pg_dump和期间都没有遇到错误pg_restore。