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