«А кто отвечает за эту базу данных?»
Народ из команды администраторов баз данных пожал плечами, и кто-то спросил: «А сервер Oracle или SQL?»
«По-моему, это My SQL», — сказал руководитель отдела разработки.
За 20 лет работы администратором баз данных зачастую именно в таких ситуациях передо мной возникала необходимость изучения новых RDBMS (система управления реляционными базами данных). В результате я не понаслышке знаю, с какими сложностями вы можете столкнуться, когда приходится с головой погружаться в омут другой системы.
Новые базы данных добавляются в производственную среду самыми разными способами. Например, приобретается новый программный продукт, и для его установки требуется (или создается) новая база данных. Разработчик создает его прототип для того или иного бизнес-отдела. Когда начинается его использование, он быстро превращается в важную систему, и вместе с этим на администраторов сваливается новая база данных, которую нужно обслуживать и отлаживать в случае сбоя. А иногда компания решает, что им необходимо перейти на какую-нибудь популярную стандартную СУБД и отказаться от других. Данное решение может потребовать повышения квалификации (изучения новой системы) целой команды администраторов.
Также в один прекрасный день вы можете услышать: «Поздравляем! Теперь вы отвечаете за эту базу данных. Я знаю, что вы являетесь администратором баз данных Oracle, но PostgreSQL — это почти то же самое, поэтому вы с легкостью справитесь и с ней».
Да, они обе представляют из себя системы управления реляционными базами данных (RDBMS), и для взаимодействия с ними вы используете (в основном) старый добрый SQL. Но некоторые отличия, в которых вам нужно разбираться, все-таки имеются.
Начнем мы пожалуй с основ архитектуры: одна база данных на одной машине. Я расскажу о некоторых сходствах и различиях между Oracle и PostgreSQL, чтобы помочь вам быстро освоиться. В этой статье я также предлагаю обсудить архитектуру высокого уровня и некоторые ключевые аспекты, проверив которые, можно убедиться, что ваша новая база данных не содержит каких-либо явных проблем.
Основные функции
В Oracle, служба состоит из нескольких фоновых процессов, сегментов памяти (называемых инстансами - instance) и файлов, содержащих конфигурации, транзакционные (или архивные) логи, данные и индексную информацию.
В PostgreSQL есть один процесс, называемый postgres, который управляет файлом базы данных, принимает подключения от клиентских приложений и выполняет действия от имени этих клиентов. В PostgreSQL также есть файлы данных и файлы архивных логов (называемые WAL-файлами).
В таблице ниже приведено сравнение некоторых функций этих двух систем управления базами данных:
Oracle | PostgreSQL | Function |
Tablespace | Tablespace | Часто используется в Oracle для балансировки нагрузки. Редко используется в PostgreSQL |
User | Role | CREATE USER в PostgreSQL создает роль с правами входа в систему. |
Role | Role | В Oracle только набор привилегий. В PostgreSQL см. предыдущую строку. |
PL/SQL | PL/pgSQL | Процедурный язык |
Export | pg_dump/pg_dumpall | Извлечение копии данных из базы данных |
Import | pg_restore | Восстановление данных в базе данных |
License model | Open source model | Лицензирование |
Oracle Enterprise Manager (OEM) | pgAdmin | Графическая утилита для администрирования |
Oracle | An array of third parties | Провайдер тех. поддержки |
Как только вы разберетесь с основами PostgreSQL, следующее, что вам нужно будет освоить — это выполнение технического аудита (health check). Большинство администраторов баз данных сами вырабатывают ту или иную форму этой проверки. Обычно все начинается с изучения того, что легче предотвратить, чем потом исправлять. Если вы новичок в Postgres, вот краткое руководство, которое покажет вам на что следует сделать акцент:
Резервное копирование
Существует несколько основных подходов к резервному копированию базы данных PostgreSQL. У каждого из них есть сильные и слабые стороны, поэтому я кратко расскажу о них здесь и предоставлю ссылки, по которым вы можете получить дополнительную информацию, если у вас возникнет такая потребность.
Дамп SQL
Утилита pg_dump создаст файл команд SQL, чтобы иметь возможность воссоздать базу данных в том же состоянии, в котором она была запущена. Подробнее об этом можно прочитать в документации pg_dump.
Резервное копирование файловой системы
Если вы можете остановить свою базу данных, вы можете сделать копию всех файлов. Это часто нецелесообразно для систем с высокими требованиями к доступности, но может быть полезным способом гарантировать, что у вас будет заведомо исправный бэкап. При внесении значительных изменений в базу данных это часто является разумной дополнительной мерой для восстановления, в случае, если что-то пойдет не так. Дополнительную информацию о резервном копировании файловой системы в PostgreSQL можно найти в разделе резервного копирования файловой системы документации Crunchy Data.
Непрерывное архивирование
PostgreSQL полагается на логи для обеспечения согласованности при сбоях и для возможности восстановления согласованного состояния базы данных в случае сбоя системы. Эти логи называются логами упреждающей записи или WAL (write-ahead log). PostgreSQL может использовать WAL-файлы для восстановления любых изменений, внесенных в данные вашей базы данных. Подробнее о непрерывном архивировании можно прочесть в документации Crunchy.
pgBackRest
pgBackRest — это комплексное решение для резервного копирования и восстановления даже самых больших баз данных PostgreSQL простым и удобным в использовании способом. С помощью pgBackRest вы можете настроить процесс резервного копирования, включив в него параллелизм для ускорения резервного копирования и восстановления, контрольную верификацию для проверки целостности, а также многие другие функции. (В следующей статье мы подробнее рассмотрим параметры резервного копирования в PostgreSQL в сравнении с Oracle. Следите за выходом новых статей.)
Шаги для проверки бэкапов в Postgres:
Шаг 1: Убедитесь, что вы делаете бэкапы. Если у вас вообще нет бэкапов, эта статья — станет хорошей отправной точкой в работе с pgBackRest.
Шаг 2: Задокументируйте весь процесс выполнения восстановления. Если отказ произошел посреди ночи, и вы не доверяете своей интуиции, лучше всего, чтобы у вас был очень четкий пошаговый план действий. Еще лучше, если вы заранее автоматизируете процесс восстановления.
И последний шаг: Регулярно тестируйте весь процесс. Если вы будете выполнять тесты, используя документацию из предыдущего шага (а вы должны это делать), вы сможете продолжать улучшать задокументированный процесс, когда будете сталкиваться с неожиданными препятствиями на вашем пути (и будьте уверены, без них не обойдется). Хлопоты с налаживанием тестов конечно доставляют некоторое неудобство, но если вы проводите тестирование, то это куда лучше, чем обнаружить серьезные проблемы, когда вы пытаетесь решить проблему потери данных, что потенциально может очень серьезно отразиться на бизнесе (и вашей карьере). Crunchy Data рекомендует выполнять тесты на восстановление не реже одного раза в квартал. Для сайтов с высокими требованиями к доступности лучше выполнять их еще чаще.
Теперь пришло время убедиться, что стратегия резервного копирования соответствует ожиданиям бизнеса. Создание бэкапа раз в неделю вполне может удовлетворить потребность в резервным копированием базы данных, но необходимо учитывать множество других факторов.
Безопасность
Безопасность должна занимать первое место в списке приоритетов у всех, кто работает в сфере IT, но особенно это касается администраторов баз данных из-за ценности содержащихся данных и негативных последствий потери контроля над этой информацией для всего бизнеса.
Мажорная версия Postgres
Прежде всего, проверьте, какая у вас версия. Вам не обязательно использовать последнюю мажорную версию, но стоит следить за обновлениями последней минорной версии - так вы будете защищены от большинства CVE, которые могут подвергнуть вас риску. Если ваша версия устарела или вот-вот таковой станет, то следует запланировать обновление.
Вы можете проверить версию PostgreSQL двумя способами:
В командной строке узла базы данных, как пользователь, имеющий доступ к запуску PostgreSQL, выполните:
postgres --versionВойдя в базу данных, выполните следующую команду:
SELECT version();
Доступ пользователей
Контролируйте пользователей, у которых есть доступ, и проверяйте, все ли они валидны и имеют надлежащие средства контроля доступа (например, пароли).
Начать лучше всего с простой команды postgres-# \du и проверки того, что все перечисленные пользователи актуальны. Часто когда сотрудник покидает компанию, его учетные записи не удаляются полностью из всех систем, которыми он пользовался.
Взглянув на поле “Member of”, вы увидите некоторых пользователей, которые могут быть в группах, которые больше к ним не относятся. Например, сотрудник, который был в отделе “Sales”, но перешел в “Marketing”, может находится в двух отделах “Sales” и “Marketing”, и в этом случае его следует удалить из отдела “Sales”.
Инструменты
Убедитесь, что вы используете безопасную версию инструментов, где это возможно, и отключили небезопасную версию (например, scp, ssh и т. д.).
Передача файлов уже давно не осуществляется с помощью протокола передачи файлов (FTP), но в некоторых случаях он все еще может быть подходящим инструментом для работы, поскольку он быстрее, чем альтернативы, такие как SFTP. Однако протоколу FTP не хватает безопасности, и, используя SFTP, вы получаете дополнительное преимущество в виде зашифрованного соединения.
Те же соображения относятся и к другим утилитам, которые используются в среде базы данных, поэтому убедитесь, что вы выполнили все требования безопасности для вашей организации. Они будут варьироваться в зависимости от потребностей бизнеса, но лучшие практики обычно включают использование зашифрованных параметров вместо незашифрованных.
Бенчмарки безопасности
Существует несколько подходов к этому исследованию. Один из них заключается в использовании бенчмарка, подобного тому, что разработан Center for Internet Security. Если безопасность имеет первостепенное значение для вашей компании, вы можете уделить внимание дополнительной защите, доступной в секьюрной реализации PostgreSQL. Удачным решением может стать — Crunchy Hardened, который может обеспечить более высокий уровень защиты, который удовлетворит потребности большинства компаний.
Выдыхайте
После того, как вы наладите резервное копирование и перейдете на безопасную версию Postgres, убедитесь, что остальная часть системы соответствует требованиям вашей организации. На учебном портале Crunchy Data есть несколько курсов по администрированию PostgresSQL для начинающих, где можно получить больше информации по этой теме.
Перевод материала подготовлен для будущих студентов курса «PostgreSQL для администраторов баз данных и разработчиков».