В этой статье мы рассмотрим основные принципы миграции БД без даунтайма и дадим быстрые рецепты для наиболее распространенных случаев.
Давайте взглянем на типовой процесс выкладки веб-приложения в прод. Большинство приложений, рассчитанных на выкладку без даунтайма, сегодня опираются на балансировщики нагрузки и оркестрацию контейнеров:
Читать полностью »Привет, любители ! Сегодня я решил поделиться своим вариантом бекапа данных из MySql и рассказать о том как его можно использовать для контроля версий в Git. И если вам интересно узнать, как можно контролировать состояние базы данных на всех этапах разработки, или просто делать правильные бекапчики базы своих проектиков и разворачивать из в любой момент времени, тогда прошу к прочтению!Читать полностью »
Это первая часть статьи, в которой я расскажу о том, как мы построили процесс работы над большим проектом по миграции БД: про безопасные эксперименты, командное планирование и кросс-командное взаимодействие. В следующих статьях подробней расскажу про технические проблемы, которые мы решали: про масштабирование и отказоустойчивость PostgreSQL и нагрузочное тестирование.
Долгое время основной базой данных в RealtimeBoard был Redis. Мы хранили в нём всю основную информацию: данные о пользователях, аккаунтах, досках и т.д. Всё работало быстро, но мы столкнулись с рядом проблем.
Проблемы с Redis
Эти проблемы вместе с ростом количества данных на серверах послужили причиной для миграции БД.
Читать полностью »
Недавно мы рассказали об архитектуре Яндекс.Облака. Теперь давайте перейдем от теории к практике. В Облаке есть несколько сервисов для автоматизированного контроля за СУБД: Managed Service for ClickHouse, Managed Service for PostgreSQL и Managed Service for MongoDB. Все они являются платформенными и позволяют сосредоточиться на задаче хранения данных, а не на администрировании инфраструктуры. Но иногда бывает важно контролировать ещё и виртуальные машины кластера. Например, может возникнуть задача масштабирования в ответ на увеличение или снижение нагрузки. Обычно этот сценарий — один из самых трудоёмких с практической точки зрения. Сегодня мы расскажем, как Яндекс.Облако позволяет автоматизировать сложные задачи масштабирования, и убедимся, что база остаётся доступной в процессе изменения размера кластера.
Привет! Сегодня я выпустил новую версию ThinkingHome.Migrator — инструмента для версионной миграции схемы базы данных под платформу .NET Core.
Пакеты опубликованы в NuGet, написана подробная документация. Вы уже можете пользоваться новеньким мигратором, а я расскажу, как он появился, почему у него номер версии 3.0.0 (хотя это первый релиз) и зачем он нужен, когда есть EF Migrations и FluentMigrator.
Статья будет интересна тем, кто хоть раз задумывался о вопросе наката изменений (патча) на реляционную БД. Статья не будет интересна тем, кто уже освоил и использует Liquibase. Главной целью данной статьи является указание ссылки на репозиторий с примером использования. В качестве примера я выбрал накат sample-схемы HR на БД Oracle (список всех поддерживаемых БД) — любой желающий может скачать себе репозиторий и поиграться в домашних условиях. Желание продемонстрировать пример вызвано обсуждением этого вопроса на ресурсе sql.ru.
Liquibase — это система управления миграциями базы данных. Эта вторая статья о Liquibase, на этот раз содержащая советы «боевого» использования системы. Для получения базовых сведений подойдет первая статья-перевод «Управление миграциями БД с Liquibase» (ссылка).
Как и многие инструменты, служащие для облегчения жизни разработчиков программного обеспечения, Liquibase имеет «обратную сторону медали», с которой приходится рано или поздно столкнуться.
Вот 10 вещей, которые в определенный момент работы с Liquibase были для меня открытием.
Если вы не будете следовать этому правилу, файлы чейнджлогов быстро украсят папку миграций своим количеством и необычными именами.
На данный момент для себя я выработал оптимальную стратегию именования файлов и папок. Вот она:
/db-migrations
/v-1.0
/2013-03-02--01-initial-schema-import.xml
/2013-03-02--02-core-data.xml
/2013-03-04--01-notifications.xml
/changelog-v.1.0-cumulative.xml
/v-2.0
...
/changelog-v.2.0-cumulative.xml
/changelog.xml
Подробнее:Читать полностью »
Вольно цитируя вступление к соответствующей статье на RailsGuides,
Миграции — это удобный способ управления структурой и изменениями схемы БД.
Конечно, можно вести дела по старинке, оперирую множеством SQL-файлов, или, о ужас!, редактируя куски SQL-кода в одном большом файле, который представляет собой актуальную схему БД.
Однако следить за этими изменениями, начиная с некоторого момента, становится очень сложно, не говоря уже о применении соответствующих изменений на продакшен-машине: тут нужно обладать ловкостью гепарда, силой медведя и мудростью всех восточных мудрецов, вместе взятых, чтобы все сделать правильно и ничего не уронить.
Но как быть, если Вы не обладаете какими-либо из вышеперечисленных качеств? Правильно, нужно систематизировать и автоматизировать процесс, переложив большую часть работы на машину.
Если Вы уже заинтересовались, или все еще не уверены, но перспектива иметь прозрачную историю изменений и возможность с помощью одной-двух консольных команд откатиться на любою версию схемы, звучит заманчиво, прошу под кат.
Читать полностью »
Не так давно мы начали внедрять Liquibase в качестве инструмента миграций схемы данных в большинстве наших проектов, новых и уже существующих. Система миграций схемы базы данных Liquibase хороша тем, что позволяет использовать системы контроля версий, VCS, (например, Git) для управления ревизиями базы данных приложения. Говоря более точно, VCS содержит описание изменений, необходимые для миграции схемы базы данных из одной ревизии в другую.
Хотя миграция схемы базы данных кажется довольно простой задачей изначально, задача становится сложнее после того, как появляется желание откатывать изменения схемы без ее создания заново.
Кроме схемы и операций DDL, Liquibase позволяет мигрировать данные приложения, с поддержкой наката изменений данных и их отката. Читать полностью »
В данной заметке я покажу, как запускать DBDeploy из скрипта Gradle.
Возможно, вы уже слышали о версионированной миграции структуры баз данных. Об этом писали на хабре. DBDeploy — один из самых простых и известных инструментов, позволяющий легко установить все последние изменения в базе данных на любом инстансе и любой девелоперской машине. А Gradle — модный ныне инструмент для сборки проекта (как Ant и Maven, только лучше). О нём тоже уже писали.
Вопрос в том, как запускать DBDeploy из скрипта Gradle? У DBDeploy есть таски для Ant и плагин для Maven, но пока ещё нет плагина для DBdeploy (точнее, он в зачаточном состоянии). Немного потыркавшись, я пришёл к выводу, что самый простой способ — это использовать тот самый Ant таск DBDeploy из скрипта Gradle (здесь описано, как из gradle-скрипта использовать любые Ant-таски). Рассмотрим пример.