Все правильно написал. Если у меня user_id = 100, при 5ти шардах, я буду попадать на 0вую шарду, добавляем 6той сервер, я попаду уже явно на другой шард, а там моих данных нет.
Не «остаток от деления user_id на числов серверов», потому что это негибко, и пользователей на другую шарду перетащить будет сложно в случае необходимости.
А в случае принятого решения, путем небольшого улучшения компонента, отвечающего за шардирование, можно будет неактивных пользователей перенести в шард на слабеньком сервере
Скажите, пожалуйста, какие в итоге предлагаются решения по автоматизации «Загрузки остатков на сайт», в случае если работа идет с несколькими поставщиками? их предложенных решений на автоматизацию тянет только одно и то с очевидными недостатками
Простите, но мне очень интересно, а какой можно будет сделать вывод из этого голосования? Расскажете, какие будут выводы, и на что повлияет? Я без издевательства и сарказма, правда интересно, не зря же люди делают такие опросы, наверняка, есть смысл, который от меня скрыт
Это если есть Nginx. В этом случае конечно через него запросы прокинуть лучше.
Но, как я описал «это самое простое что можно сделать, будет работать по идее на любом хостинге.»
Пока еще не все хостеры дыют править конфиг nginx, .htaccess «немножко» пораспространенее будет
репликация — на случай если у нас идет много записи в БД, и не хочется эти записи при перетаскивании терять.
Но это уже на случай если проект большой.
Описанный мной простой способ — это самое простое что можно сделать, будет работать по идее на любом хостинге.
Конечно.
Простое решение:
Разворачиваем на новом сервере полную версию сайта с БД и кодом, у веб сервера настраиваем адрес host и алиас www2.host
Заранее(за неделю до переезда) в DNS настраиваем, чтобы www2.host отзывался на новый ИПшник.
На старом сайте в htaccess прописываем редирект на www2.host
переключаем DNS.
Люди у которых DNS уже обновился — идут сразу на новый сервер, люди у которых DNS не обновился придут на старый, и их редиректнет на новый.
Гдето через неделю, как на старом сервере в access log перестанут появляться записи отключаем редирект. Все.
Сложный вариант — если в БД идет много записи — надо мудрить с бинлогами, чтобы получить БД без потерь, про это на хабре уже писали…
Плюс редирект через nginx хорошо сюда впишется, как Вы и писали
Почему бинарники не стоит редактировать? Потому что это адский костыль, и Вы не сможете гарантировать его последующую нормальную работу.
Если уж у нас сервер в полном контроле, лучше TTL у DNS поставить в 5 минут, и то лучше будет
Я думал что классическое решение — это настроить алиасом на новом сервере www2.* и со старого сервера перекидывать на него с помощью того же htaccess, пока DNS просасывается…
А редактировать .so файлы — это за гранью добра и зла… Я думаю, что так не стоит советовать
А как у нынешнего поколения с производительностью?
Год назад пробовали запустить html5 игры на нем — там лбая аркада превращалась в пошаговую стратегию изза тормозов.
Когда рисуешь карандашем, можно толщину линии регулировать силой нажатия. В ролике пишут, что это перо тоже реагирует на степень нажатия. Но на фотографиях кончик пера больше похож на шариковую ручку. Так вот на самой бумаге то будет разница в толщине линии при разной степени нажатия? Кто-нибудь знает?
У меня складывается ощущение что можно смело создавать блог «Маны» и туда раз в день комунибудь копипастить русский ман. Предела удивлению людей не будет :)
Это я не с наездом о том что топик бесполезный, я только рад, что много людей наконец-то узнало об этих командах. Это я к тому, чтобы както людям информации больше доносить, раз они читают не маны, а хабр :)
Ну зачем все это?
Ну неужели работая за границей, Вы не можете себе позволить купить фильм или альбом? Тогда какой смысл туда ехать? Зачем заниматься на работе нерабочими делами я уже и не спрашиваю…
Хотя желание разобраться самому во всем похвально, кто спорит… Но расстраивает все остальное
А в случае принятого решения, путем небольшого улучшения компонента, отвечающего за шардирование, можно будет неактивных пользователей перенести в шард на слабеньком сервере
Но, как я описал «это самое простое что можно сделать, будет работать по идее на любом хостинге.»
Пока еще не все хостеры дыют править конфиг nginx, .htaccess «немножко» пораспространенее будет
«Заранее(за неделю до переезда) в DNS настраиваем, чтобы www2.host отзывался на новый ИПшник.»
Но это уже на случай если проект большой.
Описанный мной простой способ — это самое простое что можно сделать, будет работать по идее на любом хостинге.
Простое решение:
Разворачиваем на новом сервере полную версию сайта с БД и кодом, у веб сервера настраиваем адрес host и алиас www2.host
Заранее(за неделю до переезда) в DNS настраиваем, чтобы www2.host отзывался на новый ИПшник.
На старом сайте в htaccess прописываем редирект на www2.host
переключаем DNS.
Люди у которых DNS уже обновился — идут сразу на новый сервер, люди у которых DNS не обновился придут на старый, и их редиректнет на новый.
Гдето через неделю, как на старом сервере в access log перестанут появляться записи отключаем редирект. Все.
Сложный вариант — если в БД идет много записи — надо мудрить с бинлогами, чтобы получить БД без потерь, про это на хабре уже писали…
Плюс редирект через nginx хорошо сюда впишется, как Вы и писали
Если уж у нас сервер в полном контроле, лучше TTL у DNS поставить в 5 минут, и то лучше будет
А редактировать .so файлы — это за гранью добра и зла… Я думаю, что так не стоит советовать
Год назад пробовали запустить html5 игры на нем — там лбая аркада превращалась в пошаговую стратегию изза тормозов.
Это я не с наездом о том что топик бесполезный, я только рад, что много людей наконец-то узнало об этих командах. Это я к тому, чтобы както людям информации больше доносить, раз они читают не маны, а хабр :)
Ну неужели работая за границей, Вы не можете себе позволить купить фильм или альбом? Тогда какой смысл туда ехать? Зачем заниматься на работе нерабочими делами я уже и не спрашиваю…
Хотя желание разобраться самому во всем похвально, кто спорит… Но расстраивает все остальное