На сколько я понял приведенное решение предполагает, что Repository будет возвращать AR. Нет понимания как маппить модели в базу и обратно, особенно, если это нужно сделать для агрегата.
Вы проводили эксперименты? Есть авторитетный источник где можно это увидеть? Я тоже предполагаю, что большой разницы не должно быть, но нельзя этого утверждать.
И как влияют при этом на временные таблицы настройки для MyIsam?
Все-таки интересует программное решение. Алгоритмы выборки в haproxy не совсем подходят. Более всего близко балансировка по количеству коннектов, но это не исключает ситуации когда на один слэйв поступит 100 медленных запросов, а на другом будет 100 быстрых. И хочется еще какой-то альтернативы.
Скорее всего это свой велосипед, но все же, может у кого-нибудь есть опыт написания подобного скрипта?
Сейчас я вижу это так: скрипт, который опрашивает каждые 30 сек слейвы и помещает данные(количество коннектов, отставание слейвов, суммарное время уже выполняющихся запросов, количество запросов) о их загруженности в memcache. Перед каждым запросом, выбирать 1 слейв из 5 наименее загруженных рандомно.
Александр Аксентьев: Вопрос в другом.
1) На одном из слейвов я настраиваю HaProxy.
2) В конфиге Yii указываю один слейв, он является слейвом с HaProxy (пункт 1).
Если падает сервер с HaProxy, то падает все, потому что в конфиге только указан slave - proxy.
Если указано несколько слейвов, то если падает один слейв, то остальные могут обслужить запросы.
Если я конечно правильно понял идею с прокси сервером.
Я в конфиге укажу один slave, который будет являться proxy. И уже он будет разруливать запросы, так? Если этот прокси сервер выходит из строя или для него превышен лимит ожидания, то запросы начнут сыпаться к мастеру, что убьет систему в целом.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
