[Moscow.pm] Что стало с модулем DBIx::DBCluster?

[Alexandr Gomoliako]

On 3/8/12, Ruslan Zakirov <ruz at bestpractical.com> wrote:
> Какие-то оценки у вас странные. Откусили блок в Х ключей и
> переместили, если необходимость перенести быстрее. Кто сказал, что
> нужно ввести ноду за пять минут. Пять дней тоже нормально.

Нужно ввести ноду за 0 минут, за пять дней может и конец света наступить :)

Но вообще правило примерно такое: новая копия должна создаваться
быстрее, чем время между отказами дисков/появлением бэдблоков с учетом
каскадных отказов, иначе данные будут теряться.

Вот тут можно почитать подробнее:
http://pdos.csail.mit.edu/papers/carbonite:nsdi06/

> Из вашего примера было сложно понять, что у вас изначально шард больше
> чем нод и количество шард статичное.
>
> Это плюс. Шарды у вас просто в разных БД на одном инстансе СУБД?

Шарды там, где вам удобно :) Хотите, можно приписывать в имена таблиц,
а можно и просто назвать базу по имени шарды.

> Что делать, когда шард станет меньше чем нод? Или шард просто ну очень
> много?

Да, их очень, заранее берется побольше. Например, если начинаете с 1-й
ноды (сервера) и хотите вырасти в 100 раз, то берите сразу 2 hex
буквы, т.е. 256 шард.

> Блокировки все равно нужны для переноса шард между нодами.

Это если не использовать никакую распределнную модель хранения данных.

> Как это связано с разбиением данных по шардам и нодам? Не вижу супер
> прямой связи. Если только вы не реплицируете данные больше одного раза
> и не разбрасываете их по различным шардам.

А как это может быть без нескольких реплик? Потеряли данные и забыли? :)
Или упал мастер ну и пусть, подождем, пока суппорт починит и вернет?
За это время большие шансы потерять данные и те что есть.