title

text

M
Mikhail Moscovskiy Postgres Professional
10:00 21 June
45 мин

Physical replication speed in PostgreSQL

Replication is one of the important mechanisms designed to provide database fault tolerance and scalability. In our practice, we regularly encounter the problem of low replication performance. This prompted us to investigate the factors that affect the speed of physical replication. In this presentation, I will talk about our findings. I will also demonstrate the differences in replication performance for various versions of PostgreSQL.

Материалы к докладу

Слайды

Видео

Видео доступно только участникам мероприятия, выполнившим вход в личный кабинет

Другие доклады

  • Vladimir Surdin
    Vladimir Surdin МГУ
    45 мин

  • Denis Sukhovei
    Denis Sukhovei Аладдин Р.Д.
    Alexey Sabanov
    Alexey Sabanov АО "Аладдин Р.Д."
    45 мин

    Database management systems: from software import substitution to technological sovereignty

    The myths and misconceptions of software import substitution. The acute threat of non-working DBMS servers. The basic plans for import substitution and problems of the transition period. DBMS data protection and the image of an ideal protection system. Crypto BD is the cryptographic data protection system. How does it work?

  • Anatoly Anfinogenov
    Anatoly Anfinogenov АО "ВНИИЖТ"
    45 мин

    Life after migration to PostgreSQL: configuring the database and stored procedures

    Many books end with a wedding, but the reader has no idea about the future life of the heroes except that they lived happily ever after. In 2019, we successfully migrated distributed our railway application from Oracle 11g SE to vanilla PostgreSQL 11.9. But our story did not end with this successful migration - life went on, and sometimes we got startled because of "surprises". We encountered a number of problems, some of which were solved by reorganizing the data, some disappeared after we changed our stored procedures, and some got resolved after tuning the PostgreSQL parameters. Solving our problems would be impossible without the logging and profiling system built into our DB application. Our talk covers the examples of successful detection and resolving of the performance issues that occurred in our PostgreSQL-based application.

  • Vadim Yatsenko
    Vadim Yatsenko Tantor Lab
    45 мин

    Harmful advice on autovacuum you shouldn't ever follow

    PostgreSQL has a number of peculiarities that you need to take into account not only while maintaining your database but also when designing your database schema. Experienced PostgreSQL are well aware of vacuuming process. On the web one can find tons of materials covering its internals, configurations and monitoring. Many valuable talks about vacuum were given at numerous conferences. However, we still face the common wraparound problem when the maximum possible number of transactions (xid) is reached. It happens even on databases that are relatively small in size. In my presentation, I will share a customer case that looks interesting to me. A chain of mistakes made at different stages of the database's life cycle once caused a disaster. The database fully stopped for one week, we detected a wraparound and spotted corrupted blocks. Maintenance was problematical, and we spent sleepless nights in search of a solution. We managed to achieve a local win as we finally restored the database, but it's not the end of this story, which makes it even more interesting.