Что мы можем сделать в репликации MySQL 5.0 для решения проблем с пропускной способностью?
Я разрабатываю приложение для запуска на клиентском ПК (Win), которое настроено с экземпляром сервера MySQL 5.1, который будет действовать как подчиненный только для чтения удаленному мастеру. У удаленного мастера есть десятки схем, но мне нужна только одна для каждого клиента, поэтому я предоставляю параметр replication-do-db в моем. ini, чтобы реплицировать только ту схему, которая нужна клиенту. Репликация работает, но когда наши клиенты попадают в регионы мира, где доступ в Интернет доступен только через беспроводную сеть 3G, которая взимает плату за использование данных, они быстро превышают ограничения своего тарифного плана и сталкиваются с дорогостоящими проблемами.
Насколько я понимаю, MySQL записывает все транзакции для всех схем в один файл binlog, что означает, что каждый клиент должен загрузить все транзакции, которые выполняются для каждой схемы на главном сервере, а затем после загрузки применить фильтр базы данных согласно настройкам replication-do-db в клиентском файле my.ini.
Чтобы минимизировать эту неэффективность, я использовал настройку slave_compressed_protocol = 1 , которая, кажется, уменьшает передаваемые данные на 50%, но все же вызывает у нашего клиента s, чтобы быстро превысить свой лимит данных, увеличив счет за 3G.
Я не могу представить, что я единственный, кто сталкивается с этим, поэтому я уверен, что получу массу ответов о том, как этого добиться, установив х = у. Однако я не могу найти ни документации по такой настройке, ни рекомендуемого подхода.
Итак, вот моя мысль о возможном решении, пожалуйста, предоставьте обратную связь или альтернативные маршруты:
- Настройте «прокси-сервер» для каждой схемы (на другом устройстве или в том же самом устройстве с другим экземпляром / портом MySQL)
- Настройте ведомый прокси-сервер для репликации-do-db только той базы данных, которую клиенты хотят реплицировать.
- Настройте экземпляр MySQL клиента в качестве ведомого устройства для соответствующего ведомого устройства-посредника.
Это должно ] приводит к тому, что клиент извлекает только данные бинарного журнала для своей схемы. Обратной стороной (насколько я могу судить) является то, что это резко увеличивает сложность нашей установки, вероятно, делая ее более хрупкой.
Мысли? Будет ли этот подход работать?
Обратите внимание, мы запускаем сервер MySQL 5.0 на RedHat, но мы можем обновить его до 5.5, если он даст решение.