Испытания
Я знаю, что существуют практики, такие как добавление только объектов базы данных, то есть таблиц и столбцов, никогда не изменяя и не удаляя их
В одной компании, в которой я работал, скользящее окно необработанных данных равнялось примерно 6 месяцам и потребляло 10 ТБ. Затем данные были обработаны в формате RDBMS, который стоил 6 ТБ полезных данных, на которые приходилось около 10 лет отчетных данных. Дело в том, что в масштабе эти виды практики просто не практичны. Хранение дорого - вероятно, самый большой вычислительный расход. Это создает несколько интересных проблем:
- Резервное копирование - плагины innodb великолепны и все такое, но время резервного копирования для такого большого количества данных просто не такое практичное
- Время восстановления - для больших наборов данных - особенно если вам нужна репликация, чтобы наверстать упущенное после восстановления, возвращение в рабочее состояние может занять дни или даже недели
- Создание / заполнение новых экземпляров. Часто работа, которую вы можете выполнять в dev / test, включает в себя задания ETL (извлечение, преобразование и загрузка) в вашем наборе данных. Они должны быть проверены с использованием единиц тестирования QA, но это должно быть сделано неразрушающим способом, чтобы сохранить исходный набор производственных данных. В случае аварии вы можете быть готовы к длительному восстановлению, понимая, что резервные копии являются страховым полисом, и цель состоит в том, чтобы их избежать, рабочий процесс разработки DevOps требует, чтобы, по сути, вы могли выполнять восстановление или копия ваших данных на регулярной основе (возможно, несколько раз в день)
- Емкость - перебор такого большого количества данных в масштабе, который я только что описал, может быть очень интенсивным вводом / выводом. Вам нужно не только решать проблемы, описанные в 1-3, но и делать это таким образом, чтобы не вызывать перебои или снижение производительности ваших производственных систем.
Хотя приведенные выше соображения могут не вызывать беспокойства в более мелких масштабах, в более крупных масштабах они становятся огромными проблемами. Это означает, что крайне важно, чтобы вы определили свои требования и прогнозировали размер вашего набора данных.
Определение требований
В результате вам необходимо определить несколько требований:
- RTO - RTO или Restore Time Objective для резервного копирования являются одним из наиболее важных драйверов решений для резервного копирования баз данных. Хотя вначале это может показаться не относящимся к большинству других проблем, оно становится чрезвычайно актуальным, когда вы спрашиваете: «Что если бы я использовал свое решение для резервного копирования для создания или заполнения новых экземпляров?». Я расскажу о некоторых приемах для этого в следующем разделе.
- RPO - RPO или Respoint Point Objective для резервных копий определяет A) насколько далеко вы можете восстановить (минуты, часы, дни, недели, месяцы или годы) B) Интервал резервного копирования на разных уровнях и C) насколько детально вы можете восстановить , Например, для баз данных электронной почты часто запрашиваются резервные копии на уровне сообщений - восстановление определенной электронной почты. Точно так же вы можете обнаружить, что данные за несколько дней совершенно бесполезны - поэтому нет смысла восстанавливать данные год назад.
- Размер вашего набора данных - это важно, потому что для базы данных объемом 1 МБ ваш RTO может быть достигнут с помощью большинства продуктов и решений для резервного копирования. Однако для базы данных объемом 10 ТБ вы обнаружите, что полное резервное копирование на уровне строк на ленту LTO 3, вероятно , не достигнет вашего RTO и может помешать вашему RPO, поскольку резервные копии начинают превышать окно резервного копирования. Вы не можете просто выполнить mysqldump для этого большого набора данных, но, вероятно, можете избежать проблем с базой данных размером 1 МБ.
- Согласованность базы данных . Последнее, что имеет огромное значение для непрерывного развертывания, надежности сайта, масштабируемости и высокой доступности при работе с базами данных, - это ваша потребность (или ее отсутствие) в согласованности. Существует три основных типа: немедленная согласованность, согласованность 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 будет хорошо работать, если вам нужен прокси.
В конечном счете, все эти компоненты в совокупности создают очень гибкую среду, подходящую для непрерывного развертывания и разработки, если вы не можете просто использовать облачную среду и позволить своему облачному провайдеру справиться с вышеуказанными проблемами для вас.