Какова цель MySQL BLACKHOLE Engine?

Ответ 1

Это полезно в реплицируемой среде, где все операторы SQL выполняются на всех узлах, но вы хотите, чтобы только некоторые узлы действительно сохраняли результат. Это пример использования, приведенный в документации: http://dev.mysql.com/doc/refman/5.0/en/blackhole-storage-engine.html

Другие виды использования, приведенные в документации, включают:

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

Ответ 2

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

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

Но поскольку фильтры репликации применяются только к подчиненному серверу, бинговые файлы для всех операторов, выполняемых на главном сервере, все равно должны передаваться по сети. Здесь пропускная способность тратится впустую; главный сервер отправляет binlogs для транзакций, которые ведомый просто собирается выбросить при их получении. Можем ли мы сделать лучше и избежать ненужного использования полосы пропускания?

Да, мы можем и там, где работает движок BLACKHOLE. На том же компьютере, на котором работает главный сервер, мы запускаем второй, фиктивный mysqld процесс, на котором размещается база данных BLACKHOLE. Мы настраиваем этот фиктивный процесс для репликации из основного журнала bin, с теми же параметрами репликации, что и реальный подчиненный, и для создания собственного бинарного журнала. В фиктивном процессе binlog теперь содержатся только те утверждения, которые необходимы реальному подчиненному, и он не выполнял никакой реальной работы, кроме того, что отфильтровывал нежелательные утверждения из binlog (поскольку он использует движок BLACKHOLE). Наконец, мы настраиваем истинное подчиненное устройство для репликации из фиктивного процесса binlog, а не из исходного исходного журнала bin. Теперь мы устранили ненужный сетевой трафик между двумя компьютерами, на которых размещены ведущий и ведомый серверы.

Эта настройка - это то, что описано и проиллюстрировано (гораздо более кратко) этим абзацем и диаграммой из документов BLACKHOLE:

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

Помимо фильтрации, документы также загадочно намекают, что использование сервера BLACKHOLE с включенным бингингам "может быть полезным как механизм повторителя...". Этот вариант использования меньше в документах, но можно представить себе сценарий, в котором это имеет смысл. Например, предположим, что у вас много подчиненных серверов, все на компьютерах в локальной сети с быстрым локальным подключением друг к другу, что все они должны реплицировать большие объемы данных с удаленного подчиненного устройства, которое может быть подключено только через Интернет. Вы не хотите, чтобы все они реплицировались непосредственно из главного окна, так как тогда вы получаете одни и те же данные несколько раз и используете в несколько раз больше пропускной способности Интернета, чем вам нужно. Но предположим, что вы также не хотите, чтобы только один из ваших существующих подчиненных реплицировал от ведущего, а остальные реплицировали это подчиненное устройство, возможно, потому, что ваши подчиненные работают на гораздо менее надежных машинах, чем мастер, или запускают некоторые другие процессы который может убить коробку, съедая весь ее процессор или память, и вы не хотите рисковать программным или аппаратным сбоем на промежуточном ведомом, снимающем всю вашу рабочую сеть. Что вы делаете?

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

Как это, так и промежуточное подчиненное подчинение, подробно описанное в документации, являются краевыми случаями; большинство пользователей MySQL никогда не найдут себя в ситуациях, когда им будет выгодно использовать любую из этих стратегий, не говоря уже о том, чтобы оправдать выполнение работы, чтобы фактически настроить их. Но, по крайней мере теоретически, движок BLACKHOLE можно использовать для создания промежуточного node в сети реплицируемых ведомых в качестве стратегии сохранения полосы пропускания, без необходимости node фактически хранить данные на диске.

Ответ 3

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