облачные базы данных для мобильного приложения
Бесплатные сервисы для разработчиков — огромный список
Бесплатное хранилище артефактов PackageCloud
Удивительно, но в интернете сотни сервисов, которыми разработчик может пользоваться совершенно бесплатно. «Бесконечное» время (пока компания не обанкротится или не изменит условия), без рекламы, пробного периода и других подводных камней.
Недавно мы обсуждали эту тему в статье «Боль разработчика: “Никогда не давайте пользователям бесплатный тариф”». Речь шла о том, что на самом деле бесплатный план вовсе не бесплатен — приходится тратить массу времени и усилий на поддержку этих тарифов.
Но для некоторых бесплатный тариф — единственный способ завлечь новых клиентов. Это просто замечательно с точки зрения самих пользователей. Ведь перед нами десятки бесплатных хостингов, API, CMS, CDN, сервисов обработки данных, поисковых движков, репозиториев, инструментов проверки кода и других. Бесплатный тариф идеален для опенсорс-разработчиков, любительских и некоммерческих проектов, маленьких стартапов. Ни за что не надо платить.
Например, огромный список бесплатных сервисов для разработчиков ведётся в репозитории free-for-dev. Список составлен пул-реквестами более 900 участников.
Важно подчеркнуть, что конкретно в этом списке отсутствуют альтернативы на своём хостинге (о них см. ниже). Здесь исключительно онлайновые сервисы, то есть SaaS, PaaS, IaaS.
Приведены только сервисы с честным бесплатным тарифом, которым можно пользоваться без ограничения по времени, без перехода на платную подписку. Обычно такой честный тариф ограничен только по объёму услуг.
Для примера вот несколько тематических категорий.
Основные облачные провайдеры
Ниже указано, в каком объёме предоставляются бесплатные услуги.
Аналитика, статистика, логи
Вот несколько сервисов бесплатной аналитики для мобильных приложений и сайтов. Здесь только бесплатные сторонние сервисы. Многие из них можно использовать вместо скриптов Google Analytics, поскольку GA рассматривается как угроза приватности.
Примечание. Программы self-hosted см. в отдельной категории.
Другие категории
Эмулятор основных операционных систем в браузере copy.sh
Облачные сервисы и аналитика — лишь малая капелька в море бесплатных услуг для разработчиков. Вот ещё 45 категорий. В каждой от нескольких штук до несколько десятков сервисов с бесплатными тарифами.
Опенсорсные инструменты безопасности
Компания Penetrum Security, которая специализируется на информационной безопасности, составила собственный список опенсорсных инструментов для разработчиков, с упором на безопасность.
Например, в нём есть системы для управления уязвимостями Faraday, Archery Sec, Jackhammer,
Watchdog и OpenVAS, сканер контейнеров trivy, менеджеры конфигурация вроде MGMT, Chef и Puppet, бесплатные системы SIEM (анализ событий в реальном времени и реагирование), VPN, инструменты для улучшения безопасности систем на Linux и Windows (Bastille, JShielder, nixarmor, Zeus (AWS), Docker-bench и др.), защита аутентификации в Linux, чёрные списки IP и доменов, прокси, socks-серверы, HTTP-туннели, FTP-прокси, DNS-прокси, инструменты сетевого и серверного мониторинга, системы для определения вторжений в сеть и на хост (NIDS и HIDS, соответственно), мониторинг и анализ логов, антивирусы, спам-фильтры, симуляторы инфраструктуры, файрволы для веб-приложений, сетевые сканеры, системы форензики (поиск цифровых улик), программы анализа файлов, метаданных, оперативной памяти и многие другие инструменты.
Всё бесплатно и с открытыми исходниками.
Бесплатные альтернативы на своём хостинге
Вышеупомянутый список free-for-dev не включает бесплатные инструменты на своём хостинге. Однако их очень много. Обычно это опенсорсные программы. Бывает, что какой-то коммерческий сервис SaaS одновременно публикует исходники, то есть предлагает параллельно платный и бесплатный тариф.
Вот список бесплатных альтернатив на своём хостинге в 81 категории из коллекции awesome-selfhosted:
Списки бесплатных ресурсов для разработчиков также ведутся в проектах FOSS-for-Dev, getAwesomeness и De-google-ify Internet.
Надеемся, что эта подборка окажется кому-то полезной.
Наша компания предлагает облачные серверы для любых задач и на любой операционной системе. Создавайте собственные конфигурации в течение минуты, минимальный тариф — всего 6.5 рублей в день!
Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!
Работа с данными в мобильных приложениях. Реализуем offline хранилище и синхронизацию данных используя Microsoft Azure и SQLite
Azure Mobile Services SDK для синхронизации
Функциональность нового Microsoft Azure Mobile Services SQLiteStore SDK 1.0 alpha для синхронизации данных не идентична Sync Framework или Azure Data Sync.
С точки зрения клиентской стороны, пока есть возможность работать только с SQLite, но создатели обещают, что возможности будут развиваться и другие клиентские БД добавятся позже.
Серверная сторона поддерживает следующие базы данных: SQL Database, MongoDB и Azure Table Storage.
SDK поддерживает следующие операции: Push (отправка на сервер), Pull (загрузка с сервера), Purge (очистка локального хранилища).
Сегодня мы остановимся на том, как создать бэкенд для вашего приложения используя Microsoft Azure Mobile Services SQLiteStore SDK 1.0 alpha.
Настройка Azure Mobile Services
1. Чтобы создать Azure Mobile Service для вашего проекта, необходимо открыть Microsoft Azure Portal и перейти в меню Mobile Services – New
Создавая облачный сервис, вы можете выбрать на каком языке вы будете писать код сервиса. На С# или JavaScript.
2. Когда мобильный сервис создастся, на главной странице сервиса, вы сможете найти инструкции, как использовать его в приложениях для многих популярных платформ и фреймфорков, таких как Windows, Windows Phone, IOS, Android, Xamarin.
3. Вы можете скачать шаблон проекта облачного сервиса, доработать его код, например, поправив модель данных как на скриншоте ниже.
4. Затем, опубликовать в облаке из Visual Studio.
Как разработать и опубликовать облачный сервис достаточно подробно написано тут.
Создаем проект приложения
1. Я буду использовать проект универсального приложения для Windows и Windows Phone.
2. После создания проекта, подключим необходимые библиотеки. Так как у нас проект и для Windows и для Windows Phone, то установить WindowsAzure.MobileServices надо для обоих проектов.
3. В общем проекте (Shared), открываем App.xaml.cs и добавляем туда объявление мобильного сервиса:
4. Теперь мы можем работать с данными через облачный сервис и сохранять данныe в БД.
Создание локальной базы данных и синхронизация
Теперь нам надо создать локальное хранилище данных SQLite.
2. Добавим SQLite в качестве используемой библиотеки для наших приложений Windows и Windows Phone.
3. Установим и добавим в References пакет WindowsAzure.MobileServices.SQLiteStore
4. Откроем Shared проект и создадим там новый пустой класс с моделью данных. В моем случае, он получился вот такой:
5. Создадим вспомогательный класс, который будет создавать нам локальную базу данных, уметь наполнять её данными и отправлять данные в облачный сервис.
Интерфейс приложения
1. Откроем MainPage.xaml и добавим туда кнопки для заполнения таблицы данными и синхронизации.
2. Добавим в MainPage.xaml.cs код для обработки событий.
Запуск и проверка
1. Запустим приложение и посмотрим как оно работает.
2. Как только мы запустили приложение, у нас уже создалась локальная база SQLite. Мы можем найти её в папке приложения и посмотреть. Для этого я буду использовать SQLite Browser.
Моя БД лежит тут: C:\Users\[username]\AppData\Local\Packages\[app id]\LocalState
Как видите, сейчас она пустая.
3. Добавим в неё элемент, нажав на кнопку Add Item нашего приложения.
4. Данные в базе обновятся и туда добавится запись, но наша облачная БД всё еще пуста.
5. Теперь нажмем на кнопку Sync в приложении для синхронизации баз данных и смотрим результат.
Синхронизация отработала и в облачной базе появились данные из локальной базы приложения.
Может так оказаться, что создание локальной БД упадет с ошибкой. Тогда найдите и добавьте в References сборку SQLitePCL.Ext.dll. Сама она почему-то не всегда устанавливается NuGet’ом.
Заключение
Новый Microsoft Azure Mobile Services и его SDK имеет много новых полезных возможностей для разработчиков приложений. Одна из них – это поддержка offline работы и синхронизации данных для приложений. Следуя этой инструкции, вы можете настроить синхронизацию данных для вашего Phone или Windows приложения не тратя много времени на сложные алгоритмы и написание библиотек.
База данных как сервис: когда, зачем и как использовать DBaaS в облаке
Database by Julian-Faylona
Многие облачные платформы предлагают базы данных как сервис (Database as a Service, DBaaS). Базу можно создать в облаке в несколько кликов, не тратя время на настройку и поддержку. Но не всем приложениям облачные базы данных подходят.
Мы расскажем, как на старте проекта не ошибиться с выбором облачной СУБД. Эта статья — вольная переработка нашего вебинара (видео тут).
Мы разберем, когда стоит и не стоит использовать DBaaS, какие особенности нужно учесть при работе с ними и как выбрать подходящую базу данных с учетом особенностей ИТ-инфраструктуры, объема и специфики задач. В конце посмотрим, как устроено создание базы данных в облаке и какие операции с ней доступны, на примере DBaaS Mail.ru Cloud Solutions.
Кому подходит и не подходит DBaaS
Как показывает опыт, наиболее часто к DBaaS обращаются в следующих случаях:
Требуются мощности для Dev- и Test-сред с оплатой по принципу Pay-as-you-go. Нередко бывает, что Production-среда в компании развернута на On-premise-серверах, но инженерам и разработчикам для тестирования приложений требуются дополнительные мощности под регулярно создаваемые и удаляемые БД. Это удобно делать в облаке, где ресурсы предоставляются по запросу и можно гибко управлять их потреблением, настраивая лимиты для каждого проекта или разработчика.
Оплачиваются при этом только используемые вычислительные мощности с посекундной тарификацией. В любой момент можно остановить неиспользуемую БД, после чего оплачиваться будет только место на диске, а не CPU и RAM.
Нужно быстро развернуть решение, аттестованное по 152-ФЗ. Если компания работает с персональными данными и необходимо соответствовать требованиям 152-ФЗ, использование DBaaS в аттестованном облаке может оказаться наиболее быстрым и простым решением, так как в этом случае не приходится тратить время и ресурсы на самостоятельное развертывание и аттестацию защищенного контура.
При этом зачастую компании переносят в облако только часть данных, оставляя наиболее «чувствительные» на своей стороне. Это позволяет значительно сэкономить на используемых мощностях, особенно при обработке больших объемов данных.
Требуется недорогое хранилище для резервных копий. В облаке MCS для хранения бэкапов баз данных можно использовать отказоустойчивое объектное хранилище S3. Хранение массивных бэкапов с редким доступом в таком хранилище обойдется намного дешевле, чем на локальных серверах. S3 позволяет хранить неограниченный объем данных без каких-либо специальных действий со стороны пользователя для увеличения объема хранения, а оплачивается только фактически использованный объем хранения.
Кроме этого, сами бэкапы автоматизированы и расписание их создания легко настраивается. При необходимости бэкапы из S3 всегда можно выгрузить в On-premise-хранилище.
В команде не хватает опыта самостоятельной настройки и администрирования СУБД. Установка и настройка любой СУБД требует времени, а создание отказоустойчивой системы — высокого уровня квалификации команды. Используя 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.
Для записи — 30 000.
Для записи — 50 000.
Для записи — 900 МБ/с.
Производительность дисков в облаке напрямую зависит от их объема. Для облачных дисков лимит на операции ввода-вывода всегда определяется на определенный шаг дискового пространства. Если нужно увеличить скорость обработки данных, то иногда достаточно просто увеличить размер требуемого диска.
Например, был выбран диск High-IOPS SSD, на нем развернули базу данных на 50 GB, но при тестировании стало понятно, что IOPS не хватает, хотя диск высокоскоростной. Это происходит потому, что в любом облаке есть QoS (Quality of Service): чтобы клиент, арендовавший 50 GB, не утилизировал полностью диск объемом 2 TB, ресурсы распределяются, в том числе в зависимости от запрошенного объема. И чтобы получить большую производительность, необходимо увеличить размер диска.
Изменение типа и размера диска доступны на лету. Эти операции выполняются без даунтайма через API или UI. Следует учитывать, что изменение размера диска возможно только в большую сторону — во избежание потерь данных.
Производительность ВМ зависит от типа флейвора. Перед созданием БД важно правильно подобрать не только тип и размер дисков, но также тип процессора, количество ядер и объем ОЗУ. Комбинация этих параметров называется флейвором.
В облаке MCS по умолчанию доступны следующие группы флейворов:
Кроме этого, по запросу возможно создание индивидуальных конфигураций, например с использованием высокочастотных процессоров. Стандартные процессоры Intel® Xeon® Gold 6238R CPU @ 2.20GHz подойдут для 90% задач. High-Freq процессоры Intel® Xeon® Gold 6238R CPU с частотой от 3.00GHz, подключаемые по запросу, предназначены для высокопроизводительных вычислений и могут использоваться в таких областях, как машинное обучение, распределенная аналитика, кодирование мультимедиа, игровые задачи, распространение рекламы и так далее. Максимальное число виртуальных ядер для инстанса ВМ на стандартных процессорах — 80 vCPU, для High Frequency — 40 vCPU.
Вертикальное масштабирование ВМ, то есть изменение выделенных им ресурсов уже после создания, возможно, но требует незначительного даунтайма — ориентировочно в пределах минуты.
Доступны несколько конфигураций БД. В облаке MCS базу данных, в зависимости от типа СУБД, можно развернуть в одной или нескольких конфигурациях из следующего списка:
Single-Instance — единичный инстанс СУБД. Рекомендуется использовать исключительно в целях разработки и тестирования.
Master-Slave — два и более инстанса СУБД с репликацией в режиме Master/Slave (Active/Passive). В этом подходе выделяется основной сервер базы данных, Master, на который отправляются все изменения данных (INSERT/UPDATE/DELETE). Другой сервер, Slave, в синхронном режиме копирует все изменения с Master и обрабатывает запросы на чтение данных (SELECT). Таким образом, Master отвечает за изменение данных, а Slave — за чтение. При выходе из строя любого из них другой временно берет на себя функции и чтения, и записи. Обычно следует использовать не более 20 Slave-серверов при работе с одним Master. Конфигурация рекомендуется для промышленной эксплуатации.
Кластер (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 и другие. Если потребуется расширение, которого еще нет среди доступных, клиент всегда может обратиться в поддержку — и мы постараемся его добавить.
Рекомендации по использованию:
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.
Рекомендации по использованию:
6. ClickHouse
Это колоночная OLAP-СУБД, заточенная под аналитические нагрузки. Она горизонтально масштабируется с использованием шардирования.
В нашем облаке доступна в версиях 19, 20.8 в конфигурациях Single-Instance и «Кластер».
Рекомендации по использованию:
7. Arenadata DB Cloud (ADB)
Это аналитическая СУБД, построенная на MPP-системе с открытым исходным кодом Greenplum. Основана на PostgreSQL — поэтому при наличии экспертизы в PostgreSQL переход на ADB может быть довольно простым. Горизонтально масштабируется, благодаря чему выдерживает высокие нагрузки.
В нашем облаке доступна в версиях 6.5 и 6.11 в конфигурации «Кластер». СУБД изначально является кластерной, позволяя равномерно распределять нагрузку и данные между множеством узлов кластера.
Рекомендации по использованию:
Пример создания проекта с 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