PgConf.Russia 2020

In Zabbix-server 4.4, a new Zabbix-agent has become available. It is written in Golang, has a plug-in structure, keeps a permanent connection and makes it possible to control metrics in runtime. We will make an overview of the Zabbix-agent 2 and talk about how to develop plugins for it, in particular, the PostgreSQL monitoring plugin developed by Postgres Professional in collaboration with Zabbix.

Will be demonstrated in the master-class the following: 1). The benefits of declarative programming. Rapid creation of complex LUI-forms using only SQL. 2). Support for long transactions and automatic locks. An example of a wizard with a record directly in the database. 3). The multilingual fields and columns. Rapid inclusion of multilingualism in existing forms. 4). Control the coloring of data in fields and columns of the form. Typical examples. 5). Live search in input fields using the example of address input. 6). How to configure the LUI to enter and display of application-specific data. 7). Design form Master Detail with retrieving data from two different databases. 8). How end-user builds of complex data queries without using SQL.

Cloud storage has some unique characteristics compared to traditional storage mainly because it is virtualized and controlled by software. One example is that AWS EBS shows higher throughput with larger I/O size up to 256 KiB without hurting latency. Hence, a user can get only about 4 MiB/sec with 1,000 IOPS EBS volume if the I/O request size is 4 KiB, whereas a user can get about 250 MiB/sec if the I/O request size is 256 KiB. This is because EBS consumes one I/O in a given IOPS budget for every I/O request regardless of the I/O size (up to 256 KiB). Unfortunately, PostgreSQL cannot exploit the full potential of cloud storage because PostgreSQL has designed without considering the unique characteristics of cloud storage.

In this talk, I will introduce the AppOS extension that improves the throughput of a write-intensive workload by 10x by transparently making PostgreSQL cloud storage-native. AppOS works like a storage driver that efficiently exploits the characteristics of cloud storage, such as I/O size dependency to storage throughput and latency, atomic write support in cloud block storage, and fast, but non-durable local SSDs. To do this, AppOS comprises a Linux-compatible file I/O stack including virtual file system, page cache, block I/O layer, cloud storage driver. On top of the file I/O stack, syscall module supports registering pre- and post-handler for file I/O-related system calls in order to transparently work without modifying PostgreSQL codes.

I will focus on presenting key use cases and performance results of the AppOS extension after explaining the internals. Specifically, I will show the performance results of OLTP and some batch workloads using standard benchmarking tools like pgbench and sysbench. I will also present performance results and implications on multiple clouds including AWS, GCP, and Azure.

Corosync & pacemaker is a well known solution for creating fault-tolerant clusters. Such clusters can contain 3 working nodes or 2 working nodes and one voting-only node. The cluster can be deployed on physical or virtual servers.

This tutorial will demonstrate the process of installation and tuning of a PostgreSQL fault-tolerant cluster. You will learn that it is not so difficult as seems to be from the first glance.