Merge pull request #6191 from geekpi/master

translated
This commit is contained in:
geekpi
2017-10-31 20:02:16 -05:00
committed by GitHub
2 changed files with 95 additions and 97 deletions

View File

@@ -1,97 +0,0 @@
translating---geekpi
Best of PostgreSQL 10 for the DBA
============================================================
Last week a new PostgreSQL major version with the number 10 was released! Announcement, release notes and the „Whats new“ overview can be found from [here][3], [here][4]and [here][5]  its highly recommended reading, so check them out. As usual there have been already quite some blog postings covering all the new stuff, but I guess everyone has their own angle on what is important so as with version 9.6 Im again throwing in my impressions on the most interesting/relevant features here.
As always, users who upgrade or initialize a fresh cluster, will enjoy huge performance wins (e.g. better parallelization with parallel index scans, merge joins and uncorrelated sub-queries, faster aggregations, smarter joins and aggregates on remote servers) out of the box without doing anything, but here I would like to look more at the things that you wont get out of the box but you actually need to take some steps to start benefiting from them. List of below highlighted features is compiled from a DBAs viewpoint here, soon a post on changes from a developers point of view will also follow.
### Upgrading considerations
First some hints on upgrading from an existing setup this time there are some small things that could cause problems when migrating from 9.6 or even older versions, so before the real deal one should definitely test the upgrade on a separate replica and go through the full list of possible troublemakers from the release notes. Most likely pitfalls to watch out for:
* All functions containing „xlog“ have been renamed to use „wal“ instead of „xlog“
The latter naming could be confused with normal server logs so a „just in case“ change. If using any 3rd party backup/replication/HA tools check that they are all at latest versions.
* pg_log folder for server logs (error messages/warnings etc) has been renamed to just „log“
Make sure to verify that your log parsing/grepping scripts (if having any) work.
* By default queries will make use of up to 2 background processes
If using the default 10 postgresql.conf settings on a machine with low number of CPUs you may see resource usage spikes as parallel processing is enabled by default now which is a good thing though as it should mean faster queries. Set max_parallel_workers_per_gather to 0 if old behaviour is needed.
* Replication connections from localhost are enabled now by default
To ease testing etc, localhost and local Unix socket replication connections are now enabled in „trust“ mode (without password) in pg_hba.conf! So if other non-DBA user also have access to real production machines, make sure you change the config.
### My favourites from a DBAs point of view
* Logical replication
The long awaited feature enables easy setup and minimal performance penalties for application scenarios where you only want to replicate a single table or a subset of tables or all tables, meaning also zero downtime upgrades for following major versions! Historically (Postgres 9.4+ required) this could be achieved only by usage of a 3rd party extension or slowish trigger based solutions. The top feature of version 10 for me.
* Declarative partitioning
Old way of managing partitions via inheritance and creating triggers to re-route inserts to correct tables was bothersome to say the least, not to mention the performance impact. Currently supported are „range“ and „list“ partitioning schemes. If someone is missing „hash“ partitioning available in some DB engines, one could use „list“ partitioning with expressions to achieve the same.
* Usable Hash indexes
Hash indexes are now WAL-logged thus crash safe and received some performance improvements so that for simple searches theyre actually faster than standard B-tree indexes for bigger amounts of data. Bigger index size though too.
* Cross-column optimizer statistics
Such stats needs to be created manually on a set if columns of a table, to point out that the values are actually somehow dependent on each other. This will enable to counter slow query problems where the planner thinks there will be very little data returned (multiplication of probabilities yields very small numbers usually) and will choose for example a „nested loop“ join that does not perform well on bigger amounts of data.
* Parallel snapshots on replicas
Now one can use the pg_dump tool to speed up backups on standby servers enormously by using multiple processes (the jobs flag).
* Better tuning of parallel processing worker behaviour
See max_parallel_workers and min_parallel_table_scan_size / min_parallel_index_scan_size parameters. The default values (8MB, 512KB) for the latter two I would recommend to increase a bit though.
* New built-in monitoring roles for easier tooling
New roles pg_monitor, pg_read_all_settings, pg_read_all_stats, and pg_stat_scan_tables make life a lot easier for all kinds of monitoring tasks previously one had to use superuser accounts or some SECURITY DEFINER wrapper functions.
* Temporary (per session) replication slots for safer replica building
* A new Contrib extension for checking validity of B-tree indexes
Does couple of smart checks to discover structural inconsistencies and stuff not covered by page level checksums. Hope to check it out more deeply in nearer future.
* Psql query tool supports now basic branching (if/elif/else)
This would for example enable having a single maintenance/monitoring script with version specific branching (different column names for pg_stat* views etc) instead of many version specific scripts.
```
SELECT :VERSION_NAME = '10.0' AS is_v10 \gset
\if :is_v10
SELECT 'yippee' AS msg;
\else
SELECT 'time to upgrade!' AS msg;
\endif
```
Thats it for this time! Lot of other stuff didnt got listed of course, so for full time DBAs Id definitely suggest to look at the notes more thoroughly. And a big thanks to those 300+ people who contributed their effort to this particularly exciting release!
--------------------------------------------------------------------------------
via: http://www.cybertec.at/best-of-postgresql-10-for-the-dba/
作者:[ Kaarel Moppel][a]
译者:[译者ID](https://github.com/译者ID)
校对:[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
[a]:http://www.cybertec.at/author/kaarel-moppel/
[1]:http://www.cybertec.at/author/kaarel-moppel/
[2]:http://www.cybertec.at/best-of-postgresql-10-for-the-dba/
[3]:https://www.postgresql.org/about/news/1786/
[4]:https://www.postgresql.org/docs/current/static/release-10.html
[5]:https://wiki.postgresql.org/wiki/New_in_postgres_10

View File

@@ -0,0 +1,95 @@
对 DBA 最好的 PostgreSQL 10
============================================================
上周发布了一个新的 PostgreSQL 10公告、发布说明和“新功能”概述可以在[这里][3]、[这里][4]和[这里][5]看到 - 强烈建议阅读,所以将它列出来。像往常一样,已经有相当多的博客覆盖了所有新的东西,但我猜每个人都有自己认为重要的角度,所以与 9.6 版一样我再次在这里列出我印象中最有趣/相关的功能。
与往常一样,升级或初始化一个新集群的用户将获得更好的性能(例如,更好的并行索引扫描、合并 join 和不相关的子查询,更快的聚合、远程服务器上更加智能的 join 和聚合),这些都开箱即用,但本文中我像将一些不能开箱即用,实际上你需要采取一些步骤才能从中获益。下面高亮展示的功能是从 DBA 的角度来编的,很快有一篇文章从开发者的角度讲述更改。
### 升级注意事项
首先有些从现有设置升级的提示 - 有一些小的事情会导致从 9.6 或更旧的版本迁移时引起问题,所以在真正的升级之前,一定要在单独的副本上测试升级,并遍历发行说明中所有可能的问题。最值得注意的缺陷是:
* 所有包含 “xlog” 的函数都被重命名为使用 “wal” 而不是 “xlog”。
后一个命名可能与正常的服务器日志混淆,因此“以防万一”更改。如果使用任何第三方备份/复制/H A工具请检查它们是否为最新版本。
* 服务器日志(错误消息/警告等)的 pg_log 文件夹已重命名为 “log”。
确保验证你的日志解析/grep 脚本(如果有)可以工作。
* 默认情况下,查询将最多使用 2 个后台进程。
如果在 CPU 数量较少的机器上在 postgresql.conf 设置中使用默认值 10则可能会看到资源使用率峰值因为默认情况下并行处理已启用 - 这是一件好事,因为它应该意味着更快的查询。如果需要旧的行为,请将 max_parallel_workers_per_gather 设置为0。
* 默认情况下,本地主机的复制连接已启用
为了简化测试等,本地主机和本地 Unix 套接字复制连接现在在 pg_hba.conf 中以“信任”模式启用(无密码)!因此,如果其他非 DBA 用户也可以访问真实的生产计算机,请确保更改配置。
### 从 DBA 的角度来看我的最爱
* 逻辑复制
这个期待已久的功能在你只想要复制一张单独的表或者字表或者所有表时有简单的设置和最小的性能损失,也意味着之后主要版本的零停机升级!历史上(需要 Postgres 9.4+),这可以通过使用第三方扩展或缓慢的基于触发器的解决方案来实现。对我而言这是 10 最好的功能。
* 声明分区
以前管理分区的方法通过继承并创建触发器来重路由插入到正确的表中,这一点很烦人,更不用说性能的影响了。目前支持的是 “range” 和 “list” 分区方案。如果有人在某些 DB 引擎中缺少 “哈希” 分区,则可以使用带表达式的 “list” 分区来实现相同的功能。
* 可用的哈希索引
哈希索引现在是 WAL 记录的,因此是崩溃安全,并获得了一些性能改进,因此对于简单的搜索,由于更大的数据,它们比标准的 B 树快。还有更大的索引大小。
* 跨列优化器统计
这样的统计数据需要在一组表的列上手动创建,以指出这些值实际上是以某种方式相互依赖的。这将能够应对计划器认为返回的数据很少(概率的乘积通常会产生非常小的数字)并选择例如一个在大量数据下性能不好的“嵌套循环” join 的慢查询问题。
* 副本上的并行快照
现在可以在 pg_dump 中使用多个进程(-jobs标志来极大地加快备用服务器上的备份。
* 更好地调整并行处理 worker 的行为
参考 max_parallel_workers 和 min_parallel_table_scan_size/min_parallel_index_scan_size 参数。我建议增加一点后两者的默认值8MB、512KB
* 新的内置监控角色,便于加工
新的角色 pg_monitor、pg_read_all_settings、pg_read_all_stats 和 pg_stat_scan_tables 能更容易进行各种监控任务 - 以前必须使用超级用户帐户或一些 SECURITY DEFINER 包装函数。
* 用于更安全的副本生成的临时 (每个会话) 复制槽
* 用于检查 B 树索引的有效性的一个新的 Contrib 扩展
几个智能检查发现结构不一致和页面级校验和未覆盖的内容。希望不久的将来能更加深入。
* Psql 查询工具现在支持基本分支if/elif/else
例如下面的将启用具有特定版本分支(对 pg_stat* 视图等有不同列名)的单个维护/监视脚本,而不是许多版本特定的脚本。
```
SELECT :VERSION_NAME = '10.0' AS is_v10 \gset
\if :is_v10
SELECT 'yippee' AS msg;
\else
SELECT 'time to upgrade!' AS msg;
\endif
```
这次就这样了!当然有很多其他的东西没有列出,所以对于全职 DBA我一定会建议更全面地看发布记录。非常感谢那 300 多为这个版本做出贡献的人!
--------------------------------------------------------------------------------
via: http://www.cybertec.at/best-of-postgresql-10-for-the-dba/
作者:[ Kaarel Moppel][a]
译者:[geekpi](https://github.com/geekpi)
校对:[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
[a]:http://www.cybertec.at/author/kaarel-moppel/
[1]:http://www.cybertec.at/author/kaarel-moppel/
[2]:http://www.cybertec.at/best-of-postgresql-10-for-the-dba/
[3]:https://www.postgresql.org/about/news/1786/
[4]:https://www.postgresql.org/docs/current/static/release-10.html
[5]:https://wiki.postgresql.org/wiki/New_in_postgres_10