title

text

Александр Любушкин
Александр Любушкин ФОРС Телеком Технический директор
Андрей Чибук
Андрей Чибук ФОРС Телеком Ведущий эксперт
: декабря
40 мин

Управление сценариями миграции большого объёма данных из Oracle в PostgreSQL

Инструмент Ora2PgCopy представленный на PgConf.Russia-2023 (https://pgconf.ru/talk/1589503) получил новое развитие и дополнен новым средством для инкрементальной миграции данных Ora2PgSync. В докладе рассматриваются следующие стадии процесса переноса данных большой БД: - многопоточная миграция данных (в том числе со сжатием при передаче по медленной сети) - создание индексов и ограничений целостности - инкрементальная миграция изменений данных после переноса основного объёма. Особое внимание уделяется обработке нештатных ситуаций с целью предотвращения полного повторения сценария миграции данных. Представлено несколько способов обеспечения равномерного и полного использования вычислительных ресурсов в течение всего времени отведённого на перенос БД. Обсуждаются проблемы инкрементальной синхронизации БД Oracle и PostgreSQL: - Почему надо анализировать все транзакции в Oracle, а не только зафиксированные - Что происходит, когда в Oracle один оператор delete удаляет 1млн. строк.

Слайды

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

Видео

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

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

  • Илья Сазонов
    Илья Сазонов Всегда Да Руководитель разработки
    Фёдор Сазонов
    Фёдор Сазонов Сбер Руководитель направления
    40 мин

    pg укротитель

    У разработчиков постоянно возникают проблемы при работе с базами данных. Они вызваны тем, что разработчики считают СУБД чёрным ящиком, который "просто работает" и даже не подозревают, что важно и нужно понимать не только стандарт SQL, но и подробности устройства конкретной СУБД.

    Проекты разные, разработчики разные, но вот проблемы как правило одни и те же. Мы хотим продемонстрировать как разработчики пользуются базой данных и рассказать хорошо бы знать об устройстве СУБД, для того, чтобы писать код, который не разваливается как только компания из бодрого стартапа превращается в зрелый бизнес с планомерно растущими продажами и, соответственно, нагрузками.

    Практически в любом успешном проекте можно встретить практически одинаковые проблемы. Они появились потому что бизнес хотел побыстрее получить готовый продукт и это в своё время помогло компании встать на ноги. В небольших проектах эти проблемы совершенно незаметны.

  • Алексей Мигуцкий
    Алексей Мигуцкий Конвертум Руководитель отдела миграции БД
    20 мин

    Автоматическая миграция БД на PostgreSQL: планирование, решения, трудности

    • Автоматическая миграция БД в PostgreSQL
    • Оценка миграционного проекта и построение плана работ
    • Миграция схемы, данных и бизнес логики. Основные сложности, решения и возможности автоматизации.
    • Изменение приложения при миграции БД - сложности и возможности автоматизации

  • Павел Толмачев
    Павел Толмачев Postgres Professional Специалист образовательного отдела
    20 мин

    Историко-статистический взгляд на сообщество PostgreSQL

    В первой части своего доклада расскажу о некоторых моментах из истории PostgreSQL-сообщества (например, про русского Слоника на логотипе).

    А во второй части покажу интересную статистику про сообщество и расскажу (используя информацию о коммитах в GIT и с сайта commitfest.postgresql.org) сколько патчей предлагается на коммитфестах и сколько из них принимается; в какие дни недели и в какое время происходит фиксация патчей; кто из авторов патчей являются самыми активными; и наглядно посмотрим на некоторые из интересных тенденций развития сообщества.

  • Павел Конотопов
    Павел Конотопов Postgres Professional руководитель кластерной группы
    40 мин

    Слон и Моська. Проблема фенсинга в кластерах PostgreSQL

    Довольно часто в кластерных конфигурациях PostgreSQL можно встретить настройку, отвечающую за ввод отказавшего ведущего сервера обратно в кластер в качестве реплики. Утилита pg_rewind выполнит синхронизацию данных между двумя серверами. Она копирует изменения из WAL-файлов основного сервера, которые не применялись на отстающем сервере (бывшем мастере). Однако без механизма fencing существует риск потери данных, если оба сервера (старый мастер и новый мастер) активны одновременно и оба принимают изменения данных. Эта ситуация называется split-brain, возникновение ее катастрофично для целостности данных. Поговорим о том, как минимизировать риски потери данных, какие есть варианты fencing-а, какие практики стоит использовать и в каких ситуациях.