Что мы можем сделать в MySQL 5.0 Replication для решения проблем пропускной способности?

Я разрабатываю приложение для запуска на клиентском ПК (Win), которое сконфигурировано с экземпляром MySQL server 5.1, который будет действовать как ведомый только для чтения подчиненный удаленный мастер. Удаленный мастер имеет десятки схем, но мне нужна только одна для каждого клиента, поэтому я предоставляю параметр replication-do-db в my.ini для репликации только той схемы, которая нужна клиенту. Репликация работает, но когда наши клиенты попадают в регионы мира, где доступ в Интернет доступен только через беспроводную связь 3G, которая взимает плату за использование данных, они быстро выходят за пределы своего тарифного плана и сталкиваются с дорогостоящими проблемами.

Насколько я понимаю, MySQL записывает все транзакции для всех схем в один файл binlog, что означает, что каждый клиент должен загрузить все транзакции, которые выполняются в каждой схеме на ведущем устройстве, а затем после загрузки применить фильтр базы данных для каждой репликации. Настройки do-db в клиентском файле my.ini.

Чтобы минимизировать эту неэффективность, я использовал настройку slave_compressed_protocol = 1 , которая, по-видимому, сокращает передаваемые данные на 50%, но все же заставляет наших клиентов быстро превышать свой предел данных, увеличивая счет 3G.

Я не могу себе представить, что я один сталкиваюсь с этим, поэтому я уверен, что получу массу ответов о том, как этого добиться, установив x = y. Тем не менее, я не могу найти ни документацию такого параметра, ни рекомендуемый подход.

Итак, вот моя мысль о возможном решении, пожалуйста, предоставьте обратную связь или альтернативные маршруты:

1. Настройте «прокси-сервер» для каждой схемы (на другом или на том же компьютере с другим экземпляром / портом MySQL)
2. Сконфигурируйте подчиненный прокси-сервер для репликации-do-db только одной базы данных, которую клиенты хотят реплицировать.
3. Сконфигурируйте клиентский экземпляр MySQL как подчиненный для соответствующего прокси-подчиненного.

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

Мысли? Будет ли этот подход даже работать?

Обратите внимание, что мы работаем на сервере MySQL 5.0 в RedHat, но мы можем обновить его до 5.5, если это даст решение.

ПРЕДЛОЖЕНИЕ № 1: Используйте мастера распространения

Мастер распространения - это ведомый MySQL с включенным хранилищем журналов, включенным обновлением подчиненных журналов и содержит только таблицы с механизмом хранения BLACKHOLE . Вы можете применить replicate-do-db к Мастеру распространения и создать двоичные журналы на Мастере распространения, которые содержат только схемы БД, которые вы хотите заблокировать. Таким образом, вы уменьшаете размер исходящих binlogs от мастера распространения.

Вы можете настроить Master Distribution следующим образом:

1. mysqldump вашу базу данных, используя опцию --no-data, чтобы создать дамп только для схемы.
2. Загрузите дамп только для схемы в мастер распространения.
3. Преобразуйте каждую таблицу в мастере распространения в механизм хранения BLACKHOLE.
4. Настройте репликацию на мастер распространения с мастера с реальными данными.
5. Добавьте параметр (-и) replicate-do-db в /etc/my.cnf мастера распространения.

Для шагов 2 и 3 вы также можете отредактировать дамп только для схемы и заменить ENGINE = MyISAM и ENGINE = InnoDB на ENGINE = BLACKHOLE, а затем загрузить этот отредактированный дамп только для схемы в мастер распределения.

Только на шаге 3, если вы хотите создать сценарий преобразования всех таблиц MyISAM и InnoDB в BLACKHOLE в мастере распространения, выполните следующий запрос и выведите его в текстовый файл:

mysql -h... -u... -p... -A --skip-column-names -e"SELECT CONCAT('ALTER TABLE ',table_schema,'.',table_name', ENGINE=BLACKHOLE;') BlackholeConversion FROM information_schema.tables WHERE table_schema NOT IN ('information_schema','mysql') AND engine <> 'BLACKHOLE'" > BlackholeMaker.sql

Дополнительным бонусом к написанию сценариев преобразования таблицы в механизм хранения BLACKHOLE является то, что таблицы механизма хранения MEMORY также преобразуются. Хотя таблица механизма хранения MEMORY не занимает место на диске для хранения данных, она будет занимать память. Преобразование таблиц MEMORY в BLACKHOLE сохранит память в мастере распространения незагроможденной.

Пока вы не отправляете DDL в мастер распространения, вы можете передавать любой DML (INSERT, UPDATE, DELETE), который вы пожелаете, прежде чем позволить клиентам реплицировать только ту информацию БД, которую они хотят.

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

ПРЕДЛОЖЕНИЕ № 2: Используйте меньшие двоичные журналы и журналы реле

Если вы установите для max_binlog_size что-то смехотворно маленькое, то бины могут быть собраны и отправлены небольшими порциями. Существует также отдельная опция для установки размера релейных журналов, max_relay_log_size . Если max_relay_log_size = 0, по умолчанию будет установлено значение max_binlog_size.

ПРЕДЛОЖЕНИЕ № 3: Использовать полусинхронную репликацию (только MySQL 5.5)

Настройте основную базу данных и несколько мастеров распространения как MySQL 5.5. Включите полусинхронную репликацию, чтобы основная база данных могла быстро отправлять журналы блогов в мастер распространения. Если ВСЕ ваши ведомые устройства являются Мастерами распространения, вам может не понадобиться полусинхронная репликация или MySQL 5.5. Если какой-либо из ведомых, кроме Мастеров распространения, имеет реальные данные для создания отчетов, обеспечения высокой доступности, пассивного ожидания или резервного копирования, тогда используйте MySQL 5.5 вместе с полусинхронной репликацией.

ПРЕДЛОЖЕНИЕ № 4: Используйте двоичное ведение журнала на основе операторов, а не на основе строк

Если оператор SQL обновляет несколько строк в таблице, двоичное ведение журнала на основе операторов (SBBL) сохраняет только оператор SQL. Тот же оператор SQL, использующий двоичное ведение журнала на основе строк (RBBL), будет фактически записывать изменение строки для каждой строки. Это делает очевидным, что передача операторов SQL сэкономит место в двоичных журналах, выполняющих SBBL через RBBL.

Другая проблема заключается в использовании RBBL в сочетании с replicate-do-db, где к имени таблицы добавляется база данных . Это не может быть хорошо для раба, особенно для Мастера Распределения. Поэтому убедитесь, что у всех DML нет базы данных и точки перед именами таблиц.

Значение max_binlog_size должно быть неактуальным - данные бинлога передаются непрерывно.

Предупреждение о «Мастере распространения» - это «единая точка отказа». То есть, если он умирает, все ведомые (ие) за ним не будут получать данные, и перестройка реле будет работать.

SBR против RBR - это зависит от запроса. Любой может быть лучше или хуже другого.

Разместите Мастеров Распределения на той же машине, что и настоящий Мастер, или на машине "рядом" с Мастером. Используйте отдельные порты для разделения экземпляров.