Как стать автором
Обновить
VK
Технологии, которые объединяют

База данных как сервис: когда, зачем и как использовать DBaaS в облаке

Время на прочтение 16 мин
Количество просмотров 8.2K


Database by Julian-Faylona


Многие облачные платформы предлагают базы данных как сервис (Database as a Service, DBaaS). Базу можно создать в облаке в несколько кликов, не тратя время на настройку и поддержку. Но не всем приложениям облачные базы данных подходят.


Мы расскажем, как на старте проекта не ошибиться с выбором облачной СУБД. Эта статья — вольная переработка нашего вебинара (видео тут).


Мы разберем, когда стоит и не стоит использовать DBaaS, какие особенности нужно учесть при работе с ними и как выбрать подходящую базу данных с учетом особенностей ИТ-инфраструктуры, объема и специфики задач. В конце посмотрим, как устроено создание базы данных в облаке и какие операции с ней доступны, на примере DBaaS Mail.ru Cloud Solutions.


Кому подходит и не подходит DBaaS


Как показывает опыт, наиболее часто к DBaaS обращаются в следующих случаях:


  1. Требуются мощности для Dev- и Test-сред с оплатой по принципу Pay-as-you-go. Нередко бывает, что Production-среда в компании развернута на On-premise-серверах, но инженерам и разработчикам для тестирования приложений требуются дополнительные мощности под регулярно создаваемые и удаляемые БД. Это удобно делать в облаке, где ресурсы предоставляются по запросу и можно гибко управлять их потреблением, настраивая лимиты для каждого проекта или разработчика.


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


  2. Нужно быстро развернуть решение, аттестованное по 152-ФЗ. Если компания работает с персональными данными и необходимо соответствовать требованиям 152-ФЗ, использование DBaaS в аттестованном облаке может оказаться наиболее быстрым и простым решением, так как в этом случае не приходится тратить время и ресурсы на самостоятельное развертывание и аттестацию защищенного контура.


    При этом зачастую компании переносят в облако только часть данных, оставляя наиболее «чувствительные» на своей стороне. Это позволяет значительно сэкономить на используемых мощностях, особенно при обработке больших объемов данных.


  3. Требуется недорогое хранилище для резервных копий. В облаке MCS для хранения бэкапов баз данных можно использовать отказоустойчивое объектное хранилище S3. Хранение массивных бэкапов с редким доступом в таком хранилище обойдется намного дешевле, чем на локальных серверах. S3 позволяет хранить неограниченный объем данных без каких-либо специальных действий со стороны пользователя для увеличения объема хранения, а оплачивается только фактически использованный объем хранения.


    Кроме этого, сами бэкапы автоматизированы и расписание их создания легко настраивается. При необходимости бэкапы из S3 всегда можно выгрузить в On-premise-хранилище.


  4. В команде не хватает опыта самостоятельной настройки и администрирования СУБД. Установка и настройка любой СУБД требует времени, а создание отказоустойчивой системы — высокого уровня квалификации команды. Используя DBaaS, можно запустить любую БД всего за несколько минут с помощью API или UI, а также получить «из коробки» весь необходимый функционал: автомасштабирование БД по мере роста нагрузок, резервное копирование и геораспределенные реплики для большей надежности. Кроме этого, провайдеры предоставляют определенный SLA на работу своих сервисов, часто с финансовыми гарантиями.



Однако далеко не всегда DBaaS является лучшим решением. Важно учитывать, что облачные провайдеры не предоставляют Root-доступ к настройкам серверов БД: это своеобразная плата за то, что провайдер гарантирует SLA, минимизируя ошибки и гарантируя доступность сервисов. Поэтому в тех случаях, когда требуется полный контроль над системой, включая ее администрирование, On-premise-вариант выглядит предпочтительнее — разумеется, при достаточном уровне экспертности в самостоятельной установке и развертывании БД. Аналогично и в случаях, когда требуется тонкая настройка СУБД, то есть опять же нужен доступ к ее «внутренностям».


Особенности инфраструктуры в облаке, которые следует учитывать при использовании DBaaS


При развертывании баз данных в облаке необходимо знать о некоторых инфраструктурных особенностях. Перечислим их ниже.


