Предположим, у вас есть два компьютера, на каждом из которых работает сервер MySQL.На одном компьютере размещена первичная база данных, а на втором - реплицирующее ведомое устройство , которое вы используете в качестве резервной копии.
Кроме того, предположим, что ваш первичный сервер содержит некоторые базы данных или таблицы, которые вы не используете.хочу сделать резервную копию.Возможно, они представляют собой таблицы с высоким уровнем оттока, и не имеет значения, если вы потеряете их содержимое.Таким образом, чтобы сэкономить дисковое пространство и избежать ненужного использования ЦП, памяти и дискового ввода-вывода, вы используете параметры репликации , чтобы настроить ведомое устройство на игнорирование операторов, которые влияют на таблицы, резервное копирование которых вы не хотите.
Но поскольку фильтры репликации применяются только на подчиненном сервере , бины для операторов all , выполняемых на главном сервере, все же необходимо передавать по сети.Здесь пропускная способность тратится впустую;главный сервер отправляет блоки журналов для транзакций, которые ведомый просто отбрасывает при получении.Можем ли мы добиться большего успеха и избежать ненужного использования пропускной способности?
Да, мы можем, и именно здесь включается движок BLACKHOLE. На том же компьютере , на котором работает главный сервер,мы запускаем второй, фиктивный mysqld процесс, на котором размещена база данных BLACKHOLE.Мы настраиваем этот фиктивный процесс для репликации из бинарника главного процесса с теми же параметрами репликации, что и у реального ведомого, и для создания собственного бинлога.Binlog процесса-пустышки теперь содержит только те операторы, которые нужны настоящему ведомому, и он не выполнил никакой реальной работы, кроме фильтрации нежелательных операторов из binlog (поскольку он использует механизм BLACKHOLE).Наконец, мы настраиваем истинное ведомое устройство для репликации из бинарника фиктивного процесса, а не из бинарника оригинального главного процесса.Теперь мы устранили ненужный сетевой трафик между двумя компьютерами, на которых размещены главный и подчиненный серверы.
Эта настройка описана и проиллюстрирована (гораздо более кратко) в этом параграфе и на диаграмме из ЧЕРНОЙ ДЫРЫdocs :
Предположим, что ваше приложение требует правил фильтрации на ведомой стороне, но передача всех двоичных данных журнала на ведомое устройство сначала приводит к слишком большому трафику.В таком случае на главном хосте можно настроить «фиктивный» подчиненный процесс, чей механизм хранения по умолчанию - BLACKHOLE, изображенный следующим образом:
Помимо фильтрации, документы также загадочно намекают на то, что использование сервера BLACKHOLE с включенным ведением блогов "может быть полезным в качестве механизма повторителя ..." 1034 *.Этот вариант использования менее подробно описан в документации, но можно представить сценарий, в котором это имело бы смысл.Например, предположим, что у вас есть много подчиненных серверов, все на компьютерах в локальной сети с быстрыми локальными соединениями друг с другом, которые должны реплицировать большие объемы данных с удаленного ведомого устройства, к которому можно подключиться только через Интернет.Вы не хотите, чтобы все они реплицировались непосредственно из главного блока, поскольку с тех пор вы получаете одни и те же данные несколько раз и используете пропускную способность интернета в несколько раз больше, чем нужно.Но предположим, что вы также не хотите, чтобы только один из ваших существующих рабов копировал данные с ведущего устройства, а другие - с этого ведомого, возможно, потому что ваши подчиненные работают на гораздо менее надежных машинах, чем мастер,или запускают некоторые другие процессы, которые могут уничтожить блок, потребляя весь его ЦП или память, и вы не хотите рисковать программным или аппаратным отказом на промежуточном подчиненном устройстве, что приведет к отключению всей вашей подчиненной сети.Что ты делаешь?
Одним из возможных компромиссов может быть добавление дополнительного блока в вашу подчиненную сеть, который будет выступать в роли посредника, оптимизированного для надежности и производительности, а не для хранения данных. Дайте ему небольшой надежный SSD-накопитель и ничего не запускайте на нем, кроме процесса mysqld, реплицируемого с удаленного главного устройства, и пусть он создает бины, на которые могут подписаться другие ведомые устройства. И, конечно же, настройте этого промежуточного ведомого на использование механизма BLACKHOLE, чтобы ему не требовалось место для хранения.
И этот, и промежуточный фильтрующий ведомый, подробно описанный в документации, являются крайними случаями; большинство пользователей MySQL никогда не окажутся в ситуациях, когда им будет выгодно использовать любую из этих стратегий, не говоря уже о том, чтобы получить достаточную выгоду, чтобы оправдать выполнение работы для их фактической настройки. Но, по крайней мере теоретически, механизм BLACKHOLE можно использовать для создания промежуточного узла в сети реплицирующих ведомых устройств в качестве стратегии сохранения пропускной способности, при этом этому узлу не требуется фактически хранить данные на диске.