How we switched Oracle for PostgreSQL for a client, before it became mainstream
The history of import substitution did not start last year after well-known events. Its launch dates back to 2014. It was from this year that state and near-state companies began to think of switching to the so called "recommended software". One of these companies approached us back in 2020 with a project to move from Oracle to PostgreSQL. This project was designed to solve the accumulated architectural problems (imperfect storage system for telemetry data, the DBMS itself worked inside a virtual machine), and optimize the use of disk space (make space in the main storage, debug saving archived data, ensure correct backup). Since the customer's system should have worked uninterrupted 24/7, it was necessary to switch from one DBMS to another "seamlessly" without downtime, with simultaneous operation of both to ensure step-by-step translation of subsystems and the ability to control the correctness of the data. And, of course, the work had to be completed as quickly as possible.
In the report we will discuss how we managed to solve this case.
Слайды
Видео
Видео доступно участникам мероприятия, выполнившим вход в личный кабинет
Другие доклады
-
45 мин
Andrey Borodin Яндекс.ОблакоReview of some historical CVEs
I'm not a real security expert. But this will help me to do ELI5 explanation of the funniest historical Postgres CVEs.
-
45 мин
Ivan Frolkov Postgres ProfessionalNew UUID versions
Primary key generation is a known issue quite efficiently though not ideally solved by sequences. There are still problems with distributed generation, real uniqueness and predictability. Initially, UUID was not intended for use as a DBMS key, but its new versions (6, 7 and 8) make it quite convenient to use them as both synthetic and natural keys.
-
22 мин
Anatoly Anfinogenov АО "ВНИИЖТ"Vacuum Therapy: Treatment of Chronic DB Disease
Three years ago we successfully migrated our application from Oracle DBMS to vanilla PostgreSQL. After that we faced with "childhood" diseases of our application on the new DBMS, which were successfully cured, and some "chronic diseases", which took much longer to deal with. One of the most memorable problems was the problem of DB performance degradation. The source of this problems was insufficient vacuuming of our database. The experience of understanding and solving this problem is offered to your attention in the form of practical recommendations to prevent DB tables and indices bloat and setting up PostgreSQL VACUUM/autovacuum parameters.
-
45 мин
Vasiliy Puchkov ОООOdyssey of corporate-scale migration to PostgreSQL
- Scylla Charybdis of project management;
- Sirens of personal goals:
- Circe for IT professionals:
- Polyphemus of information security.
The tricky part of taking the journey in less than ten years.