Покритикуйте мою многосерверную модель хранения данных

fooler

Новичок
Покритикуйте мою многосерверную модель хранения данных

Добрый день

Проблема такая.
Имеем таблицу из которой постоянно идёт много много запросов на чтение (более ста в секунду) и гораздо меньше (на 2-3 порядка) запросов на удаление/добавление/изменение.
Имею проблему чтения записи - постоянные локи и зависание.
Нашёл в интернете различные решения и советы. Остановится решил на репликации.
Получил в распоряжение физически ещё один сервер.Внутри датацентра связал из дополнительно сетевушками напрямую.

На первом сервере запускаю Mysql как мастер сервер.
На втором стоит www сервер и запущено две версии mysql, оба как слейвы.
Запись произвожу на мастер (в архитектуре приложения это возможно реализовать в моём случае).
Поясню зачем мне нужно две версии mysql на втором сервере. После изучения методов репликации выяснилось что и Statement-Based Replication (SBR) и Row-Based Replication (RBR) по большому счёту могут тоже вызывать проблемы блокировок при активном чтении слейва, хотя SBR и выигрывает значительно в этом плане.
Поэтому я решил настроить своё приложение чтобы чтение шло с одного экземпляра mysql слейва, а репликация в этот момент происходила на другой mysql слейв. Если процесс скажем переключать раз в 15 минут, то единственная проблема это неактуальность данных на 15 минут на слейве который мы читаем (в моём случае это не принципиально).
Главное, что будет решено в такой схеме это полное исключение одновременной записи и чтения в какую-либо из таблиц слейва какими-либо методами.

Если есть замечания/советы - с удовольствием выслушаю
Спасибо
 

С.

Продвинутый новичок
Скорее всего обычная запись с отсрочкой даст тот же результат, но несравнимо проще и дешевле.
 

korchasa

LIMB infected
Как-то цифра в 100+ не внушает. Как определил, что проблема в локах? Тип таблицы MyISAM?
 

440hz

php.ru
fooler
перейди на InnoDB ?

-~{}~ 30.06.10 00:41:

Имеем таблицу из которой постоянно идёт много много запросов на чтение (более ста в секунду) и гораздо меньше (на 2-3 порядка) запросов на удаление/добавление/изменение.
Имею проблему чтения записи - постоянные локи и зависание.
размер? тип? поля/ключи?
 

fooler

Новичок
Автор оригинала: С.
Скорее всего обычная запись с отсрочкой даст тот же результат, но несравнимо проще и дешевле.
На данном этапе пожалуй соглашусь.
Но хочется заложить возможность наперёд. Колво запросов в течение полугода планируется удвоить и дальнейший рост, поэтому ищу более надёжные варианты.

-~{}~ 01.07.10 14:18:

Автор оригинала: korchasa
Как-то цифра в 100+ не внушает. Как определил, что проблема в локах? Тип таблицы MyISAM?
show full processlist поглядывал периодически а там видно как появляется болшой запрос например на запись и поехало...
Таблица MyISAM

-~{}~ 01.07.10 14:22:

Спасибо все за комментарии, но хотел бы ещё раз подчеркнуть, что мне было бы интересно услышать критику именно того способа, который я хочу реализовать и описал выше (а не доводы, чтобы отговорить и сделать совсем иначе)
Особенно интересно, если ктото реализовывал подобные схемы, узнать о результатах.
 

dimagolov

Новичок
fooler,
1. google://KISS
2. вместо того, чтобы городить сервера и прочее, переведи таблицы в InnoDB
 

Krishna

Продался Java
InnoDB, а потом рвать на себе волосы, что похерил столько времени на велосипеды.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Автор оригинала: fooler
Спасибо все за комментарии, но хотел бы ещё раз подчеркнуть, что мне было бы интересно услышать критику именно того способа, который я хочу реализовать и описал выше
мало кто хочет обсуждать твой способ есть суп вилкой
 

pilot911

Новичок
способ обычный, кроме 15ти минутных переключений - они тут ни к чему
 

fooler

Новичок
всё понял. ещё раз спасибо за коменты.
пойду менять вилку на ложку )
 
Сверху