Облачный SQL не очень хорош

Я наконец-то закончил перенос нашей базы данных PostgreSQL версии 9.6 из Google Cloud SQL в 14, работающую на виртуальной машине под нашим управлением. Возможно, это не окончательный дом для нее, но, по крайней мере, она освободилась от тирании управляемой базы данных.

У меня меньше опыта работы с AWS и нет опыта работы с другими управляемыми решениями для баз данных. Однако, основываясь на своем опыте работы с Cloud SQL, я думаю, что самостоятельное управление такой базой данных, как PostgreSQL, станет для меня стандартом, а управляемые базы данных будут скорее исключением, чем правилом.

У меня есть несколько критических замечаний, которые относятся именно к GCP (Google Cloud Platform), и несколько, которые применимы к любому управляемому решению. Без лишних слов, вот те вещи, которые мне не понравились в управляемых решениях, и в Google Cloud SQL в частности.

То, что не нравится

Случайное удаление

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

Нет проблем, подумаете вы. Управляемое решение для баз данных обеспечивает резервное копирование, так что просто восстановите из резервных копий – вы ведь включили резервное копирование, верно?

Как выяснилось, Cloud SQL удаляет резервные копии вместе с экземпляром. Это безумное поведение, и предупреждение жирным красным шрифтом в документации не соответствует действительности:

Предупреждение: Все данные на экземпляре, включая резервные копии, безвозвратно теряются при удалении этого экземпляра. Чтобы сохранить данные, экспортируйте их в Cloud Storage перед удалением. Роль Cloud SQL Admin включает разрешение на удаление экземпляра. Чтобы предотвратить случайное удаление, предоставляйте эту роль только по мере необходимости.

А что если ваша база данных действительно случайно удалена? Вы будете бежать со всех ног и надеяться, что сможете ее найти.

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

Это было бы не так плохо, если бы вы могли лучше управлять резервным копированием…

Возможности резервного копирования

Возможности резервного копирования ограничены. В наши дни pgbackrest является основным решением для резервного копирования PostgreSQL, и пока что я очень впечатлен его использованием. Он обеспечивает полное, дифференциальное и инкрементное резервное копирование, а также архивирование сегментов WAL для восстановления в нужный момент времени. Он позволяет очень гибко выбирать расписание и место назначения резервного копирования, продолжительность хранения резервных копий, количество полных резервных копий. Например, вы можете создавать резервные копии на локальный диск, а другие резервные копии – во внешнее S3-совместимое хранилище, каждое из которых имеет свои настройки и расписание (например, по расписанию cron).

В Cloud SQL вы можете включить восстановление по времени, запустить резервное копирование по требованию и запланировать его с ограниченными параметрами. Но если вы когда-нибудь удалите свой экземпляр, все это исчезнет. Ваши запланированные резервные копии и параметры восстановления по времени, похоже, связаны с этим экземпляром, который обещают стереть, если вы его удалите.

Если вы хотите иметь внешние резервные копии, то, как я описал выше, вам придется каждый раз создавать полный дамп.

Хотите выполнять резервное копирование во внешнее место, например, на собственный сервер или в резервные копии? Тогда вы возвращаетесь к опции экспорта, где каждый раз создается полный дамп базы данных. Это не очень хорошо, но это лучше, чем держать все яйца в корзине, которая может быть удалена в один момент.

Могут быть варианты с репликацией в базу данных под вашим контролем, чтобы вы могли выполнять более качественное резервное копирование на этой копии. У меня были проблемы, которые я частично описываю ниже. Возможно, с более новыми версиями Cloud SQL дело обстоит лучше, но я не буду тестировать – логическая репликация не была встроена в PostgreSQL до версии 10, поэтому я полагался на поддержку pglogical от Google.

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

Обновления

Мы застряли на 9.6 на некоторое время, наблюдая за тем, как проходят основные релизы. Наша база данных не была особенно большой, может быть, 200 ГБ в пике, что ни в коем случае не является большой базой данных по сравнению с масштабами, в которых работают некоторые компании. Однако даже при таком размере все еще проблематично проводить обновления.

Проблема в том, что управляемая база данных не предлагает никакого способа обновления. Официально рекомендуемый метод:

Чтобы перейти на более позднюю версию, воспользуйтесь службой миграции базы данных или экспортируйте, а затем импортируйте базу данных в новый экземпляр Cloud SQL.

Служба миграции базы данных сработала с некоторыми усилиями, когда я попытался ее использовать. Она использовала логическую, а не физическую репликацию, позволяя нам иметь реплику на более новой версии – в частности, на расширении pglogical, поскольку мы были на 9.6. Реплика была настроена и передавала изменения, работала на последней версии и работала достаточно хорошо. Однако я не мог перейти на новую версию немедленно, а ждать несколько дней казалось глупым решением. Синхронизация перестала работать, и я не смог найти никаких сообщений об ошибках или информации, чтобы отладить причину. Повторное создание миграции с нуля не помогло.

Обращение в службу поддержки не помогло. При попытке приобрести поддержку кнопка поддержки не срабатывала. Затем я попытался связаться со службой поддержки, чтобы получить помощь в приобретении поддержки, после чего я был перенаправлен обратно на неработающую страницу.

В результате мы вернулись к варианту 2: экспорт и импорт базы данных. Проблема в том, что этот вариант требует значительного времени простоя. Время на экспорт базы данных, а затем на импорт заняло несколько часов.

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

Расширения

Теперь перейдем к другим причинам, по которым я в целом склоняюсь в сторону управляемых баз данных. Первая (но не самая важная) в этом списке – расширения. В рамках моих недавних усилий по освоению своего ремесла, включая базы данных, я заинтересовался возможностями расширения базы данных. Это включает в себя использование расширений сторонних производителей, а также разработку собственных. Пока это теоретическая критика, поскольку у меня еще не было потребности в этом, но я определенно могу предвидеть такую возможность.

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

Настройки тюнинга

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

Более новые версии

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

Доступ суперпользователя

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

Недостатки самостоятельного управления

Конечно, у самоуправляемой базы данных есть и отрицательные стороны. Если вам нужна новая база данных, то создать ее с помощью управляемого решения очень быстро и просто. Управляя ею самостоятельно, вам придется делать такие вещи, как:

  • настроить виртуальную машину и установить программное обеспечение
  • запустить обновления ОС
  • настройка и тестирование резервного копирования
  • Настроить репликацию самостоятельно
  • Создание клонов для тестирования может быть более сложным.
  • Настройки PostgreSQL из коробки не очень хороши, и вам придется настраивать их самостоятельно.

У самостоятельного управления есть и отрицательные стороны, но для проектов определенной значимости, я считаю, преимущества стоят затраченных усилий. Если не по какой-либо другой причине, то при рассмотрении Cloud SQL трудно отказаться от лучшего контроля над резервными копиями и более простого обновления.

Оцените статью
Procodings.ru
Добавить комментарий