Какие методы или инструменты обеспечивают непрерывное развертывание баз данных?

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

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

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

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

Pramod Sadalage и Scott Ambler написали книгу « Рефакторинг баз данных: эволюционный дизайн баз данных», которая является невероятно прочным учебником по теме БД в оргкоманде / команде CD.

Испытания

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

В одной компании, в которой я работал, скользящее окно необработанных данных равнялось примерно 6 месяцам и потребляло 10 ТБ. Затем данные были обработаны в формате RDBMS, который стоил 6 ТБ полезных данных, на которые приходилось около 10 лет отчетных данных. Дело в том, что в масштабе эти виды практики просто не практичны. Хранение дорого - вероятно, самый большой вычислительный расход. Это создает несколько интересных проблем:

1. Резервное копирование - плагины innodb великолепны и все такое, но время резервного копирования для такого большого количества данных просто не такое практичное
2. Время восстановления - для больших наборов данных - особенно если вам нужна репликация, чтобы наверстать упущенное после восстановления, возвращение в рабочее состояние может занять дни или даже недели
3. Создание / заполнение новых экземпляров. Часто работа, которую вы можете выполнять в dev / test, включает в себя задания ETL (извлечение, преобразование и загрузка) в вашем наборе данных. Они должны быть проверены с использованием единиц тестирования QA, но это должно быть сделано неразрушающим способом, чтобы сохранить исходный набор производственных данных. В случае аварии вы можете быть готовы к длительному восстановлению, понимая, что резервные копии являются страховым полисом, и цель состоит в том, чтобы их избежать, рабочий процесс разработки DevOps требует, чтобы, по сути, вы могли выполнять восстановление или копия ваших данных на регулярной основе (возможно, несколько раз в день)
4. Емкость - перебор такого большого количества данных в масштабе, который я только что описал, может быть очень интенсивным вводом / выводом. Вам нужно не только решать проблемы, описанные в 1-3, но и делать это таким образом, чтобы не вызывать перебои или снижение производительности ваших производственных систем.

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

Определение требований

В результате вам необходимо определить несколько требований:

1. RTO - RTO или Restore Time Objective для резервного копирования являются одним из наиболее важных драйверов решений для резервного копирования баз данных. Хотя вначале это может показаться не относящимся к большинству других проблем, оно становится чрезвычайно актуальным, когда вы спрашиваете: «Что если бы я использовал свое решение для резервного копирования для создания или заполнения новых экземпляров?». Я расскажу о некоторых приемах для этого в следующем разделе.
2. RPO - RPO или Respoint Point Objective для резервных копий определяет A) насколько далеко вы можете восстановить (минуты, часы, дни, недели, месяцы или годы) B) Интервал резервного копирования на разных уровнях и C) насколько детально вы можете восстановить , Например, для баз данных электронной почты часто запрашиваются резервные копии на уровне сообщений - восстановление определенной электронной почты. Точно так же вы можете обнаружить, что данные за несколько дней совершенно бесполезны - поэтому нет смысла восстанавливать данные год назад.
3. Размер вашего набора данных - это важно, потому что для базы данных объемом 1 МБ ваш RTO может быть достигнут с помощью большинства продуктов и решений для резервного копирования. Однако для базы данных объемом 10 ТБ вы обнаружите, что полное резервное копирование на уровне строк на ленту LTO 3, вероятно , не достигнет вашего RTO и может помешать вашему RPO, поскольку резервные копии начинают превышать окно резервного копирования. Вы не можете просто выполнить mysqldump для этого большого набора данных, но, вероятно, можете избежать проблем с базой данных размером 1 МБ.
4. Согласованность базы данных . Последнее, что имеет огромное значение для непрерывного развертывания, надежности сайта, масштабируемости и высокой доступности при работе с базами данных, - это ваша потребность (или ее отсутствие) в согласованности. Существует три основных типа: немедленная согласованность, согласованность Just-In-Time (JIT) и возможная согласованность

