Управление схемой с помощью Skema

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

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

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

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

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

Как мы управляем схемой

Наш текущий процесс управления схемой использует один репозиторий Git для хранения исходной схемы для всех наших кластеров базы данных и содержит все последующие изменения этой схемы по мере изменения/создания и удаления отдельных таблиц:

• Разработчик вносит изменения в схему локально, генерирует оператор alter/create/drop и добавляет его как запрос на включение в ветвь интеграции.
• Набор тикетов Jira для команды операций с данными создается для проверки и применения изменений схемы к нашим тестовым/промежуточным и производственным средам.
• Член группы операций с данными просматривает запрошенное изменение, применяет его к тестовой/промежуточной среде и объединяет PR с веткой интеграции.
• Запрашивающий разработчик тестирует изменение в наших тестовых/промежуточных средах и утверждает изменение для внедрения в рабочую среду.
• Наконец, Data Operations объединяет интеграционную ветвь с master и применяет изменение схемы к производственной среде.

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

Защита базы данных — это одно, но этот процесс создает несколько препятствий для надежного и эффективного внесения изменений в схему:

• Проверка и внесение изменений в схему происходит с периодичностью два раза в неделю и может легко выйти из строя, поскольку несколько команд работают с разными базами данных в одном и том же репозитории Git, и все полагаются на кого-то из группы операций с данными для проверки и внесения изменений в различные среды.
• Наличие одного репозитория для всех схем реляционных баз данных может привести к сложным процессам выпуска. Изменение одной схемы, готовой к работе, не может быть запущено в работу, если есть другие изменения схемы, которые не готовы к отправке в рабочую среду, но находятся в промежуточной стадии, ожидая дополнительного тестирования.
• Команда операций с данными, которая является небольшой командой, становится узким местом, пытаясь управлять тем, какие изменения могут и не могут быть запущены в производство и когда. Конфликты планирования и доступность персонала могут существенно замедлить выпуск новых функций или исправлений для текущих приложений.
• Мы вручную применяем эти изменения к производственным системам, используя комментарии в запросах на вытягивание и тикетах Jira; иногда копипаста может пойти ужасно неправильно.

Введите Skeema (и несколько помощников)

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

Мы автоматизировали применение изменений схемы от локальной разработки к рабочей среде, используя наши существующие инструменты, Git, Buildkite CI и pt-online-schema-change, добавив еще один, Skeema.

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

Skeema — это инструмент командной строки, который декларативно управляет схемой MySQL с помощью SQL.

Он может генерировать язык определения данных (DDL) для каждой таблицы в базе данных и экспортировать DDL в локальную файловую систему для интеграции с репозиторием отслеживания через Git. Skeema может сравнивать файлы SQL в репозитории Git с действующей базой данных MySQL и выводить эти различия в виде операторов DDL.

Его также можно настроить для использования инструмента Percona pt-online-schema-change и отформатировать необходимую команду pt-online-schema-change для сопоставления схемы работающей базы данных MySQL со схемой, определенной в репозитории Git.

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

Создание отдельных репозиториев схемы базы данных MySQL разрушит наш текущий монолитный репозиторий db-schema Git и позволит разработчикам из отдельных команд управлять схемой MySQL своего приложения в своем собственном репозитории вместо общего репозитория (db-schema).

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

Жизненно важным компонентом автоматизации этого процесса является конвейер CI Buildkite. Мы создали конвейер, который:

• Проверяет синтаксические ошибки SQL
• Создает тестовый сервер MySQL, используя текущую основную ветвь схемы базы данных, и тестирует применение изменений в запросе на вытягивание (PR).
• Проверьте различия и примените изменения PR к нашей тестовой среде MySQL.
• Проверьте различия и примените изменения PR к нашей промежуточной среде и выведите некоторую табличную статистику из производственной среды.

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

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

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

Деструктивные изменения разрешены в наших тестовых и промежуточных средах.

Мы также настроили Skeema для использования pt-online-schema-change для внесения изменений в схему. Это тот же инструмент изменения схемы, с которым команда DataOps знакома и который используется в SendGrid уже много лет. Мы разработали набор разумных опций для pt-online-schema-change, чтобы откатить свои изменения, если репликация отстает или количество активных потоков в базе данных становится избыточным.

Такая настройка Skeema устраняет потенциальные ошибки, связанные с ручными действиями для приложения и ручным кодированием команд pt-online-schema-change членами команды DataOps.

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

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

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

Сочетание Git, pt-online-schema-change, Skeema и конвейера Buildkite CI обеспечивает надежный, повторяемый программный процесс изменения схемы базы данных MySQL. Это позволяет разработчикам безопасно управлять схемой своих баз данных и контролировать скорость развертывания функций и исправлений в рабочей среде.

Включение соответствующих ограничений в файлы конфигурации для изменения схемы Skeema и pt-online-schema обеспечивает определенную степень уверенности для разработчиков, реализующих изменения схемы, и дает ценную информацию о возможных способах продолжения изменения схемы, если эти ограничения будут нарушены.

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