On 3/8/12, Ruslan Zakirov <[email protected]> wrote: > Какие-то оценки у вас странные. Откусили блок в Х ключей и > переместили, если необходимость перенести быстрее. Кто сказал, что > нужно ввести ноду за пять минут. Пять дней тоже нормально.
Нужно ввести ноду за 0 минут, за пять дней может и конец света наступить :) Но вообще правило примерно такое: новая копия должна создаваться быстрее, чем время между отказами дисков/появлением бэдблоков с учетом каскадных отказов, иначе данные будут теряться. Вот тут можно почитать подробнее: http://pdos.csail.mit.edu/papers/carbonite:nsdi06/ > Из вашего примера было сложно понять, что у вас изначально шард больше > чем нод и количество шард статичное. > > Это плюс. Шарды у вас просто в разных БД на одном инстансе СУБД? Шарды там, где вам удобно :) Хотите, можно приписывать в имена таблиц, а можно и просто назвать базу по имени шарды. > Что делать, когда шард станет меньше чем нод? Или шард просто ну очень > много? Да, их очень, заранее берется побольше. Например, если начинаете с 1-й ноды (сервера) и хотите вырасти в 100 раз, то берите сразу 2 hex буквы, т.е. 256 шард. > Блокировки все равно нужны для переноса шард между нодами. Это если не использовать никакую распределнную модель хранения данных. > Как это связано с разбиением данных по шардам и нодам? Не вижу супер > прямой связи. Если только вы не реплицируете данные больше одного раза > и не разбрасываете их по различным шардам. А как это может быть без нескольких реплик? Потеряли данные и забыли? :) Или упал мастер ну и пусть, подождем, пока суппорт починит и вернет? За это время большие шансы потерять данные и те что есть. -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
