Когда RDS выходит за рамки вашего бюджета, запускайте Postgres на EC2

Мотивация

Самая большая причина для запуска вашей базы данных из EC2 - это экономия средств. На момент написания этой статьи самое дешевое / минимальное развертывание RDS стоило около 30,88 долларов США в месяц. Напротив, мы можем запустить экземпляр t2.micro EC2 с 8 ГБ хранилища примерно за 6 долларов США в месяц. Эта стоимость может быть дополнительно снижена, если вы выберете зарезервированный биллинг.

Предостережения / Когда следует выбрать RDS

Как правило, если позволяет бюджет, всегда выбирайте RDS. Он обеспечивает репликацию через резервный экземпляр в другой зоне доступности и обрабатывает автоматическое переключение при отказе. Это желательно по двум причинам:

  1. Amazon гарантирует 99,99999% времени безотказной работы для регионов, а не для зон доступности. Таким образом, наличие резервной реплики в другой зоне гарантирует, что даже если в основной зоне, в которой размещена ваша основная база данных, произойдет сбой, ваше приложение сможет вернуться к резервной реплике в другой (и предположительно незатронутой) зоне.
  2. Ваше приложение не должно уметь обнаруживать сбой базы данных и обрабатывать отказоустойчивость. Amazon обрабатывает это автоматически. Они будут указывать URL-адрес хоста вашей базы данных на резервную базу данных, если / когда ваша основная база данных выйдет из строя. После того, как кризис будет разрешен, они автоматически догонят восстановленную основную базу данных и продвинут ее.

Теперь, когда у нас это есть, давайте приступим. Если вы предпочитаете использовать это руководство в видеоформате:

Настроить инфраструктуру

Перейдите в консоль AWS EC2 и выделите сервер Linux для размещения нашей БД. Я выберу сервер Ubuntu 20.04, потому что это то, к чему я привык больше всего.

Остальная часть конфигурации не так важна, но в разделе тегов мы создадим тег для идентификации этого экземпляра БД. Это будет использовано при настройке резервного копирования позже.

Затем мы настроим группу безопасности, чтобы разрешить SSH и доступ к базе данных. Я открою порт 5432 Postgres по умолчанию в ожидании запуска службы Postgres там. Для дополнительной безопасности я ограничиваю доступ к своему общедоступному IP-адресу. Для производственного использования вы должны разрешать соединения с базой данных только из группы безопасности вашего сервера приложений.

После запуска экземпляра обратите внимание на общедоступный IP-адрес и общедоступное DNS-имя. Мы будем использовать общедоступный IP-адрес для SSH на сервере для настройки Postgres. После этого мы можем использовать DNS-имя для подключения к серверу Postgres.

Это хорошее время, чтобы сделать паузу и добавить вновь созданный сервер в вашу конфигурацию SSH, чтобы вы могли подключиться более эргономичным способом.

Настроить Postgres

Мы будем использовать следующие шаги в качестве руководства для настройки нашего сервера Postgres.

Давайте разберем команды, описанные выше. Первые две строки обновят пакеты в Ubuntu и установят последнюю версию Postgres.

sudo apt-get update -y && sudo apt-get upgrade -y
sudo apt install postgresql -y

Затем мы войдем в систему как пользователь Postgres по умолчанию (образно названный postgres) и создадим роли пользователей, которые мы будем использовать. Я просто назову своего пользователя ubuntu и разрешаю ему входить в систему и создавать базы данных.

sudo su postgres
psql -U postgres -c "CREATE ROLE ubuntu;"
psql -U postgres -c "ALTER ROLE  ubuntu  WITH LOGIN;"
psql -U postgres -c "ALTER USER  ubuntu  CREATEDB;"
psql -U postgres -c "ALTER USER  ubuntu  WITH PASSWORD 'ubuntu';"

Выйдите из учетной записи postgres и вернитесь к своему пользователю по умолчанию, введя следующее:

exit

Найдите postgresql.conf файл (обычно он находится в /etc/postgresql/12/main/postgresql.conf). Если вы не уверены, вы можете использовать удобную команду Bash, чтобы найти его, введя:

sudo find / -name "postgresql.conf"

Откройте файл с помощью вашего любимого текстового редактора (да, у меня так получилось, что это Nano #sorryNotSorry). Мы найдем запись конфигурации listen_addresses и изменим ее со значения по умолчанию на ‘*’. Это позволит серверу Postgres прослушивать DNS-имя экземпляра EC2.

После этого найдите pg_hba.conf и откройте его.

sudo nano /etc/postgresql/12/main/pg_hba.conf

Мы разрешим аутентификацию из удаленных подключений, добавив следующие строки в конец файла. Это позволит подключаться с любого IP-адреса. Обратите внимание, что на производстве было бы неплохо ограничить подключения только теми, которые вам нужны (хорошо настроенная группа безопасности EC2 должна быть достаточной, но для спокойствия вы должны добавить IP-адрес своего сервера приложений вместо 0.0. .0.0 / 0)

host    all             all              0.0.0.0/0                      md5
host    all             all              ::/0                            md5

Чтобы новая конфигурация вступила в силу, мы перезапустим демон Postgres, запустив:

sudo systemctl restart postgresql

Давайте сделаем тест-драйв

Чтобы опробовать нашу новую блестящую базу данных Postgres, мы будем использовать PgAdmin. Скачайте и установите отсюда. После установки запустите его и добавьте сервер.

Введите DNS-имя из консоли EC2 и учетные данные, которые мы настроили ранее.

Если сервер добавлен - отлично! Если вы столкнулись с ошибкой тайм-аута, обязательно дважды проверьте свои группы безопасности в EC2 и конфигурацию Postgres, которую мы рассмотрели ранее.

Я собираюсь создать тестовую базу данных и таблицу пользователей и вставить фиктивные данные для тестирования.

Настроить автоматическое резервное копирование

Теперь, когда наша база данных настроена и работает, давайте обеспечим регулярное резервное копирование экземпляра БД. Цель здесь - создать резервную копию всего экземпляра (вместе с данными и конфигурацией), чтобы в случае сбоя мы просто запустили новый экземпляр EC2 из образа резервной копии (AMI).

Для этого перейдите в консоль EC2, выберите Data Lifecycle Manager и нажмите Create Lifecycle Policy.

Помните тег, который мы связали с этим сервером EC2? Мы скажем DLM создать резервную копию целей, помеченных тегом Type: Database.

Далее мы определим политику и расписание резервного копирования. Я обычно выбираю ежедневное резервное копирование, и у меня истекает срок хранения резервных копий моментальных снимков после пятидневного периода хранения.

Стоит отметить, что эта стратегия резервного копирования вызовет некоторое время простоя из-за того, как Amazon обрабатывает создание образов. Во время этого окна резервного копирования ваш сервер базы данных отключится на несколько секунд.

Если такое время простоя неприемлемо, вы можете использовать pg_dump вместе со сценарием Bash и AWS SDK, чтобы склеить воедино подпрограмму, которая периодически выгружает базу данных и выгружает ее в S3. Этот сценарий может быть запущен в Unix-подобных системах с помощью cron. Хотя это выходит за рамки данной статьи, суть должна помочь вам начать:

На этом пока все. Наслаждайтесь работой администратора БД и удачи!

Шашике - инженер-программист из Торонто и основатель Restarone Inc.. Когда он не занимается разработкой программного обеспечения, он создает контент на Medium и YouTube, чтобы помочь людям перейти в технологический процесс.