Для разных задач предназначены различные типы дисков. Например, в облаке MCS при создании БД доступны диски SSD, High-IOPS SSD и Low Latency NVMe. SSD отличает отказоустойчивость «из коробки», надежность и геораспределенность. Для систем с более высокими требованиями по IOPS (Input/Output Operations Per Second) рекомендуются быстрые диски High-IOPS SSD. А для высоконагруженных приложений, где критически важна скорость отклика, лучше всего подойдут сверхбыстрые диски Low Latency NVMe, которые, в отличие от других типов дисков, размещаются локально, непосредственно на гипервизорах, а также обеспечивают гарантированное время отклика — в нашем облаке не более 0,5 мс.


Краткая сводка по дискам приведена ниже. Более подробно о типах дисков Mail.ru Cloud Solutions и их SLA можно прочитать здесь.


Параметр SSD High IOPS SSD Low Latency NVMe
SLA на IOPS (количество операций в секунду на 2 ТБ пространства) Для чтения — 16 000.

Для записи — 8000.
Для чтения — 45 000.

Для записи — 30 000.
Для чтения — 75 000.

Для записи — 50 000.
SLA на Throughput (пропускная способность на 2 ТБ пространства при размере блока 1М) Для чтения и записи — 400 МБ/с. Для чтения и записи 500 МБ/с. Для чтения — 1200 МБ/с.

Для записи — 900 МБ/с.

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


Например, был выбран диск High-IOPS SSD, на нем развернули базу данных на 50 GB, но при тестировании стало понятно, что IOPS не хватает, хотя диск высокоскоростной. Это происходит потому, что в любом облаке есть QoS (Quality of Service): чтобы клиент, арендовавший 50 GB, не утилизировал полностью диск объемом 2 TB, ресурсы распределяются, в том числе в зависимости от запрошенного объема. И чтобы получить большую производительность, необходимо увеличить размер диска.


Изменение типа и размера диска доступны на лету. Эти операции выполняются без даунтайма через API или UI. Следует учитывать, что изменение размера диска возможно только в большую сторону — во избежание потерь данных.


Производительность ВМ зависит от типа флейвора. Перед созданием БД важно правильно подобрать не только тип и размер дисков, но также тип процессора, количество ядер и объем ОЗУ. Комбинация этих параметров называется флейвором.


В облаке MCS по умолчанию доступны следующие группы флейворов:


Флейвор Назначение Параметры Примеры использования
Basic Базовая группа, содержащая конфигурации ВМ с невысокой производительностью До 2 vCPU
До 4 GB
  • Небольшие базы данных
  • Микросервисы
  • Виртуальные рабочие столы
  • Среды разработки
  • Репозитории кода
Standard Группа с повышенным количеством CPU и объемом RAM 2-4 vCPU
4-16 GB
  • Небольшие и средние базы данных
  • Веб-серверы и серверы приложений
Advanced Группа для создания высокопроизводительных инстансов 8-16 vCPU
16-64 GB
  • Крупные базы данных
  • Игровые серверы
  • Кластерные вычисления
  • Платформы кэширования

Кроме этого, по запросу возможно создание индивидуальных конфигураций, например с использованием высокочастотных процессоров. Стандартные процессоры Intel® Xeon® Gold 6238R CPU @ 2.20GHz подойдут для 90% задач. High-Freq процессоры Intel® Xeon® Gold 6238R CPU с частотой от 3.00GHz, подключаемые по запросу, предназначены для высокопроизводительных вычислений и могут использоваться в таких областях, как машинное обучение, распределенная аналитика, кодирование мультимедиа, игровые задачи, распространение рекламы и так далее. Максимальное число виртуальных ядер для инстанса ВМ на стандартных процессорах — 80 vCPU, для High Frequency — 40 vCPU.


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


Доступны несколько конфигураций БД. В облаке MCS базу данных, в зависимости от типа СУБД, можно развернуть в одной или нескольких конфигурациях из следующего списка:


  1. Single-Instance — единичный инстанс СУБД. Рекомендуется использовать исключительно в целях разработки и тестирования.


  2. Master-Slave — два и более инстанса СУБД с репликацией в режиме Master/Slave (Active/Passive). В этом подходе выделяется основной сервер базы данных, Master, на который отправляются все изменения данных (INSERT/UPDATE/DELETE). Другой сервер, Slave, в синхронном режиме копирует все изменения с Master и обрабатывает запросы на чтение данных (SELECT). Таким образом, Master отвечает за изменение данных, а Slave — за чтение. При выходе из строя любого из них другой временно берет на себя функции и чтения, и записи. Обычно следует использовать не более 20 Slave-серверов при работе с одним Master. Конфигурация рекомендуется для промышленной эксплуатации.


  3. Кластер (Cluster) — кластер с репликацией данных. В этом случае также есть Master и есть сервер, куда направляются реплики данных в синхронном режиме. Если с Master-сервером что-то происходит, система автоматически переключается на другой сервер. При необходимости замена Master доступна и в ручном режиме. Можно добавлять асинхронные реплики, изменять их число и распределять их по различным дата-центрам. Точкой входа в кластер служит отказоустойчивый балансировщик. В случае сбоя на балансировщике происходит бесшовное переключение на другой, активный. Конфигурация рекомендуется, если есть высокие требования к надежности и отказоустойчивости системы.



