Как запланировать резервное копирование внешнего PostgreSQL с помощью Google Cloud Serverless?
У нас есть кластер PostgreSQL, управляемый DigitalOcean, и мы хотим выполнять резервное копирование в облачное хранилище Google по расписанию. Я планирую создать облачную функцию, которая будет работать по расписанию.
Поскольку наши базы данных не хранятся в Google Cloud, я не могу использовать это руководство, опубликованное Google. А поскольку для доступности pg_dump необходимо установить в системе, в Cloud Functions такой возможности нет.
Какие у меня есть варианты? Можно ли использовать что-то вроде psycopg2 в Python или pg в Node.js?
Спасибо за ваш комментарий, но я хотел бы избежать оплаты стороннего решения.
Можете ли вы рассказать, где работает ваш PostgreSQL?
Он работает на DigitalOcean
Не могли бы вы взглянуть на document1 и document2 ? Документы могут помочь вам решить вашу проблему. Кроме того, вы также можете обратиться к этой проблеме stackoverflow с аналогичным контекстом.
Вы можете использовать pg_dump из Docker-контейнера, запущенного в запланированном задании Cloud Run . Хотя pg_dump снимки являются автономными, простыми и удобными в использовании, вместо этого вы можете рассмотреть возможность Восстановление на определенный момент времени - они будут делать один первоначальный снимок, а затем собирать только дельту, поэтому вам не придется для резервного копирования одних и тех же данных снова и снова. Это также позволяет вам восстановить любое состояние между резервными копиями.
Спасибо. Cloud Run может быть лучшим вариантом. У нас также есть PITR (включенный в управляемую базу данных DigitalOcean), но только за последние 7 дней. Это будет дополнением к тому, когда дерьмо действительно поразит фаната.
@HannesHultergård Помимо удобства, если вам просто удобнее делать снимки pg_dump, в этом нет никакой пользы по сравнению с настройкой собственного PITR с дельтами, поступающими в корзину GCP. Я не уверен, почему именно у них есть ограничение в 7 дней, но как только вы настроите свой собственный, вы не только сможете восстановить его в любую точку, но кроме базовой резервной копии, это также будет в целом быстрее и легче, чем полноразмерные дампы. Он так же безопасен, только немного умнее и гибче.
Хорошо, я проверю это вместо этого. Проблема может заключаться в том, что у меня нет полного доступа к серверу, на котором находится кластер базы данных. Так что, возможно, я не смогу сделать ничего, кроме логического резервного копирования с помощью pg_dump. Но это может быть вопрос к поддержке DigitalOcean.
Служба поддержки DigitalOcean только что подтвердила, что pg_basebackup нельзя использовать и что они не поддерживают физическое резервное копирование. Также, к сожалению, права на репликацию не могут быть предоставлены пользователю.
Ответы 1
поскольку для доступности
pg_dumpнеобходимо установить в системе, в Cloud Functions это также невозможно. Какие у меня есть варианты?
- Cloud Run. Хотя облачные функции должны абстрагировать базовую платформу, Cloud Run позволяет вам определить как функцию, так и платформу, на которой она будет активироваться. Обе службы представляют собой то, что Google рекламирует как Cloud Serverless.
- Cloud Compute , крошечная виртуальная машина с простым скриптом по расписанию пробуждается , запускает ее, а затем снова засыпает. Вы можете сохранить его как собственный образ и настроить таким образом несколько небольших рабочих процессов резервного копирования.
Последний будет своего рода имитировать то, что Cloud Run должен обрабатывать за вас, но он может быть более интуитивным (приблизительно так вы бы делали это дома или локально). Это также может быть немного более рентабельным, поскольку более «облачные» решения, такие как Cloud Run, обычно стоят дороже — аналогично тому, как управляемая база данных обычно стоит немного дороже, чем виртуальная машина, арендованная у того же провайдера, на которой размещается точно такая же база данных, с теми же ресурсами (за исключением секретного соуса провайдера, которым они оправдывают премию).
Тем не менее, работа, которая включает в себя простое пробуждение и несколько минут прослушивания pg_dump|gsutil cp, должна стоить вам практически ничего, независимо от того, какой вариант вы выберете. Возможно, вы захотите изучить многопоточную pg_dump -j , чтобы ускорить работу за счет дополнительного использования процессора, и gsutil -m для многопоточной загрузки.
Спасибо за ответ. В итоге я запустил задание резервного копирования на сервере Linux, который у нас уже был запущен. Однако в будущем я могу переключиться на Cloud Run, чтобы повысить надежность. Учитывая то, что я задал в вопросе, я отмечу это как правильный ответ.
Пожалуйста, обратитесь к этому документу . если это не решит вашу проблему, не могли бы вы сказать мне, где работает ваш postgre?