В условиях глобальной цифровой трансформации и ужесточения санкционного давления многие компании сталкиваются с необходимостью перехода с зарубежных коммерческих СУБД, таких как Oracle, на открытые и независимые аналоги.
PostgreSQL — одна из самых зрелых и функциональных альтернатив, обладающая рядом преимуществ для бизнеса и IT-инфраструктуры.
Долгие годы Oracle Database оставалась стандартом для крупных корпораций и государственных структур. Её мощный функционал и надежность не вызывали сомнений, но за это приходилось платить высокую цену — не только в денежном эквиваленте, но и в зависимости от вендора.
PostgreSQL, как свободная и расширяемая СУБД, дала компаниям то, чего они были лишены с Oracle — полный контроль над своей базой данных. Теперь организации не просто мигрируют на PostgreSQL, а активно дорабатывают продукт под свои потребности, создавая собственные форки с уникальными функциями.
Однако замена Oracle на PostgreSQL — сложный процесс, требующий совместной работы разработчиков, администраторов БД и архитекторов. Успешная миграция включает в себя как перенос данных, так и адаптацию SQL кода, настройку инфраструктуры и качественную настройку экземпляров.
Роль разработчика может содержать в себе множество задач, но основная — конвертация PL/SQL в PL/pgSQL, которая включает выявление несовместимых конструкций, например, замену CONNECT BY в Oracle на рекурсивные CTE в PostgreSQL, а также замену Oracle-специфичных функций, например, NVL() → COALESCE().
Роль администратора БД включает аудит текущей инфраструктуры Oracle. Проводится оценка объема данных, количества экземпляров, используемого функционала (партиционирование, RAC, Data Guard), анализ зависимостей (триггеры, процедуры, внешние интеграции).
После, наступает этап выбора стратегии миграции — полный перенос или постепенный (частичный) переход, определение инструментов (ora2pg, ручная адаптация, другие утилиты). Финальный этап — проектирование новой инфраструктуры PostgreSQL.
В последнее время появилось много инструментов для автоматической миграции Oracle в PostgreSQL. Вместе с тем, даже если представить, что такие инструменты на 100% заменяют разработчика, то решить вопрос подготовки нового экземпляра PostgreSQL, пока не возможно.
Правильная подготовка нового экземпляра PostgreSQL — важная часть успеха миграции, и она включает в себя:
Проведенный аудит имеющейся системы может потребовать кластеризации нового экземпляра, а это требует и выбора инструмента (чаще всего – patroni, который порождает этап выбора DCS) и установку всех необходимы компонентов.
Также важно понимать, правильно ли подобраны ресурсы, верно ли размечены диски, ведь в такой инсталляции на одном сервере может быть несколько сервисов.
Сюда также можно отнести организацию единой точки входа, от использования функционала драйвера JDBC до изменения DNS имени точки во время переключения ролей в автоматическом режиме.
Первым шагом является настройка параметров PostgreSQL. Чаще всего приходят к изменению базовых параметров, таких как shared_buffers или work_mem. Но зачастую этого недостаточно, и требуется тонкая настройка с самых первых минут работы кластера.
Также, популярный метод выставления параметров – использование онлайн конфигураторов, например, pgconfigurator.cybertec.at для автоматической генерации оптимальных настроек.
Наш подход сочетает рекомендации официальной документации PostgreSQL и практический опыт, что позволяет минимизировать проблемы на старте проекта.
Самые необходимые процедуры – это резервное копирование и мониторинг. Важно иметь представление обо всех возможных способах включения данных процедур.
Резервное копирование можно выполнить множеством способов, которые зависят от разных факторов: версия PostgreSQL, издатель PostgreSQL (например PostgresPRO), наличие облачных ресурсов, и т.д.
В нашем арсенале есть готовые решения практически для любой ситуации. Если ваш бизнес по каким-то причинам не предусматривает использование облачных технологий – то мы готовы предложить построение Minio-хранилища, которое будет принимать резервные копии WAL-G. А если нет возможности использовать внешние утилиты, то мы сможем сделать то же самое штатными средствами.
Мониторинг также важен, и вызывает много вопросов: какие метрики и чем их собирать, какие ставить триггеры и какие выдать им условия?
В классическом варианте можно использовать стандартные шаблоны Zabbix, но однозначно можно утверждать, что триггеры, поставляемые в них, не покрывают все возможные «уязвимости». Например, отслеживание переполнения директории с WAL-журналами или блокировками.
Важно уметь отлаживать стандартный шаблон (будь то Zabbix или telegraf), добавляя больше метрик или создавать новые, оригинальные.
Последним пунктом при развертывании новой системы обозначим обслуживание самого сервера. Зачастую инсталляция PostgreSQL сопровождается установкой etcd, чтобы организовать кластер patroni. Поверх этого, добавляется PgBouncer в качестве пуллера соединений и другие утилиты. Каждый сервис (или утилита) в обязательном порядке должен отслеживать свои действия, иметь свой журнал, и расписание его ротации.
Практически на любой сервис есть готовое решение в сервисе logrotate. Но, согласитесь, приятно видеть, когда каждый архивный журнал имеет красивое имя с датой, максимально сжат и хранится достаточно долго, что необходимо для качественного исследования аварийных ситуаций.
Как итог, отметим, что нет единого верного решения задачи разработчика и/или администратора БД. Автоматизации не всегда предоставляют желаемый результат. Следовательно, необходимо иметь возможность привлекать опытных IT-специалистов, которые помогут найти правильное решение для текущей ситуации.
Наш менеджер свяжется в течение 2х часов