Следует учитывать сетевые задержки между дата-центрами при настройке синхронных реплик БД. Сетевые задержки между нашими дата-центрами обычно составляют 1–2 миллисекунды, но в зависимости от нагрузки эта величина может меняться. Поэтому при разнесении синхронных реплик по разным дата-центрам можно получить замедление работы базы данных, так как транзакции на Master-сервере будут ожидать подтверждения от реплики в другом дата-центре. Для предотвращения подобных проблем мы советуем Master и синхронные реплики размещать в одном дата-центре, а асинхронные реплики — в другом.


Базы данных, доступные в облаке MCS


Чтобы пояснить, на основании каких критериев выбрать правильный тип СУБД, приведем краткое описание доступных в нашем облаке баз и основные сценарии их использования.


1. PostgreSQL


Это классическая Open Source OLTP-СУБД, поддерживающая стандарт SQL и принципы ACID (Atomicity, Consistency, Isolation, Durability). Чаще всего используется для обработки транзакций в реальном времени.


В нашем облаке доступна в версиях 9.6, 10, 11, 12 и конфигурациях Single-Instance, Master-Slave и «Кластер». Кластер при этом строится на основе Patroni.


Также у нас поддерживается множество расширений PostgreSQL: Prometheus Node Exporter для мониторинга ВМ, Prometheus PostgreSQL Server Exporter для мониторинга состояния самого PostgreSQL, PostGIS для обработки геоданных, PGcrypto для криптографии, Holistic для извлечения и анализа данных, uuid-ossp для генерации UUID и другие. Если потребуется расширение, которого еще нет среди доступных, клиент всегда может обратиться в поддержку — и мы постараемся его добавить.


Рекомендации по использованию:


  • Идеальна для транзакционных нагрузок.
  • Благодаря широкому набору встроенных функций подходит для решения аналитических задач, например построения небольшого DWH (Data Warehouse). Однако следует помнить, что PostgreSQL горизонтально не масштабируется, поэтому при увеличении объемов данных могут возникать проблемы.
  • Если выбирать между MySQL и PostgreSQL, при одинаковом уровне экспертизы в обеих системах рекомендуем PostgreSQL.

2. Postgres Pro Standard


Это объектно-реляционная СУБД (Object-Relational Database Management System, ORDBMS), созданная на основе PostgreSQL. Postgres Pro предоставляет наиболее актуальную версию PostgreSQL c дополнительными расширениями и изменениями. Эта СУБД включает все новые возможности, реализованные компанией Postgres Professional, а также сторонние доработки, которые уже приняты сообществом PostgreSQL и в будущем попадут в новые версии PostgreSQL.


В нашем облаке доступна в версии 11 в конфигурации Single-Instance.


Рекомендации по использованию. Стоит выбирать для транзакционных систем, где есть необходимость в дополнительном функционале, отсутствующем в PostgreSQL. В качестве примеров можно привести усовершенствования полнотекстового поиска, доступ к внутреннему представлению данных, сохранение планов выполнения, покрывающие индексы (INCLUDING) и многое другое. С полным перечнем отличий Postgres PRO Standard от PostgreSQL можно ознакомиться на сайте разработчика.


3. MySQL


Это еще одна популярная Open Source OLTP-система. Однако по сравнению с PostgreSQL она обеспечивает меньшее соответствие стандарту SQL. Отличается высокой производительностью при операциях на чтение.


В нашем облаке доступна в версиях 5.6 и 5.7 в конфигурациях Single-Instance и Master-Slave.


Для осуществления мониторинга у нас поддерживаются расширения Prometheus Node Exporter и Prometheus Exporter For MySQL Server Metrics.


Рекомендации по использованию. Стоит выбрать, если нужна СУБД под транзакционную нагрузку без комплексной внутренней логики и сложных аналитических запросов. При прочих равных PostgreSQL больше подходит для аналитики, а MySQL — в качестве базы данных для Web-приложений.


4. MongoDB


