мы хотим настроить сложную инфраструктуру репликации mysql. Идея состоит в том, чтобы иметь 3 клиента, которые обрабатывают запросы от пользователей и настроены как подчиненные в репликации master-slave в mysql. Также есть два сервера, которые настроены как мастер-мастер репликации. Теперь мы хотим использовать эту репликацию мастер-мастер в качестве единственного мастера для 3 подчиненных устройств через балансировщик нагрузки (или прокси). Кто-нибудь уже настраивал подобную конфигурацию? Возможно ли, что два главных сервера имеют разные бинлоги, и это может нарушить репликацию? Система - Debian Lenny с MySQL 5.1.48
Я не знаю решения для того, что вы делаете, поскольку MySQL изначально не поддерживает репликацию подчиненных серверов с нескольких мастеров.
Круговая репликация хрупка и обычно не рекомендуется.
Если ваш главный мастер вышел из строя, который является действующим мастером для всех подчиненных, вы потенциально можете перенаправить их на вторичный мастер. Обычно это включает в себя рыться в журналах, что может быть довольно утомительно и легко сделать ошибку. Вы можете использовать Maatkit's мк-раб-ход утилита, чтобы сделать это немного проще.
Вы могли бы потенциально запустить несколько экземпляров MySQL на каждом ведомом устройстве, а затем иметь логику контрольного сигнала или аварийного переключения, которая могла бы переключаться в случае отказа основного ведущего устройства. Это должно иметь существенную логику, чтобы не быть хрупким.
Вы можете запустить двойное ведущее устройство, иметь ведомое устройство от каждого ведущего устройства, а затем сбалансировать нагрузку на оба ведомых устройства. Обеспечьте проверку доступности в балансировке нагрузки для удаления ведомого устройства в случае сбоя одного ведущего устройства, что, вероятно, будет лучше, чем наличие нескольких ведомых устройств на каждом сервере. Это не будет хорошо масштабироваться.
Якобы это набор скриптов помогает с этим типом конфигурации, но у меня нет опыта с ними.
Если вам нужна высокая доступность для запросов только для чтения, я бы порекомендовал запускать эти более важные запросы на двух главных высокодоступных серверах. Для запросов, которые не обязательно должны выполняться в реальном времени, имеет смысл запустить их против нескольких ведомых устройств с балансировкой нагрузки, которые потенциально могут не иметь текущих данных в случае сбоя ведущего.
Разве не было бы проще сделать их всех мастерами, а затем повторять их по кругу?
С.
После того, как вы установили мастер-мастер с двумя серверами, самая сложная часть сделана. Независимо от того, на какую из двух машин отправляются записи, если они настроены правильно, двоичных журналов на любом из серверов будет достаточно / полно. После этого, просто настроить ведомые устройства на одном из двух мастеров.
Кроме того, вы всегда можете настроить старое ведущее ведомое устройство на двойное ведущее устройство, тогда ведомые устройства будут на 2 уровня ниже по иерархии репликации. Пригодность зависит от допустимой задержки репликации для конечного приложения, но я поклонник двухуровневой репликации (чтобы упростить обслуживание).