content.json

{"pages":[{"title":"categories","text":"","link":"/categories/index.html"},{"title":"About Us","text":"Company ProfileHighGo is a database software products and services provider leading in the country. HighGo was established in 2005, and headquarters is located in Jinan, has branches and offices in Province Beijing, Xi’an, Qingdao and other places.HighGo signed an agreement with Regus in 2016.The address of HighGo in America is: 2018 156th Avenue,N.E. Suite 100 Bellevue,WA 98007 HighGo is the outstanding software enterprises, high-tech enterprises, has passed ISO9001 Quality Management SystemCertification, ISO20000IT Service Management System Certification, ISO27001 Information Security Management System Certification and CMMI3 level evaluation and certification. HighGo Software already has more than ten patents and copyright in the data management field, covering data management, user training, technical support services and other areas, HighGo establishes data lifecycle management system, and its comprehensive data solution has a good reputation in the industry. HighGo 10 YearHighGo with nearly a decade of experience in database integrated services in the country cultivates the thousands of users. HighGo database platform solutions save a lot of cost for users, by providing users with specialized data services to overall improve the level of database use in IT department. Enterprise CultureHighGo upholds entrepreneurial spirits of unity, hard work, courage, innovation, in order to revitalize the national infrastructure software for the vision , make domestic database brand bigger and stronger, ambitious, front with our customers and partners to stride along the line, create a greate cause! Connect UsOffice Address: Highgo Softwaare Inc., 10326 Whalley Blvd #3,Surrey,BC","link":"/about/index.html"},{"title":"archives","text":"","link":"/archives/index.html"},{"title":"tags","text":"","link":"/tags/index.html"}],"posts":[{"title":"Pakistan Office Open","text":"I am very pleased and thrilled to inform that i have joined HighGo Software Inc as a VP of Development and General Manager Pakistan office. HighGo Software is the largest commercial PostgreSQL provider in China. It is also a core member of PostgreSQL community in China and is the initiator of China PostgreSQL Association, under COPU (China Open Source Software Promotion Alliance) organization. Here is a link of China PostgreSQL association http://www.postgresqlchina.com/en. HighGo also provides the core support for PostgreSQL activities like conferences/ meet-up in China. We are very committed in working towards the promotion and growth of PostgreSQL community in the region and working towards making siginifcant contributions to PG. HighGo is setting up a small R&D office based in multiple locations which will primarily work on PostgreSQL development and will help PostgreSQL grow in this communuty. We recently started our HighGo postgres development office in Canada and Pakistan and also expanding the team in China. Attached a few pictures on HighGo Software Inc Pakistan office for PostgreSQL development. We have a humble begining starting a small office of PostgreSQL experts who will be working in the community as-well as HighGo Postgres. While the plans are still under discussion, HighGo Software intends to have its own fork of PostgreSQL with some unique features with the goal of contributing those features to community PostgreSQL. We also intend to work very closely with the community and contribute features back to the community and of course work on other community activies like patch reviews, bug fixes and most importantly presenting and promoting PostgreSQL. Stay tuned for more developments.","link":"/2019/05/09/pakistanofficeOpen/"},{"title":"The JIT benchmarking results and findings in PostgreSQL 11","text":"Just-in-time compilation of SQL statements is one of the new features in PostgreSQL 11. Just-in-Time compilation (JIT) is the process of turning some form of interpreted program evaluation into a native program and doing so at runtime. While doing some testing and benchmarking with JIT it appears that PostgreSQL 11 is about 29.31% faster at executing the TPC-H Q1 query than PostgreSQL 10. You could get details from https://www.citusdata.com/blog/2018/09/11/postgresql-11-just-in-time/. The JIT technique is implemented using LLVM. What is the LLVM? The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. Despite its name, LLVM has little to do with traditional virtual machines. The name “LLVM” itself is not an acronym; it is the full name of the project. Is the JIT necessary?In today’s enterprise, the data has been growing at an unprecedented rate, with a sharp rise in data, the requirement for performing business intelligence and analytical queries is also increasing. Most enterprises are also relying upon to store there very large historical data in NoSQL or distributed storage like Hadoop for performing complex analytical queries. Having said that the OLAP capabilities of the database are also getting there run for the money, the OLAP workloads are increasing and hence the need to enhance database OLAP functionality to handle the growing OLAP workloads. OLAP functionality is primarily affected by data throughput and CPU computing power. Now with the rise of SSD, Column Storage, and Distributed Databases, I/O is not the main bottleneck of the database. Modern databases add a lot of logical and virtual function calls in response to various scenarios. This reduces the efficiency of OLAP capabilities for the database. In the PostgreSQL 11, they added the Just-in-Time compilation, which could reduce the redundant logical operations and virtual function calls. JIT Accelerated Operations in PostgreSQL 11 Currently PostgreSQL’s JIT implementation has support for accelerating expression evaluation and tuple deforming. Several other operations could be accelerated in the future. Expression evaluation is used to evaluate WHERE clauses, target lists, aggregates and projections. It can be accelerated by generating code specific to each case. Tuple deforming is the process of transforming an on-disk tuple (see Section 68.6.1) into its in-memory representation. It can be accelerated by creating a function specific to the table layout and the number of columns to be extracted. The first time I came into contact with this technology was using the Vitesse database. In recent years, some new database products with this technology have been discovered. Vitesse DB: Proprietary database based on PostgreSQL 9.5.x JIT compiling expressions as well as execution plan Speedup up to 8x on TPC-H Q1 Butterstein D., Grust T., Precision Performance Surgery for PostgreSQL –LLVM-based Expression Compilation, Just in Time. VLDB 2016. JIT compiling expressions for Filter and Aggregation Speedup up to 37% on TPC-H New expression interpreter (by Andres Freund, PostgreSQL 11): Changes tree walker based interpreter to more effective one Also adds LLVM JIT for expressions Speedup up to 30% on TPC-H I find that the JIT is disabled by default in PostgreSQL 11. The purpose of this blog is to perform testing and benchmarking of JIT and in particular compare PostgreSQL 11 with JIT with PostgreSQL 10. The testing should demonstrate the performance benefits of JIT with PG 11, it will also identify areas of improvements and suggestions on how to make the improvements. My Hardware Configuration： CPU : i5 8400 Memory : 16G DDR4 Disk : Inter SSD 1T OS : CentOS Linux release 7.6.1810 (Core) Install the PostgreSQL 11 from the source with llvmPostgreSQL has built-in support to perform JIT compilation using LLVM when PostgreSQL is built with –with-llvm. In the first, you need to install llvm5.0. Then you can install the PostgreSQL 11 and PostgreSQL 10. 123456789./configure --prefix=/home/postgres/pg11JIT --with-openssl --with-libxml --with-libxslt --with-llvmmake -j6; make installcd contribmake -j6; make install./configure --prefix=/home/postgres/pgdb10 --with-openssl --with-libxml --with-libxsltmake -j6; make installcd contribmake -j6; make install The configuration variable about JIT The configuration variable jit determines whether JIT compilation is enabled or disabled. If it is enabled, the configuration variables jit_above_cost, jit_inline_above_cost, and jit_optimize_above_cost determine whether JITcompilation is performed for a query, and how much effort is spent in doing so. jit_provider determines which JIT implementation is used. It is rarely required to be changed. Enabling The JIT in PostgreSQL 11If you install the PostgreSQL 11 successfully, you will find a new folder named bit_code. There is a lot of file with the .bc extension. These are pre-generated bytecodes for LLVM for facilitating features like in-lining. I have changed some configuration variable in PostgreSQL10 and PostgreSQL11, the configuration parameters settings between the two servers in order to get an apples ot apples comparison.123456789hared_buffers = 4GBtemp_buffers = 64MBwork_mem = 32MBmaintenance_work_mem = 1GBwal_level = minimalmax_wal_senders = 0max_wal_size = 40GBrandom_page_cost = 1.1jit = on Let’s try the JIT(For a simple demonstration, I will take these parameters as 0;):1234567891011121314151617181920212223242526272829303132[postgres@neoc bin]$ ./psqlpsql (11.2)Type "help" for help.postgres=# set jit=on;SETpostgres=# set jit_above_cost=0;SETpostgres=# set jit_inline_above_cost=0;SETpostgres=# set jit_optimize_above_cost=0;SETpostgres=# explain (analyze,verbose,costs,buffers,summary) select count(*) from pg_class; QUERY PLAN-------------------------------------------------------------------------------------------------------------------------------------------------------- Aggregate (cost=14.73..14.74 rows=1 width=8) (actual time=180.390..180.391 rows=1 loops=1) Output: count(*) Buffers: shared hit=22 read=1 dirtied=1 -> Index Only Scan using pg_class_oid_index on pg_catalog.pg_class (cost=0.27..13.76 rows=386 width=0) (actual time=0.393..0.618 rows=386 loops=1) Output: oid Heap Fetches: 183 Buffers: shared hit=22 read=1 dirtied=1 Planning Time: 2.060 ms JIT: Functions: 2 Options: Inlining true, Optimization true, Expressions true, Deforming true Timing: Generation 1.852 ms, Inlining 67.384 ms, Optimization 55.645 ms, Emission 56.331 ms, Total 181.213 ms Execution Time: 330.002 ms(13 rows) I used the tool pg_tpch to get the benchmarking results. For detailed usage, please refer to the URL: https://github.com/wangguoke/blog/blob/master/How%20to%20use%20the%20pg_tpch.md. We could get the results like this(unit is second, JIT disabled in PG11 and JIT enabled in PG11):The total is the sum of all 22 SQL execution times.To be more intuitive, we can look at the histogram: We will find that the execution time is reduced by turning on the JIT, about 6.1% down. With the JIT turned on, performance has dropped. It may be that my test case and hardware do not meet the test requirements.So I checked the explain. I found an interesting thing that the JIT disabled used less time than JIT enabled in the Nested Loop.JIT enabled in PG11:123456789101112131415161718192021222324252627---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Limit (actual time=72490.850..72624.050 rows=1 loops=1) -> Finalize GroupAggregate (actual time=71891.664..71891.664 rows=1 loops=1) -> Gather Merge (actual time=71891.649..72024.844 rows=4 loops=1) -> Sort (actual time=71799.894..71799.896 rows=53 loops=3) -> Partial HashAggregate (actual time=71799.269..71799.684 rows=175 loops=3) -> Hash Join (actual time=69631.747..71189.348 rows=1087902 loops=3) -> Parallel Hash Join (actual time=69310.166..70696.067 rows=1087902 loops=3) -> Parallel Seq Scan on public.orders (actual time=0.504..9327.128 rows=5000000 loops=3) -> Parallel Hash (actual time=57497.965..57497.965 rows=1087902 loops=3) -> Nested Loop (actual time=45.005..56802.904 rows=1087902 loops=3) -> Parallel Hash Join (actual time=44.034..5326.659 rows=145140 loops=3) -> Nested Loop (actual time=0.471..5146.321 rows=145140 loops=3) -> Parallel Seq Scan on public.part (actual time=0.030..353.243 rows=36285 loops=3) -> Index Scan using idx_partsupp_partkey on public.partsupp (actual time=0.122..0.130 rows=4 loops=108855) -> Parallel Hash (actual time=43.378..43.378 rows=33333 loops=3) -> Parallel Seq Scan on public.supplier (actual time=0.016..96.976 rows=100000 loops=1) -> Index Scan using idx_lineitem_part_supp on public.lineitem (actual time=0.086..0.351 rows=7 loops=435420) -> Hash (actual time=321.382..321.382 rows=25 loops=3) -> Seq Scan on public.nation (actual time=321.368..321.371 rows=25 loops=3) Planning Time: 30.108 ms JIT: Functions: 182 Options: Inlining true, Optimization true, Expressions true, Deforming true Timing: Generation 59.807 ms, Inlining 154.474 ms, Optimization 866.697 ms, Emission 539.179 ms, Total 1620.158 ms Execution Time: 72662.415 ms(142 rows) JIT disabled In PG11: 1234567891011121314151617181920212223---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Limit (actual time=53927.711..54069.684 rows=1 loops=1) -> Finalize GroupAggregate (actual time=53927.710..53927.710 rows=1 loops=1) -> Gather Merge (actual time=53927.698..54069.665 rows=4 loops=1) -> Sort (actual time=53885.863..53885.865 rows=54 loops=3) -> Partial HashAggregate (actual time=53884.461..53884.900 rows=175 loops=3) -> Hash Join (actual time=51626.569..53258.211 rows=1087902 loops=3) -> Parallel Hash Join (actual time=51624.992..53052.825 rows=1087902 loops=3) -> Parallel Seq Scan on public.orders (actual time=0.195..9286.259 rows=5000000 loops=3) -> Parallel Hash (actual time=40238.570..40238.570 rows=1087902 loops=3) -> Nested Loop (actual time=68.942..39704.018 rows=1087902 loops=3) -> Parallel Hash Join (actual time=68.193..5794.431 rows=145140 loops=3) -> Nested Loop (actual time=1.703..5596.634 rows=145140 loops=3) -> Parallel Seq Scan on public.part (actual time=0.209..289.795 rows=36285 loops=3) -> Index Scan using idx_partsupp_partkey on public.partsupp (actual time=0.136..0.144 rows=4 loops=108855) -> Parallel Hash (actual time=66.231..66.231 rows=33333 loops=3) -> Parallel Seq Scan on public.supplier (actual time=0.022..57.748 rows=33333 loops=3) -> Index Scan using idx_lineitem_part_supp on public.lineitem (actual time=0.069..0.231 rows=7 loops=435420) -> Hash (actual time=0.038..0.038 rows=25 loops=3) -> Seq Scan on public.nation (actual time=0.020..0.023 rows=25 loops=3) Planning Time: 16.777 ms Execution Time: 54071.434 ms(144 rows) So I tried to turn the enable_nestloop off. I got the results:JIT enabled in PG11:1234567891011121314151617181920212223242526272829---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Limit (cost=2417565.92..2417566.19 rows=1 width=66) (actual time=26286.402..28662.321 rows=1 loops=1) -> Finalize GroupAggregate (cost=2417565.92..2433857.53 rows=60150 width=66) (actual time=25747.698..25747.698 rows=1 loops=1) -> Gather Merge (cost=2417565.92..2431601.90 rows=120300 width=66) (actual time=25747.682..28123.594 rows=4 loops=1) -> Sort (cost=2416565.90..2416716.27 rows=60150 width=66) (actual time=25728.040..25728.045 rows=117 loops=3) -> Partial HashAggregate (cost=2410738.48..2411791.11 rows=60150 width=66) (actual time=25727.454..25727.844 rows=175 loops=3) -> Hash Join (cost=1936728.06..2388650.49 rows=1262171 width=57) (actual time=8919.348..25117.729 rows=1087902 loops=3) -> Parallel Hash Join (cost=1936726.50..2378463.21 rows=1262171 width=35) (actual time=8555.334..24580.928 rows=1087902 loops=3) -> Parallel Seq Scan on public.orders (cost=0.00..338723.33 rows=6250133 width=8) (actual time=0.034..567.581 rows=5000000 loops=3) -> Parallel Hash (cost=1911088.36..1911088.36 rows=1262171 width=39) (actual time=7466.736..7466.736 rows=1087902 loops=3) -> Parallel Hash Join (cost=1616063.36..1911088.36 rows=1262171 width=39) (actual time=6438.537..7258.071 rows=1087902 loops=3) -> Parallel Hash Join (cost=1612441.83..1904153.48 rows=1262171 width=47) (actual time=6431.432..7101.985 rows=1087902 loops=3) -> Parallel Seq Scan on public.partsupp (cost=0.00..216566.52 rows=3332652 width=22) (actual time=0.085..337.680 rows=2666667 loops=3) -> Parallel Hash (cost=1582415.26..1582415.26 rows=1262171 width=45) (actual time=5735.438..5735.438 rows=1087902 loops=3) -> Parallel Hash Join (cost=51923.86..1582415.26 rows=1262171 width=45) (actual time=87.559..5486.450 rows=1087902 loops=3) -> Parallel Seq Scan on public.lineitem (cost=0.00..1464889.92 rows=24990992 width=41) (actual time=0.019..3087.888 rows=19995351 loops=3) -> Parallel Hash (cost=51397.76..51397.76 rows=42088 width=4) (actual time=87.245..87.246 rows=36285 loops=3) -> Parallel Seq Scan on public.part (cost=0.00..51397.76 rows=42088 width=4) (actual time=0.016..243.671 rows=108855 loops=1) -> Parallel Hash (cost=2886.24..2886.24 rows=58824 width=12) (actual time=6.928..6.928 rows=33333 loops=3) -> Parallel Seq Scan on public.supplier (cost=0.00..2886.24 rows=58824 width=12) (actual time=0.012..8.941 rows=100000 loops=1) -> Hash (cost=1.25..1.25 rows=25 width=30) (actual time=363.979..363.979 rows=25 loops=3) -> Seq Scan on public.nation (cost=0.00..1.25 rows=25 width=30) (actual time=363.964..363.967 rows=25 loops=3) Planning Time: 2.046 ms JIT: Functions: 218 Options: Inlining true, Optimization true, Expressions true, Deforming true Timing: Generation 16.778 ms, Inlining 76.056 ms, Optimization 950.728 ms, Emission 602.449 ms, Total 1646.010 ms Execution Time: 28669.215 ms(152 rows) JIT disabled in PG11:123456789101112131415161718192021222324 Limit (cost=2417565.92..2417566.19 rows=1 width=66) (actual time=10543.751..10785.349 rows=1 loops=1) -> Finalize GroupAggregate (cost=2417565.92..2433857.53 rows=60150 width=66) (actual time=10543.751..10543.751 rows=1 loops=1) -> Gather Merge (cost=2417565.92..2431601.90 rows=120300 width=66) (actual time=10543.741..10785.333 rows=4 loops=1) -> Sort (cost=2416565.90..2416716.27 rows=60150 width=66) (actual time=10540.393..10540.396 rows=62 loops=3) -> Partial HashAggregate (cost=2410738.48..2411791.11 rows=60150 width=66) (actual time=10539.846..10540.206 rows=175 loops=3) -> Hash Join (cost=1936728.06..2388650.49 rows=1262171 width=57) (actual time=8494.973..9919.414 rows=1087902 loops=3) -> Parallel Hash Join (cost=1936726.50..2378463.21 rows=1262171 width=35) (actual time=8494.901..9720.725 rows=1087902 loops=3) -> Parallel Seq Scan on public.orders (cost=0.00..338723.33 rows=6250133 width=8) (actual time=0.021..634.898 rows=5000000 loops=3) -> Parallel Hash (cost=1911088.36..1911088.36 rows=1262171 width=39) (actual time=7348.100..7348.100 rows=1087902 loops=3) -> Parallel Hash Join (cost=1616063.36..1911088.36 rows=1262171 width=39) (actual time=6251.609..7135.988 rows=1087902 loops=3) -> Parallel Hash Join (cost=1612441.83..1904153.48 rows=1262171 width=47) (actual time=6240.936..6948.291 rows=1087902 loops=3) -> Parallel Seq Scan on public.partsupp (cost=0.00..216566.52 rows=3332652 width=22) (actual time=0.021..361.590 rows=2666667 loops=3) -> Parallel Hash (cost=1582415.26..1582415.26 rows=1262171 width=45) (actual time=5524.176..5524.176 rows=1087902 loops=3) -> Parallel Hash Join (cost=51923.86..1582415.26 rows=1262171 width=45) (actual time=120.604..5269.257 rows=1087902 loops=3) -> Parallel Seq Scan on public.lineitem (cost=0.00..1464889.92 rows=24990992 width=41) (actual time=0.023..2755.599 rows=19995351 loops=3) -> Parallel Hash (cost=51397.76..51397.76 rows=42088 width=4) (actual time=120.332..120.332 rows=36285 loops=3) -> Parallel Seq Scan on public.part (cost=0.00..51397.76 rows=42088 width=4) (actual time=0.013..114.142 rows=36285 loops=3) -> Parallel Hash (cost=2886.24..2886.24 rows=58824 width=12) (actual time=10.445..10.445 rows=33333 loops=3) -> Parallel Seq Scan on public.supplier (cost=0.00..2886.24 rows=58824 width=12) (actual time=0.010..5.438 rows=33333 loops=3) -> Hash (cost=1.25..1.25 rows=25 width=30) (actual time=0.026..0.026 rows=25 loops=3) -> Seq Scan on public.nation (cost=0.00..1.25 rows=25 width=30) (actual time=0.017..0.019 rows=25 loops=3) Planning Time: 2.665 ms Execution Time: 10785.906 ms(152 rows) If I turned the enable_nestloop off, time would be significantly reduced. But the query optimizer chose nested loop instead of others. I don’t know if this is a problem. If you want to know more details about explains, please refer to https://github.com/wangguoke/blog/tree/master/results%20about%20tpch. We could get the results like this(unit is second, JIT disabled in PG11 and PG10): To be more intuitive, we can look at the histogram:We could get that the performance of the PG11 is 41% higher than the PG10. This shows that PG11 has made a lot of improvements in performance. Please refer to the official documentation for detailed information. We could get the results like this(unit is second, JIT enabled in PG11 and PG10): To be more intuitive, we can look at the histogram:We could get that the performance of the PG11 is 37.1% higher than the PG10. overall summary of JIT performance:I think it is fair to say that JIT is not for every workload but one can get good perforamnce with JIT for right workload. In the case of this testing effort with OLAP benchmark. we can that JIT is giving good performance in case of 22 queries and in some queries the performance has degraded with JIT. It is difficult so say whether the performance degradation in case of some queries is due to the query optimizer it would be better if the optimizer could choose a better path. I believe this is compareable with Oracle Adaptive Execution Plans and optimizer Hint feature. Although Oracle seems to be losing in the cloud but its database technology still seems very advanced. It is worth trying out if query optimizer can convert the nestloop to hash join or others and see if that gives better performance. The underlying optimization technology of llvm is superior to humans. If there is a problem with the query optimizer, We can improve our query optimizer based on the information provided by LLVM . this is a large project.It is difficult so say whether the performance degradation in case of some queries is due to the query optimizer it would be better if the optimizer could choose a better path. I believe this is compareable with Oracle Adaptive Execution Plans and optimizer Hint feature. Although Oracle seems to be losing in the cloud but its database technology still seems very advanced. Its query optimizer can convert the nestloop to hash join or others if it needs. The underlying optimization technology of llvm is superior to humans. If there is a problem with the query optimizer, We can improve our query optimizer based on the information provided by LLVM but it seems far fetched. So I have 3 suggestions for Improvement: Add new parameters to find the right case for query optimizer. We can add some special passes for PostgreSQL. We can improve our query optimizer based on the information provided by LLVM. Reference https://www.postgresql.org/docs/11/runtime-config-developer.html https://www.postgresql.org/docs/9.6/parallel-query.html 《JIT-Compiling SQL Queries in PostgreSQL Using LLVM》 《The Architecture of Open Source Applications: LLVM》 Author Shawn Wang is a developer of PostgreSQL Database Core. He has been working in HighGo Software for about eight years.He did some work for Full Database encryption, Oracle Compatible function, Monitor tool for PostgreSQL, Just in time for PostgreSQL and so on.Now he has joined the HighGo community team and hopes to make more contributions to the community in the future.","link":"/2019/06/06/JIT/"},{"title":"Elephant-Shed","text":"介绍Elephant Shed 是一个基于网页版的postgreSQL前端管理软件。他捆绑了PostgreSQL的各项应用软件和组件。当前他能管理单点Debian/Ubuntu PostgreSQL服务起和应用。 主要组件包括如下： PostgreSQL - https://www.postgresql.org/ pgAdmin4 - https://www.pgadmin.org/ postgresql-common - https://anonscm.debian.org/cgit/pkg-postgresql/postgresql-common.git pgBadger - http://dalibo.github.io/pgbadger/ pgBackRest - http://www.pgbackrest.org/ Grafana - https://grafana.com/ Prometheus - https://prometheus.io/ Cockpit - http://cockpit-project.org/ Shell In A Box - https://github.com/shellinabox/shellinabox 增加的其他工具可以通过配置来设置。捆绑的组件和处理任务的数量会增加当前运行的服务器。因此仅建议用于足够大小的系统。 本文档描述了当前版本。本文档的更新版本将随 elephant-shed packages一起提供，可以在中找到/ usr / share / doc / elephant-shed-portal（/ usr / share / doc / elephant-shed *）和网站地址<https：// your-server / doc />。 安装Elephant Shed 包括如下安装包和依赖: elephant-shed:元数据包. elephant-shed-prometheus:Prometheus和他的输出的配置文件和帮助脚本. elephant-shed-cockpit:cockpit和cockpit-ws配置文件. elephant-shed-grafana:预配置的Prometheus数据源和仪表板，包括各种系统和PostgreSQL指标. elephant-shed-pgadmin4:pgAdmin4的配置文件. elephant-shed-pgbackrest:系统服务文件和生成器, 帮助脚本和预设配置. elephant-shed-pgbadger:系统服务文件, 生成器和帮助程序脚本. elephant-shed-portal:Elephant Shed web的Apache配置. elephant-shed-postgresql:PostgreSQL的其他预设配置文件. elephant-shed-shellinabox:Shell的配置文件. elephant-shed-tmate:更容易支持的预配置tmate的安装包. 安装包重构包可从该网址获得 https://packages.credativ.com/public/postgresql/. 存储库包括该包 elephant-shed. 该包包括 Grafana, Cockpit and various python 包. 在Debian和Ubuntu上安装123456789101112131415161718192021# 安装工具sudo apt-get install curl ca-certificates apt-transport-https# 使用官网 PostgreSQL存储库, apt.postgresql.orgecho "deb http://apt.postgresql.org/pub/repos/apt/ stretch-pgdg main" | sudo tee -a /etc/apt/sources.list.d/pgdg.listcurl https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -# 使用 credativ 存储库, packages.credativ.comecho "deb https://packages.credativ.com/public/postgresql/ stretch-stable main" | sudo tee -a /etc/apt/sources.list.d/elephant-shed.listcurl https://packages.credativ.com/public/postgresql/aptly.key | sudo apt-key add -# 安装 elephant-shedsudo apt-get updatesudo apt-get install elephant-shed# 选择适合的PostgreSQL版本安装sudo apt-get install postgresql-10# 允许群组“elephant-shed”中的每个用户在门户网站上登录# 加入该群sudo adduser <USERNAME> elephant-shed 在RedHat和CentOS系统上安装Elephant Shed 可以在PostgreSQL RPM中安装有关的包到yum.postgresql.org网站安装适合PostgreSQL版本的安装包.然后再安装Elephant Shed. 12345678910111213141516171819202122# 使用credativ存储库(也将下载EPEL)sudo yum install https://packages.credativ.com/public/postgresql/yum/credativ-repo.rpm# 在RedHat上, 激活其他存储库 (不是在CentOS上)subscription-manager repos --enable=rhel-7-server-extras-rpmssubscription-manager repos --enable=rhel-7-server-optional-rpms# 选择需要的 PostgreSQL 版本安装sudo yum install postgresql11-server postgresql11-contrib postgresql-commonsudo pg_createcluster 11 main --start# 安装 elephant-shedsudo yum install elephant-shed# 所有在 \"elephant-shed\"组里的用户都可以登陆网页# 把所有需要的用户都加进这个组里sudo vigr# 不幸的是, pgAdmin4和shellinabox不支持SELinux# 如果要使用这些组件，请禁用SELinuxsudo setenforce 0sudo sed -i -e 's/^SELINUX=.*/SELINUX=permissive/' /etc/selinux/config 源码安装源码可以在github上获得: https://github.com/credativ/elephant-shed 源码构建Debian包所有 Elephant Shed Debian 包可以用该命令构建 make deb. 要求: dpkg-dev devscripts 构建文档把文件构建成 HTML 格式类型 make docs. 要求: sphinx 创建Vagrant测试make vagrant 该命令构建所有组件, 用Vagrant创建一个新的虚拟机，用Ansible部署软件.该命令也可以重新部署已经运行的机器. Vagrant 配置文件在该目录 vagrant/Vagrantfile. 要求: vagrant virtualbox 或者 libvirt ansible 部署到远程服务器部署软件到任何一台机器上, 连接的相关信息在该目录 vagrant/inventory.部署开始命令 make ansible. 要求: ansible 第一步登陆到游览器，输入服务器地址 (e.g.https://your-server/). 默认配置重定向到HTTP请求到HTTPS. Elephant Shed官网提供了运行PostgreSQL的例子和他的情况. 此外你也获得了其他已安装的组件. 服务起会向你要用户证书。每个部署程序区分每个用户不同. 在测试安装中(e.g. using Vagrant) 初始化用户是 admin 密码是 admin. 可以看下: Users. 所有绑定的组件除了pgAdmin4都使用PAM 授权。 pgAdmin4 还不支持 PAM 授权. 它有自己的用户管理系统与所有系统用户分离.在安装配置中你会被要求安装初始化用户配置. 如果你部署了Vagrant 虚拟机， 初始化用户就是 admin@localhost，密码是 admin. 在新安装中，您将找到一个运行当前PostgreSQL主要版本的集群，其名称为 main. 集群配置在这 /etc/postgresql/<major version>/<name>/. 要从外部应用程序服务器使用PostgreSQL，只需要几个步骤. 使用SSH或shellinabox打开一个shell去连接服务器 https://your-server/shellinabox. 切换用户 postgres 然后psql: sudo -u postgres psql 创建一个数据Create a database 和相应的应用用户, 可以选: psql: CREATE ROLE appuser1 WITH LOGIN PASSWORD 'testpass'; psql: CREATE DATABASE appdb1 OWNER appuser1; 允许应用程序服务器的外部访问，开放给网络中每个人. 配置文件: /etc/postgresql/<major version>/<name>/pg_hba.conf (可选) 进行所需的配置更改和调整. /etc/postgresql/<major version>/<name>/postgresql.conf 重新加载配置，选项: 主页: 点击按钮 Service 下一步集群 ，然后在下拉菜单中选择 “Reload” psql: SELECT pg_reload_conf(); (可选) 配置超级用户以便能够使用pgAdmin4 https://your-server/pgadmin4 or other management tools 为用户postgres创建密码: \\password 创建个性化的超级用户: CREATE USER "sosna" SUPERUSER;, \\password "sosna" 组件PostgreSQLElephant Shed基于postgresql-common，默认的PostgreSQL基于Debian的安装管理系统。创建，删除等任务或重命名PostgreSQL实例（PostgreSQL术语中的“集群”）应该是通过postgresql-common的命令行实用程序pg_createcluster，pg_dropcluster和pg_renamecluster完成。 默认配置Beside the postgresql-common default configuration theelephant-shed-postgresql package adds additional parameters for the clustercreation process. Some of these parameters are required by theElephant Shed components. E.g. pgBadger requires some speciallog_line_prefix. You can find this configuration under/etc/postgresql-common/createcluster.d/elephant-shed.conf. Becareful when changing any of these values. 集群管理创建新集群命令 pg_createcluster <version> <name>.通过命令pg_lsclusters安装集群和相关情况. 123456postgres@stretch:~$ pg_lsclustersVer Cluster Port Status Owner Data directory Log file9.6 main 5432 online postgres /9.6/main /log/9.6-main.log9.6 standby1 5433 online,recovery postgres /9.6/standby1 /log/9.6-standby1.log9.6 standby2 5434 online,recovery postgres /9.6/standby2 /log/9.6-standby2.log9.6 test 5435 online postgres /9.6/test /log/9.6-test.log 删除集群命令 `pg_dropcluster ` (注意，会删除集群中的所有数据！). 开始, 停止, 重启 或者 重载使用的命令是 `pg_ctlcluster ` 如下: start stop restart reload 另外,你能用 systemctl (systemctl <action> postgresql@<version>-<name>) 或者 Cockpit web interface. 注意: The Elephant Shed 将来的版本将会包含集群管理 portal. 门户网站门户网站是所有其他基于Web的入口点接口。它使用HTTPS和基本身份验证。每个用户在Unix组中，elephant-shed可以访问它（参见[Users]（＃users））。 门户网站还显示所有状态PostgreSQL集群包括指向Cockpit服务的链接（为了启动或停止集群），日志文件，pgBadger报告和备份软件pgBackRest。 顶部的导航栏允许在不同的网络之间切换服务。 默认情况下，仅部署HTTPS的自签名证书。一个大多数浏览器都会显示相应的安全警告。你可以改变签名证书（例如来自您的公司CA，或来自[Let’s Encrypt]（https://letsencrypt.org/））。Web服务由Apache2提供。它还充当反向代理，以服务所有其他Web界面并实施身份验证。 PostgreSQL 集群 本节概述了现有的PostgreSQL集群及其状态。每个集群都能开关显示当前状态。通过单击群集，将打开带有按钮的附加菜单。目前，所有按钮都链接到需要确认的相应组件，因此不会直接触发任何操作，但这可能会在将来发生变化。 systemd - Service这链接到Cockpit中此PostgreSQL集群的配置。这里可以配置在系统启动时启用或禁用相应的服务，还可以触发启动，停止和重新加载等操作。 systemd - Log如果为此群集启用了syslog（这是Elephant Shed创建的群集的默认设置），则链接到Cockpit中的相应日志条目。 Report - Run默认情况下，每晚生成一次所有群集的pgBadger报告。使用此服务，可以根据需要为特定群集生成报告。 Report - Show链接到相应的pgBadger报告概述。查看 pgBadger获得更多信息. Backup本节提供了几个使用pgBackRest进行备份的功能。了解更多备份工具pgBackRest，可访问网站pgBackRest. Full链接到Cockpit以启动临时完整备份。 Incremental链接到Cockpit以查看临时增量备份。 Info显示备份的状态。此按钮仅在第一次备份运行后显示。此处显示可用备份和WAL归档的内容。 获得更多信息: http://www.pgbackrest.org/user-guide.html#quickstart/backup-info SwitchesArchiving此开关显示是否设置了使用pgBackRest的存档命令。可以使用’/ bin / true’设置一个或停用该功能。时间点恢复需要存档，但对于pgBackRest备份更为重要。如果通过门户或计时器触发备份，则会自动激活存档。 手动更改服务 pgbackrest-toggle-archiving@<version>-<name>.service.可以切换状态. 全备切换到启用或禁用定期备份。已启用的备份作业（systemd timer）以绿色显示。启动或停止计时器 pgbackrest@<version>-<name>.timer.启用/禁用用于在下次重启后启用/禁用计时器。 增量备份切换到启用或禁用定期备份。已启用的备份作业（systemd timer）以绿色显示。要启动/停止计时器pgbackrest-incr @ <version> - <name> .timer。启用/禁用用于在下次重启后启用/禁用计时器。 网页服务接口 - CockpitCockpit 允许通过HTTPS远程管理所有系统的服务。就像按下按钮使得启动、停止、重启服务如此简单. 还实时显示系统日志. 监控 - PrometheusPrometheus是一种基于度量的服务器和服务监控系统。它以给定的时间间隔从配置的目标收集指标，评估规则表达式，显示结果，并且如果观察到某些条件为真，则可以触发警报。 服务在此设置中，Prometheus堆栈由systemd控制的不同组件组成。部署了以下功能。 prometheus.service监控系统和时间序列数据库 - 这是监控服务本身。它主动从不同来源提取指标。它还提供内部指标和可通过门户访问的Web界面。 配置文件: /etc/prometheus/elephant-shed-prometheus.yml /etc/default/elephant-shed-prometheus prometheus-node-exporter.service机器指标的Prometheus导出器 - 此服务导出系统指标并侦听端口9100。默认情况下，这些指标每30秒收集一次。 配置文件: /etc/default/elephant-shed-prometheus-node-exporter prometheus-sql-exporter.service用于SQL指标的Prometheus导出程序 - 此服务收集PostgreSQL特定指标并侦听端口9237。通过查询数据库来检索度量标准。为了不产生额外的负载，仅每60秒收集度量。 警告: 不建议将prometheus-sql-exporter的监视间隔设置为低于60秒。这可能会干扰正常的应用程序，并对PostgreSQL集群产生很大影响. prometheus-sql-exporter.service在启动时启动与每个数据库的一个连接，并保持此连接打开。在每个连接的开头，prometheus-sql-exporter.service检查是否存在扩展名pg_stat_statements。如果没有，该服务发出语句CREATE EXTENSION pg_stat_statements。 配置文件: /etc/prometheus-sql-exporter.yml update-prometheus-sql-exporter-config.timer此计时器定期触发update-prometheus-sql-exporter-config.service，每10分钟为prometheus-sql-exporter生成一个新配置。这可确保每个新数据库集群和每个新数据库都自动包含在监视中。可以手动调用update-prometheus-sql-exporter-config.service直接生成新配置。 配置模板文件: prometheus-sql-exporter.yml.in 配置 (运行): prometheus-sql-exporter.yml 更多资源 https://prometheus.io/docs/introduction/overview/ https://github.com/prometheus/prometheus看板 - Grafana Grafana是一种从各种不同数据源创建图形和仪表板的工具。默认安装的一个PostgreSQL看报包含最需要的相关指标和调试PostgreSQL服务。 这些预先部署的仪表板通过elephant-shed-graphana Debian软件包，并可在将来更改。它们是只读的，如果您进行任何更改，则需要以新名称保存。 PostgreSQL Server 概貌 此仪表板以带有简单仪表的摘要部分开始，以提供整个系统的概述。这些仪表可能表明当前存在的问题，或暗示未来可能出现的问题。 仪表深度指标显示为图形。 服务起指标服务器指标包括：CPU使用率（按类型/核心），磁盘使用情况，磁盘利用率，网络吞吐量等等。配置以下模板筛选器： Disk: 过滤一个或多个磁盘 Interface: 过滤一个或多个接口 Filesystem: 过滤或更多文件系统/挂载点 集群指标下一节包含PostgreSQL集群范围的指标，如连接（按类型/按数据库），事务数量，数据库增长等。一次只显示一个群集。要切换当前显示的集群，请使用模板过滤器PostgreSQL Cluster。 数据库指标数据库级别度量标准显示在 PostgreSQL Overview 仪表板的末尾。默认情况下，会显示当前所选PostgreSQL群集的所有数据库的度量标准。要过滤一个或多个数据库，可以使用模板过滤器“Database”。 更多资源 http://docs.grafana.org/ https://github.com/grafana/grafana DBA 工具 - pgAdmin4 pgAdmin4是PostgreSQL的一个管理工具，可以帮助DBA执行许多不同的任务。它提供用户管理，DDL功能，交互式SQL shell等。 更多资源 https://www.pgadmin.org/docs/pgadmin4/1.x/ 备份 - pgBackRestElephant Shed附带预装的备份解决方案 pgBackRest 。每个PostgreSQL实例都可以通过发出命令systemctl start pgbackrest @ <version> - <name>或通过Web界面中的Cockpit启动备份来单独备份。为每个实例列出了一个快捷方式。 使用第一个创建每个群集的配置条目备份运行。默认情况下，只设置db-path和db-port。 单击在门户网站上的图标pgBackRest可以获得所有备份的列表 pgBackRest知道3种类型的备份完整，增量和差异。我们默认使用完整和差异。默认情况下不安装差异备份的服务文件。 全量备份全量备份表示在给定时间点对数据库的全量备份。备份由两部分组成，备份本身存储在backup中，WAL文件在备份期间写入，存储在archive中。 为了确保这些WAL文件在归档中，我们在创建第一个备份之前自动启用WAL归档。 警告:如果启用了归档，则保留所有比最早存储的备份更新的WAL文件。如果备份保留很长时间并且未禁用存档，则会占用备份位置中的大量空间。通过删除备份，不再需要的WAL文件也被删除。 增量备份增量备份表示先前全量备份与给定点上的当前数据之间的已更改数据。增量备份可能比全量备份小很多，但依赖于特定的先前全量备份。如果没有此全量份，则无法恢复。 保留要清理空间，需要删除旧备份。pgBackRest需要知道要保留多少全量备份。如果达到该数量，将从最旧的备份开始删除所有其他备份。如果删除全量备份，则还将删除所有依赖于它的增量备份。这是必要的，因为如果没有匹配的全量备份，则无法还原增量备份。 配置配置文件目录 /etc/pgbackrest.conf. 12345678910[global]repo-path=/var/lib/pgbackrest[9.6-main]db-path=/var/lib/postgresql/9.6/maindb-port=5432[9.6-test]db-port=5433db-path=/var/lib/postgresql/9.6/test 全局部分为每个现有和未来的数据库集群设置默认配置。对于每个单个群集，可以更改这些默认值。这里将解释一些基本选项。有关完整概述，请参阅文档。 如果服务是用ansible设置, 另外还设置了以下[global]参数： 12345678[global]retention-full=4compress-level=6spool-path=/mnt/backup/pgbackrest_spoolarchive-async=yarchive-queue-max=1099511627776repo-path=/mnt/backup/pgbackrest... retention-full此选项定义应保留多少完整备份。 危险: 如果存储的完整备份比retention-full更多，pgBackRest将删除最旧的备份以保持完全备份！保留完整备份！ compress-level要使用的gzip压缩级别（6是默认值）. archive-async启用WAL文件的异步归档，从而实现更高的归档吞吐量。 spool-path在哪里保留异步归档的附加信息（状态目录）。 archive-queue-max丢弃段之前要保留多少个WAL段。注意：我们配置1TB的值以确保pgbackrest默认情况下永远不会抛出WAL段 repo-path这将设置存储备份和WAL文件的主目录。它可以设置为任何所需的安装点，因此可以轻松地备份到远程服务器。 Backup对于每个群集，都有一个systemd服务，它执行完整或增量备份。 pgbackrest@\\<version>-\\<name> pgbackrest-incr@\\<version>-\\<name> 要创建临时备份，可以启动相应的服务。systemctl start pgbackrest @ 9.6-main将创建集群9.6-main的完整备份。 如果没有以前的完整备份可用，pgbackrest-incr @也将创建一个完整备份。 Automation要自动创建备份和执行保留策略，每个群集有两个systemd计时器。 pgbackrest@-.timer pgbackrest-incr@-.timer pgbackrest @ <version> - <name> .timer触发完整备份，pgbackrest-incr @ <version> - <name> .timer触发增量备份。 这些计时器是为每个集群创建的，并使用默认时序进行初始化。可以通过systemd或Web门户为每个数据库集群独立启用计时器。要完全启用定时备份， timer 必须 started 和 enabled.如果 timer 是 started 但是没有 enabled ，systemd 在重启后不启动timer. 请记住，仅启用增量备份仅适用于较短的时间段，特殊情况（如不更改数据库）或完整备份是以其他方式触发的。为了将存储和恢复时间保持在合理的水平，需要定期进行完全备份。 pgbackrest@.timer12345678910# /lib/systemd/system/pgbackrest@.timer[Unit]Description=Automated pgBackRest full backup of PostgreSQL cluster %i[Timer]OnCalendar=Sun *-*-* 01:00:00RandomizedDelaySec=2h[Install]WantedBy=multi-user.target 此计时器每周日凌晨01:00或随机最多2小时后触发完整备份。由RandomizedDelaySec = 2h设置的随机延迟被设置，因此systemd可以在给定的时间范围内调度许多定时器。这么做是为了所有集群的备份不是在同一个时间启动，阻塞了I/O pgbackrest-incr@.timer12345678910# /lib/systemd/system/pgbackrest-incr@.timer[Unit]Description=Automated pgBackRest incremental backup of PostgreSQL cluster %i[Timer]OnCalendar=Tue,Thu *-*-* 01:00:00RandomizedDelaySec=2h[Install]WantedBy=multi-user.target 此计时器每周二和周四凌晨01:00或随机最多2小时后触发增量备份。 WAL 归档默认情况下，对于新的PostgreSQL集群，将禁用WAL归档。它可以使用门户网站（参见[portal]（＃portal））或启动pgbackrest-toggle-archving.service来激活。该服务将归档模式切换为打开或关闭，具体取决于之前的状态。 注意：如果禁用归档并启动完整或增量备份（手动或通过计时器），则会自动启用归档。需要执行此步骤以确保还原所需的所有WAL文件都存档在basebackup。Archiving is not disabled after the backup run. 还原还原是一种侵入性操作，如果未正确执行，可能会破坏数据! 要还原备份，有两个主要方法full和delta。 Full Restore根据给定的备份全部还原（默认情况下为最新）还原到给定（默认）目标。还原命令要求目标目录为空。.此方法可用于新的机器，小型集群，或者是大部分数据不正确的情况下. 步骤如下. Stop the cluster (if still running) Delete or move all remaining data Restore full content from backup 使用用户 postgres操作. 123456789# 1. 停止集群pg_ctlcluster <major version> <name> stop# 2. 删除或移除所有存在数据mv /var/lib/postgresql/<major version>/<name> /var/somewhere-savemkdir /var/lib/postgresql/<major version>/<name># 3. 从备份中还原所有数据pgbackrest --stanza=<major version>-<name> restore 然后再次重启集群.如果有足够的可用存储空间，则最好将数据移动到保存位置而不是删除。 Delta 还原增量恢复不需要干净的目标，只能复制与备份不同的文件。这种方法可以快得多，特别是如果大多数底层文件自上次备份以来没有改变。 这有可能破坏数据!因为这应用于集群数据，可能会造成损害。数据不在备份/ WAL存档中而在当前群集中的将会丢失！ 操作一个 delta 还原. 停止集群 (如果在运行中) 从备份中还原所有内容 12345# 1. 停止集群pg_ctlcluster <major version> <name> stop# 2. 从备份中还原所有内容pgbackrest --stanza=<major version>-<name> --delta restore 操作完后重启 时间点恢复该方法是全部还原.这意味着所有basebackup文件并从存档中复制回来并应用所有WAL文件. 如果要恢复另一个恢复目标，则必须指定--type和--target。大多数时候，人们希望将数据库恢复到给定的时间点（例如’2017-08-24 12:00:00’）。这将需要切换--type = time和--target ='2017-08-24 12：00：00'。 1pgbackrest --stanza=<major version>-<name> --type=time --target="<ISO timestamp>" restore 更多资源 http://www.pgbackrest.org/user-guide.html http://www.pgbackrest.org/command.html http://www.pgbackrest.org/configuration.html 报告 - pgBadger为每个PostgreSQL创建一个pgBadger服务实例。每次新的时候都会自动生成和更新这些服务创建或删除集群（systemd-generators）。 pgBadger systemd计时器可确保定期更新报告。默认情况下，这是每天23:00。 每个pgBadger服务解析的PostgreSQL相应PostgreSQL实例的日志文件. 生成的报告保存在其中/var/lib/pgbadger/<version>-<name> (e.g. /var/lib/pgbadger/9.6-main/). 可以在Web界面中访问所有报告。日历提供对每日和每周报告的访问。 可以使用相应的服务（例如pgbadger @ 9.6-main.service）或使用[portal]（＃portal）触发这些报告的手动更新。所有报告的更新可以使用该服务 pgbadger.service触发. 注意: 更改postgresql.conf设置，如log_line_prefix或lc_messages可能导致pgBadger报告不再被更新。 Web 终端 - Shell In A BoxShell In A Box是一个方便的基于Web的终端。它可以像普通的控制台连接一样使用。需要显式登录和身份验证。要更改设置（例如颜色主题），只需右键单击终端窗口上的任意位置即可。 更多资源 https://github.com/shellinabox/shellinabox 防火墙 - ferm默认情况下，ferm作为前端安装，用于创建iptables规则。默认配置部署在以下位置： /etc/ferm.conf /etc/ferm.d/elephant-shed.conf 传入流量的默认策略设置为DROP。允许本地流量，我们明确将以下传入流量列入白名单： state RELATED,ESTABLISHED ICMP (ping) SSH HTTP / HTTPS PostgreSQL: Ports 5432-5439 (first 8 clusters) 网络访问的每个附加服务也需要列入白名单。要配置自己的防火墙规则，只需在/ etc / ferm.d /中创建一个扩展名为.conf的ferm配置。这些配置文件在重启时由ferm自动加载。 注意: Prometheus和Grafana等服务默认只能通过管理身份验证的反向代理。如果提供这些服务通过网络可以到达，必须采取预防措施。 更多资源 http://ferm.foo-projects.org/ https://wiki.debian.org/ferm 远程控制 - tmatetmate是流行的终端多路复用器tmux的分支。如果需要，它用于提供远程支持。 它预先配置为连接到中继服务器（tmate.credativ.com），并允许用户通过发送包含秘密令牌的SSH命令与第三方共享当前终端。 有两种操作模式，读写和只读。这使用户能够向第三方临时访问当前终端。用户可以随时观看终端并审核第三方采取的行动。 tmate 默认不运行，需要时再运行 当启动shell关闭时，连接也会关闭 使用的后端是完全可配置的（在/etc/tmate.conf中）并预设为tmate.credativ.com tmate包含在技术预览中以评估潜力 Usage开始 tmate (打开一个终端) 1tmate 显示需要提供给第三方的凭证（安全） 1tmate show-messages 有关进一步的用法，请参阅以下有关tmux的其他资源。 更多资源 https://tmate.io/ https://man.openbsd.org/OpenBSD-current/man1/tmux.1 配置修订 - etckeeperetckeeper是一组工具和钩子，用于将所有配置保存在git存储库中的/ etc中。提交可以手动完成，也可以通过时间或包管理器挂钩自动完成。 可以查看配置更改并与以前的版本进行比较。如有必要，可以恢复以前的设置。 更多资源 https://etckeeper.branchable.com/ https://www.thomas-krenn.com/de/wiki/Etc-Verzeichnis_mit_etckeeper_versionieren 用户网页受密码保护(HTTP 基本授权) ，通过PAM使用系统用户. 通过Ansible部署时, 初始化用户 admin 密码 admin. 该用户可以用户网页可以用户SSH和PostgreSQL。 创建新用户, 使用adduser, 增加该用户到 elephant-shed 群. 12adduser myonadduser myon elephant-shed 在 RedHat/CentOS, 使用 vigr 增加新用户到 elephant-shed 群. 限制以下支持的 PostgreSQL 版本: 11 10 9.6 9.5 9.4 其他版本可用但未完全集成在所有组件中。这可能需要额外的手动调整。 所有PostgreSQL版本的软件包都可以通过Debian / Ubuntu上的 apt.postgresql.org 存储库安装，和RedHat / CentOS上的 yum.postgresql.org 。更多信息查看网站 https://apt.postgresql.org/. 已知的错误和问题PostgreSQL prometheus-sql-exporter监视代理程序永久保留连接对所有数据库开放，这会阻止DROP DATABASE工作。要删除数据库，请先停止prometheus-sql-exporter。这可以通过Web界面Cockpit实现：[services＃/ prometheus-sql-exporter.service]（/ system / services＃/ prometheus-sql-exporter.service）。 pgadmin4 pgadmin4 不使用PAM授权。 默认情况下，pgadmin4 不显示本地数据库. Portal 注销后直接重新登录不起作用。重新加载页面是必要的。 RedHat / CentOS 当S​​ELinux启用时，pgAdmin4不起作用. 当SELinux启用时，shellinabox不起作用.证书 Elephant Shed itself 证书在 GPLv3 (https://www.gnu.org/licenses/gpl-3.0.de.html). 所有捆绑组件都是免费/开源软件，具有已知且经过批准的开源许可证。 支持和更多你有问题吗？或想要知道的更多？ Project page elephant-shed.io Git github.com/credativ/elephant-shed Web-Chat #elephant-shed IRC #elephant-shed on irc.oftc.net 你需要专业支持或者更多服务吗？Elephant Shed 是一个开源项目, 开发维护是由 credativ. 对于Elephant Shed PostgreSQL应用, credativ 提供全面的技术支持, 一年365天，一天24小时提供服务. 安装和集成支持，以及介绍也是Elephant Shed PostgreSQL credativ其中一部分服务。如果您有兴趣，请随时与我们联系。 Web credativ.de E-Mail: info@credativ.de Phone: +49 2166 9901-0","link":"/2019/06/04/elephant-shed/"}],"tags":[{"name":"Pakistan highgo","slug":"Pakistan-highgo","link":"/tags/Pakistan-highgo/"},{"name":"JIT Postgresql","slug":"JIT-Postgresql","link":"/tags/JIT-Postgresql/"},{"name":"postgresql","slug":"postgresql","link":"/tags/postgresql/"},{"name":"elephant-shed","slug":"elephant-shed","link":"/tags/elephant-shed/"}],"categories":[{"name":"news","slug":"news","link":"/categories/news/"},{"name":"JIT","slug":"JIT","link":"/categories/JIT/"},{"name":"postgresql","slug":"postgresql","link":"/categories/postgresql/"}]}