> При чем тут копии? Я говорил, про расширение количества нод и перенос > данных со старых нод на новую. Репликацию новой ноды никто не отменял.
Копия, реплика, какая разница. Если у вас шарда на двух нодах и одна нода умерла, то пять дней вводить новую ноду уж слишком большой риск. Так несколько раз и гарантированно потеряете данные. >> Вот тут можно почитать подробнее: >> http://pdos.csail.mit.edu/papers/carbonite:nsdi06/ > > Опять про репликацию. Чтож. Ну да, вся суть в этом, а не в шардинге в одну строчку :) > Понятно. Я про шардинг, распределение данных по шардам и шардов по > нодам, последующее перераспределение данных, а вы все про репликацию и > failover. Задачи конечно рядом идут, но не на столько чтобы говорить > про одно, а ответы получать все время про другое. Ну вот а я не пойму, каким образом они могут быть разделимы. Допустим, вы хотите добавить запись, у вас для шарды есть 3 ноды и вам обязательно нужен фейловер (а кому не нужен в общем-то?). Вот тут сразу и надо определиться, как это делать. Можно использовать quorum logic, и послать запрос во все три ноды, подождать пока обработаются и если все ок -- сказать клиенту, что данные сохранены. Это позволит отвечать на запросы чтения записи обращаясь только к одной ноде. Вместо репликации теперь будет только синхронизация, но нужно обязательно какой-то дополнительный параметр для решения конфликтов при синхронизации, на случай двух запросов одновременно. Если это vector clock, то он привязан к шардингу и ко всей системе вообще. Можно использовать репликацию. Но тогда все равно нужен алгоритм, чтобы ноды договорились о новом мастере, если текущий упал. И при этом все запросы к шарде без мастера будут в это время отказывать. Полноценного фейловера не получается. И это все опять привязано к шардингу и всей системе. Хотя еще как вариант можно сделать все ноды с репликами мастерами и раскидывать запросы по хэшу по ним, как в изначальном примере. А у них у каждой будет репликация на оба соседа установлена. Тогда наверное выбор мастера для шарды уже не нужен. Останется решить только проблему хэлсчека. -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