Это одна из самых популярных NoSQL-систем. Она документоориентированная: каждая строка представляет собой JSON или Binary JSON (BSON), что предоставляет значительную гибкость, так как не нужно жестко задавать схему таблиц заранее. Также горизонтально масштабируется, благодаря чему выдерживает очень высокие нагрузки.


В нашем облаке доступна в версии 4.0 в конфигурации Single-Instance.


Рекомендации по использованию:


  • Хранение сложных структур данных, которые часто меняются.
  • Приложения, требующие гибкости и отсутствия жесткой схемы данных. Однако здесь необходимо соблюдать осторожность: если в будущем понадобятся схемы данных и проверки на консистентность, вероятнее всего, их придется реализовывать на стороне самого приложения либо менять СУБД.
  • Подходит для высоких нагрузок.

5. Redis


NoSQL-система для хранения структур данных вида «ключ-значение» (Key-Value) в памяти (In-Memory). За счет этого является крайне быстрой.


По умолчанию она однопоточная (Single-threaded), в связи с чем требуется производительный CPU — в нашем облаке можно использовать High-Freq. Также рекомендуем использовать минимум 4 GB оперативной памяти (RAM), так как это In-Memory-система. А под Persistent Storage — выбирать объем диска, равный значению RAM, умноженному на 3.


В нашем облаке СУБД доступна в версии 5 в конфигурации Single-Instance.


Для осуществления мониторинга поддерживаются расширения Prometheus Node Exporter и Redis Exporter.


Рекомендации по использованию:


  • Кэш.
  • Брокеры сообщений. Поддерживает механизм Pub/Sub.

6. ClickHouse


Это колоночная OLAP-СУБД, заточенная под аналитические нагрузки. Она горизонтально масштабируется с использованием шардирования.


В нашем облаке доступна в версиях 19, 20.8 в конфигурациях Single-Instance и «Кластер».


Рекомендации по использованию:


  • Благодаря высокой скорости работы подходит для аналитики и построения витрин в режиме реального времени на больших данных.
  • Не подходит для произвольных JOIN и ad hoc-запросов, в связи с чем ее использование в качестве основной СУБД для DWH ограничено.
  • Не подходит для систем, где требуются полноценные транзакции.
  • Не подходит для систем, где возможно изменение или удаление ранее записанных данных с высокой частотой запросов и низкими задержками. Поддерживает только массовое изменение и удаление более не нужных данных.
  • Разреженный индекс делает ClickHouse плохо пригодной для точечных операций чтения и записи одиночных строк по своим ключам. Работать с ней лучше батчами (Batch): СУБД ориентирована в первую очередь на поколоночное чтение и аналитику больших объемов данных.

7. Arenadata DB Cloud (ADB)


Это аналитическая СУБД, построенная на MPP-системе с открытым исходным кодом Greenplum. Основана на PostgreSQL — поэтому при наличии экспертизы в PostgreSQL переход на ADB может быть довольно простым. Горизонтально масштабируется, благодаря чему выдерживает высокие нагрузки.


В нашем облаке доступна в версиях 6.5 и 6.11 в конфигурации «Кластер». СУБД изначально является кластерной, позволяя равномерно распределять нагрузку и данные между множеством узлов кластера.


Рекомендации по использованию:


  • Решение OLAP-задач.
  • Построение DWH-хранилищ.
  • Решение задач с произвольными JOIN-ами, ad hoc-запросами на больших объемах данных.

Пример создания проекта с DBaaS на платформе MCS


Напоминаю, что эти же действия можно посмотреть на видео. Ну а если расписать по шагам, то выполняем следующие действия.


1. Выбор типа БД и ее создание по шагам


Чтобы начать работу с DBaaS на платформе MCS, необходимо в панели управления облаком выбрать пункт меню «Базы данных» — «Инстансы баз данных» или, если требуется Arenadata DB, то «Аналитические БД» — «Инстансы баз данных».


На экране отобразится список ранее созданных баз данных. Для создания новой необходимо нажать кнопку «Добавить».



Добавление новой базы данных


На первом шаге потребуется выбрать тип СУБД и ее конфигурацию. Для примера выберем PostgreSQL в конфигурации Single-Instance.



Выбор типа СУБД и конфигурации на первом шаге создания инстанса БД


На втором шаге необходимо указать имя инстанса БД и определить конфигурацию ВМ, которая будет лежать в его основе. Выбор типа ВМ осуществляется из предопределенного списка флейворов. Например, флейвор Standard-4-8 — это 4 CPU и 8 ГБ RAM. Наличие префикса 152-FZ для некоторых флейворов означает, что при их выборе база данных будет создана в защищенном контуре (аттестованном согласно федеральному закону номер 152-ФЗ).



