Какова цель движка BLACKHOLE в MySQL?
Зачем вам сохранять то, что вы не можете получить позже? В чем смысл?
3 ответа
Это полезно в реплицируемой среде, где все операторы SQL выполняются на всех узлах, но вы хотите, чтобы только некоторые узлы действительно сохраняли результат. Это пример использования, приведенный в документации: http://dev.mysql.com/doc/refman/5.0/en/blackhole-storage-engine.html
Другие виды использования, приведенные в документации, включают:
- Проверка синтаксиса файла дампа.
- Измерение накладных расходов от двоичного ведения журнала путем сравнения производительности с использованием BLACKHOLE с включенным двоичным ведением журнала и без него.
- BLACKHOLE, по сути, представляет собой механизм хранения "без операций", поэтому его можно использовать для поиска узких мест в производительности, не связанных с самим механизмом хранения.
Предположим, у вас есть два компьютера, на каждом из которых работает сервер MySQL. На одном компьютере размещена основная база данных, а на втором - реплицирующее ведомое устройство, которое вы используете в качестве резервной копии.
Кроме того, предположим, что ваш основной сервер содержит несколько баз данных или таблиц, резервное копирование которых вы не хотите. Возможно, это кеш-таблицы с высоким уровнем оттока, и не имеет значения, если вы потеряете их содержимое. Таким образом, чтобы сэкономить дисковое пространство и избежать ненужного использования ЦП, памяти и дискового ввода-вывода, вы используете параметры репликации, чтобы настроить ведомое устройство на игнорирование операторов, которые влияют на таблицы, резервное копирование которых вы не хотите.
Но поскольку фильтры репликации применяются только на подчиненном сервере, бины для всех операторов, выполняемых на главном сервере, все же необходимо передавать по сети. Здесь пропускная способность тратится впустую; главный сервер отправляет блоки журналов для транзакций, которые ведомый просто отбрасывает при получении. Можем ли мы добиться большего успеха и избежать ненужного использования полосы пропускания?
Да, мы можем, и именно здесь включается движок BLACKHOLE. На том же компьютере, на котором работает главный сервер, мы запускаем второй, фиктивный mysqld процесс, этот хостинг базы данных BLACKHOLE. Мы настраиваем этот фиктивный процесс для репликации из бинарника главного процесса с теми же параметрами репликации, что и у реального ведомого, и для создания собственного бинлога. Binlog процесса-пустышки теперь содержит только те операторы, которые нужны настоящему ведомому, и он не выполнил никакой реальной работы, кроме фильтрации нежелательных операторов из binlog (поскольку он использует механизм BLACKHOLE). Наконец, мы настраиваем истинное ведомое устройство для репликации из бинарника фиктивного процесса, а не из бинарника оригинального главного процесса. Теперь мы устранили ненужный сетевой трафик между двумя компьютерами, на которых размещены главный и подчиненный серверы.
Эта установка - то, что описано и проиллюстрировано (гораздо более кратко) этим параграфом и диаграммой из документов BLACKHOLE:
Предположим, что ваше приложение требует правил фильтрации на ведомой стороне, но передача всех двоичных данных журнала на ведомое устройство сначала приводит к слишком большому трафику. В таком случае на главном хосте можно настроить "фиктивный" подчиненный процесс, чей механизм хранения по умолчанию - BLACKHOLE, изображенный следующим образом:
Помимо фильтрации, документы также загадочно намекают на то, что использование сервера BLACKHOLE с включенным ведением блогов "может быть полезным в качестве механизма повторителя...". Этот вариант использования менее подробно описан в документации, но можно представить сценарий, в котором это имело бы смысл. Например, предположим, что у вас есть много подчиненных серверов, все на компьютерах в локальной сети с быстрыми локальными соединениями друг с другом, которые должны реплицировать большие объемы данных с удаленного ведомого устройства, к которому можно подключиться только через Интернет. Вы не хотите, чтобы все они реплицировались непосредственно из главного блока, поскольку с тех пор вы получаете одни и те же данные несколько раз и используете пропускную способность интернета в несколько раз больше, чем нужно. Но предположим, что вы также не хотите, чтобы только одна из ваших существующих подчиненных копировалась с главного, а другие реплицировались с этого подчиненного, возможно, потому что ваши подчиненные работают на гораздо менее надежных компьютерах, чем мастер, или запускают некоторые другие процессы. это может убить устройство, потребляя весь его процессор или память, и вы не хотите рисковать программным или аппаратным отказом на промежуточном подчиненном устройстве, которое разрушает всю вашу подчиненную сеть. Чем ты занимаешься?
Одним из возможных компромиссов может быть добавление дополнительного блока в вашу подчиненную сеть, который будет выступать в качестве посредника, оптимизированного для надежности и производительности, а не для хранения. Дайте ему небольшой надежный SSD-накопитель и ничего не запускайте на нем, кроме mysqld процесс репликации с удаленного главного устройства, и он должен создавать binlogs, на которые могут подписаться другие ведомые устройства. И, конечно же, настройте этого промежуточного ведомого на использование механизма BLACKHOLE, чтобы ему не требовалось место для хранения.
И этот, и промежуточный фильтрующий ведомый, подробно описанный в документации, являются крайними случаями; большинство пользователей MySQL никогда не окажутся в ситуациях, когда им будет выгодно использовать любую из этих стратегий, не говоря уже о том, чтобы получить достаточную выгоду, чтобы оправдать выполнение работы для их фактической настройки. Но, по крайней мере теоретически, механизм BLACKHOLE можно использовать для создания промежуточного узла в сети реплицирующих ведомых устройств в качестве стратегии сохранения пропускной способности, без необходимости в этом узле для фактического хранения данных на диске.
полезно для запуска триггера по данным, которые вы не хотите сохранять.