В дополнение к вышеперечисленным основным соображениям, вам также необходимо учитывать требования к лицензированию и поддержке (с открытым исходным кодом или с закрытым исходным кодом; при внутренней поддержке, поддержке третьих сторон или поддержке поставщика) требования к приложению / языку (могут быть важны соединители для многих баз данных; ваше приложение скомпилировано? У вас есть доступ к исходному коду? Можете ли вы перекомпилировать его или оно предоставлено поставщиком? Или оно работает на интерпретируемом языке?) Политические требования (доверяет ли ваша организация только Oracle? Они ненавидят оракула? «Неужели они не доверяют MySql? Как вы относитесь к MariaDB или Postgres?» И к движку базы данных (innoDB? MyISAM? Blackhole? NDB Cluster? Spider?) И историческим требованиям или требованиям совместимости (мы использовали PL / SQL годами и половину нашего кода встроен в движок оракула! Как мы можем портировать на MariaDB?!?)

Все эти вещи (значительно) влияют на доступные вам инструменты.

Некоторые варианты внутреннего управления данными

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

Принимая во внимание общие соображения, позвольте мне рассказать вам о некоторых методах и технологиях для решения вышеуказанных задач. Во-первых, спросите себя, действительно ли вам нужно использовать RDBMS или есть вариант неструктурированных данных с чем-то вроде Hadoop, CouchDB или даже объектно-ориентированным хранилищем (что-то вроде swift).

Во-вторых, подумайте о поиске решения на основе облака. Это передает часть этой головной боли и оставляет сложные проблемы высококвалифицированным (и оплачиваемым) людям. В масштабе, однако, вы можете обнаружить, что это действительно съедает ваш бюджет (облачные провайдеры действительно получают прибыль от этого, и в определенном масштабе вы можете просто позволить себе нанять этих экспертов самостоятельно), или если вы работаете в рамках конкретной системы безопасности или политики требования (читай: мы не можем делать облака) рассмотрим гибридный NFS / FibreChannel Filer. Большинство из этих файловых файлов, таких как NetApp, Pure Storage и Tegile, поддерживают технологию моментальных снимков и клонирования на основе дельты, которая может быть очень полезна для A) создания резервных копий, B) восстановления резервных копий и C) заполнения новых резервных копий.

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

Но , как говорится, эти продукты позволяют вам делать дифференциальные снимки под вашей базой данных. Вам нужно будет написать полный сценарий «блокировки таблиц с блокировкой чтения» на одном из ваших экземпляров базы данных (рекомендуется только ведомое устройство только для чтения) и вывести свою позицию в binlog или GTID, но для этих файловщиков, как только вы это сделаете, вы сможете использовать эти снимки для создания новых экземпляров вашей базы данных. Вы захотите поместить binlogs в отдельный раздел и поместить только данные своей базы данных в эти разделы. Как только вы это сделаете, вы сможете клонировать эти разделы (в NetApps это называется « FlexClone »).

Это связано с тем, что для каждого считанного блока файлировщик должен определить, находятся ли данные в замороженном исходном снимке или в дельте. Для томов / хранилищ с несколькими моментальными снимками это может потребоваться проверить несколько раз. Вы можете преодолеть это путем обновления данных (то есть, отбрасывать свой снимок и периодически клонировать его - что может быть естественно и органично для хорошей среды непрерывного развертывания) или путем постоянного разделения тома (известного как «Flex Split» в терминологии NetApp ), что займет некоторое время, чтобы окончательно разрешить дельты и создать совершенно новый и отдельный том.

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

Единственная хитрость здесь заключается в том, что это не может быть полным решением для резервного копирования, так как «резервная копия» все еще находится на вашем файловом сервере. Для этого вам может потребоваться использовать что-то, что NetApp называет Snap Mirror, который будет зеркалировать данные (используя технологию rsync-стиля) между файловыми системами и даже центрами обработки данных, или использовать какой-либо тип интегрированного решения для резервного копирования, которое может выполнять резервное копирование на ленту одного из ваших дельта-снимков или Flex-клон.

Это, однако, имеет один существенный недостаток: все ваши данные - dev, test и prod все еще используют ввод / вывод на одном и том же файловом устройстве и головке хранилища. Чтобы обойти эту проблему, рассмотрите возможность создания экземпляра подчиненной базы данных на втором файлере, который может быть отправной точкой для вашего Test и / или dev filer, или рассмотрите возможность использования контроллера доставки балансировки нагрузки / приложения для вашего прикладного уровня для зеркалирования производственных запросов в ваш среда тестирования (и / или разработчик). Это дает дополнительное преимущество, заключающееся в том, что в вашу среду QA / Test добавляется трафик prodcution, прежде чем переходить в рабочую среду для устранения проблем, которые могут быть незамедлительно замечены. Затем вы можете проверить свои журналы на наличие ошибок на основе производственного трафика и поведения пользователя.

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

Масштабируемость и высокая доступность

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

Я упомянул, JIT, немедленную и возможную последовательность. Вот тут-то и вступают различные движки СУБД. Конечная согласованность относительно проста, если просто настроить циклическую асинхронную репликацию. Однако это может вызвать некоторые коллизии * (что если ваш прикладной уровень обновляет данные на одной стороне кластера и на другой стороне кластера до завершения репликации?) Для немедленной согласованности посмотрите на кластер Galera, который вызовет синхронную репликацию, но вызывает проблемы с масштабируемостью (как вы будете выполнять репликацию на свой сайт аварийного восстановления или географически балансировать нагрузку без значительных задержек из-за задержки распространения на сетевом уровне?). Вы также можете посмотреть, можете ли вы выполнять синхронную репликацию в центре данных и асинхронную репликацию между сайтами, но это кажется худшим из обоих миров.