Выбор конфигурации ВМ на втором шаге создания инстанса БД


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



Выбор зоны доступности, типа и размера диска, включение/отключение автомасштабирования на втором шаге создания инстанса БД


Далее на этом же шаге выбирается сеть из списка доступных. При необходимости можно установить доступ к инстансу БД по внешнему IP. При назначении внешнего IP рекомендуется использовать Firewall — в нашем примере указана преднастроенная группа безопасности only_my_ip, которая отвечает за доступ к базе данных только с разрешенных IP.


Здесь же при необходимости можно установить необходимость создания Read-only-реплики и периодичность резервного копирования.



Выбор сети, назначение внешнего IP, настройка Firewall и установка периодичности резервного копирования на втором шаге создания инстанса БД


На следующем шаге указывается имя базы данных, оно по умолчанию совпадает с именем инстанса, и имя пользователя — по умолчанию user. Далее необходимо сгенерировать пароль для пользователя, нажав на кнопку «Сгенерировать». И здесь же при необходимости можно восстановить базу данных из бэкапа, если он есть, установив переключатель «Восстановить из резервной копии» и указав путь к бэкапу. При отсутствии бэкапа будет создана новая база.



Генерация пароля пользователя и выбор бэкапа для восстановления (при необходимости) на третьем шаге создания инстанса БД


После заполнения всех данных необходимо нажать кнопку «Создать базу данных» — запустится создание инстанса БД, которое займет некоторое время.


2. Настройка параметров созданной БД


После завершения инициализации инстанса БД откроется страница с несколькими вкладками. На первой вкладке «Информация» будут доступны основные данные об инстансе БД, включая сниппеты для подключения к нему из различных приложений.



На вкладке «Информация» отображаются данные о созданном инстансе БД. В нижней части формы доступны сниппеты для подключения из различных приложений


На вкладке «Список баз данных» можно просмотреть список созданных на вашем сервере баз и создать новую, нажав на кнопку «Добавить». При добавлении новой БД необходимо указать только ее имя.



Просмотр баз данных, созданных на сервере, на вкладке «Список баз данных». Для создания новой необходимо нажать на кнопку «Добавить»


На вкладке «Параметры баз данных» можно устанавливать кастомные значения для различных характеристик сервера БД. Для этого необходимо выбрать параметр из списка доступных и ввести его значение.



Установка кастомных значений для параметров сервера БД на вкладке «Параметры баз данных»


На вкладке «Пользователи» можно просматривать и удалять существующих пользователей и создавать новых. Для добавления пользователя требуется нажать на кнопку «Добавить».



Просмотр пользователей на вкладке «Пользователи». Для добавления нового пользователя следует нажать на кнопку «Добавить»


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



Добавление нового пользователя


На последней вкладке «Расширения» доступен просмотр расширений, подключенных к вашей БД. Это могут быть расширения для отправки метрик в Prometheus, для работы с криптографией, геоданными и так далее. Для добавления нового расширения необходимо нажать на кнопку «Добавить».



Вывод подключенных расширений БД на вкладке «Расширения». Для добавления нового следует нажать на кнопку «Добавить»


Затем стоит выбрать расширение из числа доступных.



Выбор расширения из списка доступных


И заполнить необходимые параметры, например номер порта и так далее.



Заполнение параметров выбранного расширения


3. Операции, доступные над созданной БД


Для того чтобы выполнять какие-либо операции над созданными базами данных, необходимо вернуться в пункт меню «Базы данных» — «Инстансы баз данных». Здесь отобразится наш инстанс в Single-варианте.


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



Действия, доступные над выбранной БД: перезапуск, остановка/запуск, удаление


Другие операции, доступные над выбранной БД, можно посмотреть в ее выпадающем меню. Из него можно создать незапланированный бэкап, реплику, переведя таким образом Single-вариант в Master-Slave, изменить указанные на этапе создания размеры дисков и их автомасштабирование, изменить/сбросить пароли и удалить БД.



Операции, доступные над БД из выпадающего меню


Аналогичное выпадающее меню доступно на уровне конкретной ВМ, на которой развернута БД — в нашем случае она пока одна, с типом Master. В этом меню по сравнению с описанным выше добавляется возможность остановки, перезапуска и удаления конкретного инстанса, назначения ему внешнего IP, а также вертикального масштабирования ресурсов.


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



