PgConf.Russia 2020

Patroni and Stolon are two of the most popular and advanced solutions for orchestrating PostgreSQL and ensuring auto-failover for clusters with the Leader-Followers configuration. However, engineers who migrate from good old tools like Corosync&Pacemaker or built-in solutions of other DBMS often run into issues when installing these tools and figuring out the purpose of each component.
In this tutorial, we will go through a typical installation procedure of Patroni and Stolon clusters on virtual machines (not in containers), as well as review their behavior in case of various infrastructure failures. The whole process will be demonstrated on three vagrant virtual machines with pre-built images. You can follow along on your own system if you set up the required environment.

In this tutorial, we will solve several programming problems using JSON functionality that extends SQL capabilities and virtually turns a relational database into an almost ready-to-use application server. :)
We will learn how to use aggregates, both standard and custom, as well as review possible benefits of JSON recursive structure.

Today no one is surprised by cloud infrastructure anymore, but not all its components are easy to deploy in cloud. For example, the database is always very demanding in terms of performance and resources. Scaling and fault tolerance are the most acute problems, that's why we have been observing rapid development of alternative DBMS in the recent years. However, traditional relational DBMS have already accumulated a lot of various features, so they often remain the first choice. Besides, they are constantly evolving and offer a wide variety of scaling tools. I will mainly speak about PostgreSQL, when you should consider scaling, and how to do it right.

We will touch upon the following topics:
- Streaming replication and balancing read/write workloads
- Logical replication and data sharding
- High availability and fault tolerance

This talk should be interesting to DBAs, system administrators, team leads, infrastructure architects, as well as wider audience dealing with PostgreSQL.

Any DBA needs some kind of tool for historical workload analyse. Assume once at morning your monitoring team will report of sudden performance degradation at 2-3 a.m., and now you need to investigate this issue. What activities was most resource consuming within that hour? There are several tools for solving this problem, and I'll talk about one very easy and convenient tool - pg_profile. It need only a postgres database and a cron-like tool to run, and it will generate a workload profile report for your database as you need it. Ths report will be a good start point for further investigation.