Однако, как правило, большинству людей не требуется полностью синхронная репликация - это обычно требуется только для очень специфических (и экзотических) сред с высокой записью, где требуется многоузловая обработка с разбиением таблицы. Большинство приложений могут работать с согласованностью Just-In-Time, используя прокси-сервер базы данных. Например, ScaleArc будет отслеживать состояние репликации и отслеживать, куда только что были отправлены записи (отправлять последующие запросы на чтение до тех пор, пока репликация не перехватит), чтобы обеспечить согласованность и внешний вид Just-In-Time.согласованности базы данных. ScaleArc совместим с Postgres, MySQL, MariaDB, Oracle и MSSQL и может использовать регулярные выражения для разбиения / разделения ваших баз данных для приложений, которые не могут использовать ключи разбиения. Он также имеет надежный REST API для взаимодействия с вашим программным обеспечением для управления конфигурацией, и его команда поддержки выдающаяся

Точно так же вы можете рассмотреть возможность бесплатной альтернативы, MaxScale, разработанной командой MariaDB для MariaDB. Однако ему не хватает графического интерфейса и некоторых функций кеширования ScaleArc.

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

Postgres и Oracle должны иметь необходимые вам функции репликации и разделения, но ScaleArc будет хорошо работать, если вам нужен прокси.

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

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

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

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

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

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

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

Мы используем ликвидазу на нашей работе, и я буду очень признателен за это. Он также используется нашим инструментом обеспечения качества QASymphony .

Мы используем его для внутренних баз данных MSSQL и Oracle, а QASymphony использует / использовал его с обоими экземплярами postgres + mysql.

Чтобы ответить на этот вопрос в контексте среды мэйнфреймов и, в частности, для баз данных DB2, обычно есть 2 часто используемых (не дешевых ...) варианта на выбор:

• Администрирование объектов для DB2® , от BMC. Вот некоторые подробности об этом (цитата со связанной страницы):

  Внесение изменений в объекты в вашей базе данных - или даже просто выполнение рутинных административных задач - может быть сложной, рискованной работой. Есть десятки задач, которые нужно отслеживать, и одна ошибка может иметь катастрофические последствия для доступности и целостности данных. BMC Object Administration для DB2 11 - это набор инструментов, которые помогут вам сократить затраты и риски.

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

• Инструмент администратора DB2 для z / OS , от IBM.

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

  • Позволяет пользователям быстро и легко перемещаться по каталогу DB2.
  • Создает и выполняет динамические операторы SQL, не зная точного синтаксиса SQL
  • Управляет и отслеживает изменения, внесенные в определения объектов DB2, разрешая любые потенциальные конфликты перед выполнением
  • Помогает создавать команды DB2 для выполнения с базами данных и таблицами
  • Позволяет пользователям создавать, изменять, переносить, удалять и перепроектировать объекты DB2
  • Создает и выполняет служебные задания, позволяя пользователям использовать преимущества LISTDEF и TEMPLATE для повышения производительности.

Интеграция с инструментами SCM

Некоторое время назад заказчик предложил мне «интегрировать» альтернативу BMC в их жизненный цикл SCM (под управлением SERENA ChangeMan ZMF ). Идея, лежащая в основе такой интеграции, заключается в следующем: « Рассмотрим нашу DBA-команду DB2 (работающую с DDL) как особый случай команды разработчиков, случайно использующей какой-то экзотический редактор (инструмент BMC) для создания кода (DDL), который нужно перенести ».

Единственной (но реальной !) Проблемой этой интеграции было также содействие «перезапуску», что является одним из ключевых преимуществ такого инструмента DBA:

• Перезапускаемость означает, что когда этот инструмент DBA делает свое дело (иногда через длительные задания, в зависимости от характера выполняемой работы), могут происходить непредвиденные ситуации (взаимоблокировки, прерывания по времени и т. Д.).

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

• Еще лучше (или я должен сказать «еще хуже»?), Если новичок в инструменте DBA не знает, как перезапустить с такой контрольной точки, и просто пытается снова (с самого начала), тогда инструмент DBA просто потерпит неудачу с какой-то ошибкой пользователя. И это с указанием на что-то вроде: « Пока вы не скажете мне, как вы хотите, чтобы я поступил после моей последней точки отказа, я отказываюсь что-либо делать (чтобы не сделать вещи еще хуже) ».

• В конце концов, реальная подсказка для реализации этого перезапуска в используемом инструменте SCM потребовала также настройки инструмента SCM. Фактически, чтобы позволить его использовать для перезапуска неудачных процедур SCM (как правило, связанных с доставкой в ​​целевые среды тестирования / разработки) ... вместо того, чтобы просто повторно передавать неудачную процедуру SCM (как обычно эти инструменты SCM восстанавливаются из таких ситуаций). ).

Бонус: после завершения SCM-интеграции альтернативы BMC заказчик решил сменить инструмент DBA на альтернативу IBM. И хотя обе альтернативы на самом деле не выглядят одинаково, влияние этого на интеграцию SCM было довольно минимальным: просто вопрос замены (в некоторых многоразовых настройках SCM) некоторых обращений к альтернативе BMC эквивалентными обращениями к IBM альтернатива ... которая (используя терминологию DevOps) была реализована с помощью feature-flags / feature-toggles .