опять сложная репликация

[Лысый]

опять сложная репликация

продолжаю разбираться с репликациями дабы снижать нагрузки и сделать систему стабильнее

задача такова
есть более десятка сайтов
надо сделать некую таблицу tbl
1) постоянно доступной для всех сайтов на чтение
2) все сайты туда пишут, надо чтоб записи достаточно быстро обналялись на всех копиях таблицы (если они есть)

есть два варианта решения

1) сделать мастер с главной копией этой таблицы, куда все сайты по сокету делают Insertы и другие обновления, и несколько слевов откуда все сайты тоже по сокету читают

плюсы: легко настроить, быстро реплицируется
минусы - разражает необходимость держать сокеты и в случае взлома или ошибки, команда TRANCATE или просто падение мастера, завалит всю систему

2) сделать для каждого сайта по одной таблице (tbl1, tbl2, tbl3 и тд) а на остальных сайтах реплицируемые копии этих таблиц
таким образом каждый сайт будет писать только в свою таблицу, на своем же хосте, а не через сокет, копии которых будут обновляться на всех остальных сайтах
каждый сайт будет читать со своих копий таблиц на своём же хосте
запросы делаются через union всех копий таблиц

плюсы: падение не грозит вообще. сайты смогут работать даже автономно, но только в рамках своих данных.
чтение идёт со своего же хоста, а не по сокету - нагрузки совсем не те

минусы : не уверен что такая сложная система сможет стабильно работать


хочу услышать конструктивную критику или какие то советы/предложения

всем спасибо.

 

[akd]

почитай последний http://phpinside.ru, думаю поможет.

 

[Апельсин]

akd, там та же статья которую ему уже давали на прочтение о репликации, но только на русском.

 

[Лысый]

спасибо уже разобрался

как никак 2 недели прошло

 

[grigori]

Автор оригинала: Лысый
спасибо уже разобрался

Буду благодарен за рассказ о том, как именно и почему именно так

-~{}~ 31.07.06 20:56:

Автор оригинала: Апельсин
akd, там та же статья которую ему уже давали на прочтение о репликации, но только на русском.

Просмотрел последние страницы форума - нет подобных тем.
Дайте ссылку еще раз, плиз.

 

[akd]

grigori, в статье все разжевано, обращай внимание на автоинкремент.

 

[Лысый]

grigori
вобщем итог такой:
для проектов с нагрузкой несколько сот тысяч хостов в день

1) вариант но только с кучей мер предостарожности на случай взлома и быстрым каналом между клиентами и слеейвами

2) сомнительный вариант. на практике оказалось репликация сильно не поспевает за юзерами


общий вывод - такие сложные системы репликации конечно целесообразны в очень сложных системах. но при условии сравнительно низкой востребованости, или хотя бы при редком измнении данных (использование только на чтение) - иначе тормоза, рассинхронизация и тд

 

[grigori]

Лысый:
Я так понимаю, между мастером и слейвом должен быть гигабитный ethernet, как разработчики MySQL рекоммендуют,
сами сервера должны быть в локалке без прямого доступа из инета, на них можно через DMZ заходить.

А при 1м варианте (с единым мастером) - слейвы успевают с репликацией?


akd: в PHPi статью прочел, но самое ценное там - коммент Young-a.
А как на PHP в слое работы с БД реализовать обход падения мастера - думайте сами )

 

[MadMike]

grigori
Репликация через инет вполне нормально работает, проверено

 

[akd]

grigori, вопроса о том как на пхп обойти падение мастера я не видел (правда я не совсем понимаю, зачем это делать на пхп, ввиду наличия описаных возможностей ... но вам виднее).

отвечал я относительно изначального вопроса tbl1, tbl2, .... tblx.

 

[Лысый]

Автор оригинала: grigori
Лысый:
Я так понимаю, между мастером и слейвом должен быть гигабитный ethernet, как разработчики MySQL рекоммендуют,
сами сервера должны быть в локалке без прямого доступа из инета, на них можно через DMZ заходить.

А при 1м варианте (с единым мастером) - слейвы успевают с репликацией?

ну гигабитный ethernet необходимое условие, а не достаточное

дело в том, что обычно тормоза не из за инета а из-за самого мускула. если пишешь систему реального времени лучше не расчитвывать на то, что репликация будет успевать за действиями юзера

 

[grigori]

Думаю, если делать систему, в которой важна целостность и синхронность, надо брать Postgres и делать промежуточные коммиты.
А в случае использования MySQL можно сделать задержку при редиректе после POST-a, который изменяет записи в базе.

Если можешь, дай статистику - на каких нагрузках какое время синхронизации.

Какая часть системы тормозит MYSQL - проц или винт?

 

[Апельсин]

> в которой важна целостность и синхронность

кластер ... только раньше чем 5.1 его лучше не смотреть, а 5.1 еще бета.

 

[grigori]

Только 5.1 в любом случае и смотрю - планирую платформу и структуру нового проекта.
Partitioning - главная причина, из-за которого я отказался от любимого "правильного" Postgres в пользу более быстрого MySQL.

Есть какие-то ожидания, когда 5.1 станет стабильным?