Добрый день ! Делаем проект в котором база будет очень сильно грузиться. В будущем дабы избежать торможений хотим разнести веб и mysql сервера по разным физически серверам, и mysql потом раскинуть на несколько серверов. Как я понимаю это будет уже Mysql кластер. А теперь вопрос Какие могут быть проблемы при переносе standalone mysql сервера в кластер. Может на данном этапе при создании проекта надо что-то учесть .. сейчас гуглю, пытаюсь разобраться, но может кто-то с личного жизненного опыта подскажет
Репликацию нужно будет рулить. И лучше это предусмотреть на уровне приложения, т.к. реплики обновляются не мгновенно, значит, после каждого POST надо будет отображать следующий GET именно c мастера, иначе пользователь может подумать, что его изменения не сохранились.
бр ) что нужно чтобы реплики обновлялись почти моментально ? (1-2 сек) в настройках репликации поставить мин. срок для обновления, но во что это упрётся? в производительность серверов? =)
естественно. Какой смысл разводить реплики на несколько серверов, если они будут мгновенно обновлятся? они и положат master своими обновлениями
сечешь тему! Вообще, стоит уточнить, что MySQL кластер и репликация БД - чуть-чуть разные вещи. Если ты подробней опишешь задачу, может и подскажу что нить.
Делаем систему в которой будут храниться все дома, все клиенты, все выписанные счета для предприятия предоставляющего горячую воду и отопления для нашего города (115к людей) php 5 + ajax + mysql 5 на данный момент при генерации счетов (можно генерировать на город, район, дом, подьезд или по владельцу) база кушает много времени. Но проект в тестовом режиме, работает только 1 человек. На продакшн версии будет 27 операторов, хочеться нагрузку разнести как-то ) кеширование счетов есть, но очень много счетов выписываются с индивидуальными флагами, 1 из 5 только берутся из кеша
Тогда нужна именно репликация, а не кластер. А вообще - лучше купить оракл. У нас один сервер обслуживает начисления за телекоммуникации всей области - (3 города: 350к + 100К + 50К, + села по мелочи) 30 касс, + онлайн сервис, + 30 терминалов. Ничего, тянет.
у них столько денег нет, да и мастеров оракла у нас в городе нет ) и проект написан на 90%, оптимизация осталась )
Victor Bazinov Для приложения такого уровня ни кластер, ни репликация нафиг не нужны, нужна хорошая оптимизация и разумное кеширование... ставьте один сервер, а деньги лучше приберегите на оперативную память.
вообще, я бы сделал все же два сервера - это все же, чужие деньги - один mysql + веб, другой или репликой с mysql, или на него писать бинарный лог, что бы с него можно было восстановится. Не к вопросу произодительности, а к отказоустойчивости.
А если сделать три, то можно сделать на мускулах еще и подхват обслуживания вторым сервером, если первый упадет.
хм, MyISAM без транзакций (просто не нужны по логике) а вот насчёт innodb надо подумать.. базу без меня делали :\ и вообще пойду читать про оптимизацию запросов и способы восстановления данных в случае падения сервера :\
Victor Bazinov Если данные обновляются сравнительно редко, а основная задача приложения - генерация отчетов, то MyISAM самый лучший выбор, т.к. он и быстрее, и (имхо) надежнее, и памяти меньше ест. Лучший способ восстановления данных - регулярные бэкапы
Не думаю, что ситуация сильно изменилась в сторону MyISAM. Если не нужен FULLTEXT, то я бы отдал предпочтение InnoDB.
Горбунов Олег Это коммунальные услуги. Там не критично: все набивается по бумажкам и на бумажках же хранится. Впрочем, спорить не буду, хотите вводить транзакции - вводите
приходят данные от жилищных контор и в базу вносятся все показания счётчиков и прочего за месяц, на этой момент много insert + update операций и несколько дней в месяц это генерация всех счетов соответсвенно.. заказчик просил сделать упор на скорость, т.к. сейчас всё это работает на FoxPro + MsSQL2k, и генерация счетов по 1 дому занимает 15-30 минут :\