Операции, доступные над выбранным инстансом (ВМ) из выпадающего меню


4. Перевод созданной БД в режим Master-Slave


Single-конфигурацию БД всегда можно перевести в Master-Slave. Для этого достаточно в выпадающем меню БД выбрать пункт «Создать реплику» и в открывшейся форме выбрать конфигурацию ВМ, зону доступности, тип и размер диска, назначить внешний IP при необходимости.



Форма для добавления реплики. Открывается после выбора пункта выпадающего меню «Создать реплику»


Когда реплика будет добавлена, на странице просмотра базы данных на вкладке «Информация» можно будет увидеть количество Slave-узлов, равное 1. Таким образом, Single-конфигурация будет преобразована в Master-Slave.



На вкладке «Информация» после добавления реплики отображается количество Slave-узлов


На странице с инстансами БД для созданной реплики станет доступно выпадающее меню, в котором наряду с прочими появится пункт «Преобразовать в мастер». При его выборе Master- и Slave-узлы поменяются ролями.



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


5. Краткий обзор конфигурации «Кластер»


Конфигурация «Кластер», в отличие от Master-Slave, может быть выбрана только на начальном этапе создания БД. В этом случае доступны Master-узел, синхронная реплика и асинхронные реплики. Последние можно добавлять по мере необходимости уже после создания кластера. Для этого в выпадающем меню необходимо выбрать пункт «Расширить кластер» и в открывшейся форме выбрать зону доступности и тип дисков для новой асинхронной реплики. Прочие параметры будут определяться конфигурацией ВМ, указанной при создании кластера.



Выпадающее меню, доступное для БД в конфигурации «Кластер». Для добавления асинхронной реплики необходимо выбрать пункт «Расширить кластер»



Добавление асинхронной реплики при расширении кластера. Необходимо выбрать зону доступности и тип диска


6. Работа с бэкапами: просмотр, настройка расписания, ручное добавление


Для работы с бэкапами необходимо перейти в раздел «Бэкапы». Здесь отобразятся текущие настройки резервного копирования (РК) для нашей БД, выбранные при ее создании. С помощью выпадающего меню можно выполнить остановку РК, просмотр ранее созданных бэкапов и настройку расписания бэкапов.



Раздел «Бэкапы»


Для обновления расписания РК необходимо выбрать пункт выпадающего меню «Настроить параметры резервного копирования». В открывшейся форме можно просмотреть, изменить и удалить текущее расписание, а также добавить дополнительное расписание, нажав на кнопку «Добавить новое расписание». При выборе периодичности РК раз в сутки можно выбрать конкретные дни недели и время начала создания бэкапов.



Форма настройки параметров РК, доступная после выбора пункта выпадающего меню «Настроить параметры резервного копирования»


Параметры РК обновляются в соответствии с введенным расписанием.



Обновление параметров можно увидеть в разделе «Бэкапы»


Наряду с созданием бэкапов по расписанию можно в любой момент добавить бэкап вручную. Для этого необходимо вернуться в раздел «Базы данных» — «Инстансы баз данных» и в выпадающем меню выбрать пункт «Создать бэкап».



Переход к ручному добавлению бэкапа из раздела «Базы данных» — «Инстансы баз данных»


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



Ручное добавление бэкапа


Все бэкапы хранятся в объектном хранилище S3. Чтобы их посмотреть, можно выбрать раздел «Бакеты» и найти в нем бакет, название которого начинается на «databasebackups-». Отсюда можно загрузить бэкапы к себе. Также мы предоставляем инструкцию, описывающую, как на основе этих бэкапов развернуть базу данных On-premise.



Просмотр бэкапов в объектном хранилище S3


Если хотите сами пройти действия из этой статьи, подключитесь к платформе Mail.ru Cloud Solutions. Новые пользователи платформы получают 3000 бонусных рублей для тестирования.

Что еще почитать:


  1. Как запускать в облаке приложения, требовательные к latency? СУБД Arenadata DB на сверхбыстрых облачных дисках.
  2. Как выбрать облачную систему хранения данных, чтобы получить лучшую производительность и оптимизировать стоимость.
  3. Подход Multicloud Native Service: что это такое и как поможет сделать IT-систему максимально отказоустойчивой.
Теги:
Хабы:
+21
Комментарии 5
Комментарии Комментарии 5

Публикации

Информация

Сайт
team.vk.company
Дата регистрации
Дата основания
Численность
свыше 10 000 человек
Местоположение
Россия
Представитель
Руслан Дзасохов