Комментарии 104
А каковы каналы и задержки в них между нодами mysql? Хватит ли ширины и отклика для нормальной онлайн-репликации?
Каждый сервер подключен в порт 100мбит. При тестировании работы сайта синхронизация просиходила сразу, задержек не было выявлено.
а сейчас, похоже, московское зеркало лежит.
root@vds:~# curl -sI hostpro.ua -vv
* About to connect() to hostpro.ua port 80 (#0)
* Trying 77.222.131.110... Connection timed out
* couldn't connect to host
* Closing connection #0
[root@system ~]# curl -sI hostpro.ua -vv
* About to connect() to hostpro.ua port 80
* Trying 77.222.131.110... Connection timed out
* couldn't connect to host
* Closing connection #0
не только московское. их сайт резолвится на 77.222.131.110 со всего мира
вот вам и патч на бинд. Говорил я, что патчами бинда ГЕО-кластер нельзя реализовывать… BGP Multicast рулит ) Ну или человеческие ADC-балансировщики.
Хорошая новость, таких сервисов надо больше.
Вот только какой-то у вас СВТ странный, картинки не отдаёт. Сайт лёг.
Вывод:
>>меньшая уязвимость к DDOS-атакам за счет перераспределения потока запросов к сайту, а также возможности ограничить запросы из определенного региона;
Не работает.
Вот только какой-то у вас СВТ странный, картинки не отдаёт. Сайт лёг.
Вывод:
>>меньшая уязвимость к DDOS-атакам за счет перераспределения потока запросов к сайту, а также возможности ограничить запросы из определенного региона;
Не работает.
Наш сайт пока не на гео-хостинге. Возможно, если бы был — такой проблемы не было бы.
Прошу прощения за неполадки, сайт не у всех открывался из-за нашей борьбы с дДос атакой на наш сайт, которая продолжается уже несколько дней. Сейчас все должно открываться.
Прошу прощения за неполадки, сайт не у всех открывался из-за нашей борьбы с дДос атакой на наш сайт, которая продолжается уже несколько дней. Сейчас все должно открываться.
Хм… Ну первое, что мне приходит в голову — сервер в том же регионе не означает более высокую скорость отклика. При прочих равных, наверное да. Но в общем случае, нет.
под регионом подразумевается страна, как видно из приведённых скринов скорость доступа к сайту с регионов(областей) из России быстрее к серверу использующему услугу гео-хостинга по сравнению с сервером который просто расположен в Украине.
Это понятно, но это частный случай, а точнее success story. Обратный пример — если разместить сервер в дата-центре в Германии и разместить сервер на каком-нибудь глубоком хостинге в России, далеко не факт, что скорость отклика российского сервера будет выше, чем немецкого.
Гео-хостинг это неплохое маркетинговое сообщение для руководителей, которые не разбираются в технических вопросах. Оно хорошо «ложится» на оффлайновое прошлое многих из них.
Но выгоды, на мой взгляд, не очевидны. В то время как очевидно усложнение и удорожание техподдержки интернет-проектов.
Гео-хостинг это неплохое маркетинговое сообщение для руководителей, которые не разбираются в технических вопросах. Оно хорошо «ложится» на оффлайновое прошлое многих из них.
Но выгоды, на мой взгляд, не очевидны. В то время как очевидно усложнение и удорожание техподдержки интернет-проектов.
Чем обусловен выбор патченого bund, а не, например, Super Sparrow.
Мы не рассматривали данное решение для нашей задачи, нам показалось, что использование патча для Bind более простой и оптимальный вариант. Хотя не исключена вероятность того, мы попробуем построить нашу систему и с использованием bgp роутинга.
может потому, что он мёртв? Как и те патчи для бинда, но они чуть посвежее.
Да, очень похоже на то — я очень давно на него не смотрел.
Интересно, что сейчас наиболее свежее и актуальное?
Интересно, что сейчас наиболее свежее и актуальное?
GSLB средствами ADC, например.
Ну или вот доклад неплохой на тему.
Ну или вот доклад неплохой на тему.
И что, этот 1 сек ответа имеет значение для посетителя?
Имеет и огромное. Правда не для сайтов размещенных на шареде, они скорее по другим причинам будут тормозить, не из-за сети.
А можно пример, в каких случаях это поможет? Вот для онлайн игр эта секунда критична. Для voice/video конференций — тоже. Но там простым реплицированием не обойдешься, требуется вынос всей серверной части.
А посте предлагают обычное кеширование контента — так? Когда это надо?
Я верю, что видимо, это надо, но непонянто, когда и для кого :)
А посте предлагают обычное кеширование контента — так? Когда это надо?
Я верю, что видимо, это надо, но непонянто, когда и для кого :)
Каждая секунда ожидания уменьшает количество хитов, которые пользователь делает на сайте (уменьшает баннеропоказы).
С медленного сайта (а 1с грузиться это долго, особенно если еще всякий внешний хлам будет подгружаться) народ быстрее уходит.
Кроме того, сейчас это еще и важный фактов в ранжировании со стороны ПС.
Яху в свое время заявляло, что каждые 100мс загрузки сайта уменьшают доход на некое количество процентов (в районе 3, если не ошибаюсь).
webo.in/articles/oborot2009/faster-means-better/ вот тут тоже неплохо изложено. Скорость решает.
С медленного сайта (а 1с грузиться это долго, особенно если еще всякий внешний хлам будет подгружаться) народ быстрее уходит.
Кроме того, сейчас это еще и важный фактов в ранжировании со стороны ПС.
Яху в свое время заявляло, что каждые 100мс загрузки сайта уменьшают доход на некое количество процентов (в районе 3, если не ошибаюсь).
webo.in/articles/oborot2009/faster-means-better/ вот тут тоже неплохо изложено. Скорость решает.
Ага, интересно.
Тогда я хотел бы понять, как я могу это использовать. Интернет магазин? Врядли — придется разносить скрипты по разным серверам, это малореально. Тогда получается, что проекты, где есть более-менее сложная логика и база, на разные сервера не разносятся.
И я вижу только один смысл услуги (которуб предлагают выше) — простенькие сайты и мелкий (много малых файлов) статический контент (на тяжелом контенте секунды роли не играют). В этом случае скорость загрузки статики будет быстрой.
Это логично?
Тогда я хотел бы понять, как я могу это использовать. Интернет магазин? Врядли — придется разносить скрипты по разным серверам, это малореально. Тогда получается, что проекты, где есть более-менее сложная логика и база, на разные сервера не разносятся.
И я вижу только один смысл услуги (которуб предлагают выше) — простенькие сайты и мелкий (много малых файлов) статический контент (на тяжелом контенте секунды роли не играют). В этом случае скорость загрузки статики будет быстрой.
Это логично?
>>придется разносить скрипты по разным серверам, это малореально.
Почему это малореально? Вроде как в этом и фишка. Да и проблемы не вижу.
Большие порталы масштабируются и разносятся на многих уровнях.
Почему это малореально? Вроде как в этом и фишка. Да и проблемы не вижу.
Большие порталы масштабируются и разносятся на многих уровнях.
Да, вижу, она масшабируют файловую систему и реплицируют БД.
Но опять же — я плохо представляю, как будет работать интернет магазин с рассинхоронизированными (они же не постоянно апдейтятся) копиями БД.
Короче, перспективы неясны. Пусть лучше success story покажут.
Но опять же — я плохо представляю, как будет работать интернет магазин с рассинхоронизированными (они же не постоянно апдейтятся) копиями БД.
Короче, перспективы неясны. Пусть лучше success story покажут.
Копии БД тоже синхронизируются. А еще может быть база одна (при условии, что канал у хостера между серверами хостера хороший), разные только морды для большей скорости доступа клиентов. А локальное кеширование поможет уменьшить задержки доступа к базе.
Да, но как написано в статье — синхронизируются не мгновенно, а для среднего проекта это уже критично.
В случае одной базы однозначно 1 секунда будет убита на соединение с удаленной базой.
Неочевиден смысл.
В случае одной базы однозначно 1 секунда будет убита на соединение с удаленной базой.
Неочевиден смысл.
то, что данные не синхронизированы в разных гео зонах не критично практически нигде. 1% сайтов, которым это критично используют другие схемы. И даже если использовать одну базу и локальное кеширование, задержки будут небольшими, намного меньше 1с.
Позвольте, любой сайт, где есть изменяемый каталог (интернет-магазин), форум и т.п. критичен к синхронизации данных. Вам же не понравиться оплатить счет за товар, который был куплен чуть раньше другим пользователем? Такая схема кластера допустимо только для сайтов, где изменения вносятся централизованно, либо не вносятся совсем.
Ну форум, допустим. Данные там для пользователя обновляются не в реальном времени, а после обновления страницы. Потому то, что данные на другой сервер попадут на несколько секунд позже не критично. Пользователь мог и страницу обновить немного позже.
Аналогично магазины и все остальное. Проблемы возникнут там где один пользователь может быть обработан несколькими серверами в пределах одной сессии. Но эти проблемы решаются по-другому и в данной ситуации их быть не может.
Аналогично магазины и все остальное. Проблемы возникнут там где один пользователь может быть обработан несколькими серверами в пределах одной сессии. Но эти проблемы решаются по-другому и в данной ситуации их быть не может.
Вы рассматриваете только случай кратковременной задержки репликации. А если сервер БД (один из многих) был недоступен, положим, час?
«Проблемы возникнут там где один пользователь может быть обработан несколькими серверами в пределах одной сессии» я честно старался представить себе такую ситуацию. Не смог. Приведите пример.
А вот вариант, когда одни и те же данные могут быть изменены разными пользователями на разных серверах — запросто.
Существуют два подхода к репликации — синхронный и асинхронный. В первом случае транзакция должна отработать на всех участниках. Второй — недопустим в учетных, биллинговы и т.п. системах.
«Проблемы возникнут там где один пользователь может быть обработан несколькими серверами в пределах одной сессии» я честно старался представить себе такую ситуацию. Не смог. Приведите пример.
А вот вариант, когда одни и те же данные могут быть изменены разными пользователями на разных серверах — запросто.
Существуют два подхода к репликации — синхронный и асинхронный. В первом случае транзакция должна отработать на всех участниках. Второй — недопустим в учетных, биллинговы и т.п. системах.
Если сервер недоступен — ну что ж, плохо, не будет работать и морда что привязана к этому серверу. Тут много серверов поможет тем, что будет хоть для части людей сайт работать.
Допустим сервера перегружены и репликация задерживается на пару минут. Что это меняет? ответы невпопад на форуме все равно чаще возникнут из-за того, что пользователи долго читают обсуждение и пишут ответ, как правило. это занимает много больше времени.
Почти все большие сервисы (гугл, фейсбук и.т.д) обновляются постепенно, т.е. для разных пользователей не только данные, но и версия кода может быть разной. Никому это не мешает.
Для платежных систем и прочих критичных сервисов, такой метод распределения не подойдет. Но там и шаред в принципе не подойдет, архитектура сильно отличается от обычных сервисов.
Допустим сервера перегружены и репликация задерживается на пару минут. Что это меняет? ответы невпопад на форуме все равно чаще возникнут из-за того, что пользователи долго читают обсуждение и пишут ответ, как правило. это занимает много больше времени.
Почти все большие сервисы (гугл, фейсбук и.т.д) обновляются постепенно, т.е. для разных пользователей не только данные, но и версия кода может быть разной. Никому это не мешает.
Для платежных систем и прочих критичных сервисов, такой метод распределения не подойдет. Но там и шаред в принципе не подойдет, архитектура сильно отличается от обычных сервисов.
«Если сервер недоступен — ну что ж, плохо, не будет работать и морда что привязана к этому серверу. Тут много серверов поможет тем, что будет хоть для части людей сайт работать.» Мы вроде как о внесении изменений говорили. Что будет с изменяемыми данными, когда один из участников репликации недоступен?
При чем здесь «большие сервисы»? У них процедура внесения изменений — отдельный технологический процесс. И они проектировались под работу в распределенной среде.
В данном же примере объявлено, что «Система работает таким образом, что владельцу сайта не нужно изменять работу веб-приложения для работы с распределенной архитектурой.» Это не верно. Система будет прекрасно работать для приложений, ориентированных на подобный способ (контролированное внесение изменений). Либо использовать только часть функционала, например, быстрая отдача статического контента при использовании единой БД (такой вот мини акамай).
При чем здесь «большие сервисы»? У них процедура внесения изменений — отдельный технологический процесс. И они проектировались под работу в распределенной среде.
В данном же примере объявлено, что «Система работает таким образом, что владельцу сайта не нужно изменять работу веб-приложения для работы с распределенной архитектурой.» Это не верно. Система будет прекрасно работать для приложений, ориентированных на подобный способ (контролированное внесение изменений). Либо использовать только часть функционала, например, быстрая отдача статического контента при использовании единой БД (такой вот мини акамай).
Какие конкретно приложения будут плохо работать?
форумы и магазины — отлично, там риалтаймовость не нужна, задержки в пределах пары десятков секунд вполне допустимы. Остальное что можно поставить на шаред, тоже без проблем будет работать.
Примером больших сервисов я хотел показать что то, что у одних пользователей будут данные чуть опаздывать, а у других появляться раньше, это не проблема для 90% задач.
Ладно, я устал говорить одно и то же, не видите, зачем это вам может быть нужно — не пользуйтесь.
форумы и магазины — отлично, там риалтаймовость не нужна, задержки в пределах пары десятков секунд вполне допустимы. Остальное что можно поставить на шаред, тоже без проблем будет работать.
Примером больших сервисов я хотел показать что то, что у одних пользователей будут данные чуть опаздывать, а у других появляться раньше, это не проблема для 90% задач.
Ладно, я устал говорить одно и то же, не видите, зачем это вам может быть нужно — не пользуйтесь.
плохо будет работать Joomla, когда редактор удалит раздел в который пользователь на лругом сервере вносит изменения. При репликации возникнет конфликт.
Зачем нужен такой сервис — я написал. Совершенно реальные примеры, которые могут успешно работать в такой системе.
Я указываю на некорректность некоторых заявлений в тексте с обоснованием, почему так считаю.
Зачем нужен такой сервис — я написал. Совершенно реальные примеры, которые могут успешно работать в такой системе.
Я указываю на некорректность некоторых заявлений в тексте с обоснованием, почему так считаю.
А на обычном хостинге что будет «когда редактор удалит раздел в который пользователь на лругом сервере вносит изменения.»?
На обычном хостинге нет другого сервера
Ну нету. Я спросил, что будет, «когда редактор удалит раздел в который пользователь на лругом сервере вносит изменения.»? можете ответить?
непредсказуемая ошибка (зависит от того как это обрабатывает конечное приложение), в данном случае joomla. Если в момент удаления радздела, выбираются и удаляются все его дети, то в этом случае на сервере, где узер что-то добавлял, это что-то останется мертвым грузом. (опять же зависит от того как написать приложение).
это называется нарушена целостность. данные обновляются не Асинхронно и это надо учитывать при написании приложения.
Joomla скорее всего на это не расчитана.
вообщем и целом просто брать любой сайт и так распределять — глупо.
это называется нарушена целостность. данные обновляются не Асинхронно и это надо учитывать при написании приложения.
Joomla скорее всего на это не расчитана.
вообщем и целом просто брать любой сайт и так распределять — глупо.
Вопрос пожалуйста почитайте. Я спрашивал, что будет в случае одного сервера. Дальше хотел показать что разницы не будет даже для нескольких серверов, но увы, спорящие со мной даже вопрос заданный пару раз не могут прочитать(
пардон конечно, но это вы не вникли в ответ, ибо ответ на ваш вопрос там дан:
Если в момент удаления радздела, выбираются и удаляются все его дети, то в этом случае на сервере, где узер что-то добавлял, это что-то останется мертвым грузом. (опять же зависит от того как написать приложение).
это называется нарушена целостность. данные обновляются Асинхронно и это надо учитывать при написании приложения.
в случае одного сервера тут все отработает нормально.
Если в момент удаления радздела, выбираются и удаляются все его дети, то в этом случае на сервере, где узер что-то добавлял, это что-то останется мертвым грузом. (опять же зависит от того как написать приложение).
это называется нарушена целостность. данные обновляются Асинхронно и это надо учитывать при написании приложения.
в случае одного сервера тут все отработает нормально.
Я загружаю админку, наимаю редактировать и сижу печатаю текст. В это время заходит другой админ, удаляет весь раздел, в котором была та запись что я редактировал. Нарушается целостность, правда? Что будет когда я нажму кнопку «сохранить»?
В чем принципиальная разница данной ситуации о той, при которой удалят на другом сервере и потом изменения дойдут до того, на котором работаю я?
В чем принципиальная разница данной ситуации о той, при которой удалят на другом сервере и потом изменения дойдут до того, на котором работаю я?
> Что будет когда я нажму кнопку «сохранить»?
ОДИН СЕРВЕР:
два варианта алгоритма:
1. программа проверяет родителя к которому вы хотите сохранить ваш документ и выдает ошибку если его нет, если есть — добавляет.
2. программа не проверяет наличие родителя, к которому вы хотите сохранить ваш документ и тупо добавляет в базу. (в это случае будет мусор).
ДВА СЕРВЕРА:
опять два варианта алгоритма:
предположим, что данные с того сервера, где заходил другой админ еще не дошли до того сервера, с которым работаете вы, а это вполне возможно в схеме репликации.
1. программа проверяет родителя к которому вы хотите сохранить ваш документ и выдает ошибку если его нет, если есть — добавляет. (в данном случае в любом случае добавит, т.к. в вашей версии базы этот родитель еще не удален).
2. программа не проверяет наличие родителя, к которому вы хотите сохранить ваш документ и тупо добавляет в базу.
и только потом приходит репликация на второй сервер, на котором работает вы и удаляет то, что было у этого родителя до того, как вы нажали чего-то там не важно что…
в случае двух серверов в любом случае будет мусор.
Мусора не будет только в том случае, если дети удаляются так DELETE FROM childs WHERE parent=ParentID; — но это возможно только в том случае если у этих детей нет своих детей или по какой-то другой причине (поэтому я и говорю, что тут все очень сильно зависит от реализации приложения).
Доступно написал?
ОДИН СЕРВЕР:
два варианта алгоритма:
1. программа проверяет родителя к которому вы хотите сохранить ваш документ и выдает ошибку если его нет, если есть — добавляет.
2. программа не проверяет наличие родителя, к которому вы хотите сохранить ваш документ и тупо добавляет в базу. (в это случае будет мусор).
ДВА СЕРВЕРА:
опять два варианта алгоритма:
предположим, что данные с того сервера, где заходил другой админ еще не дошли до того сервера, с которым работаете вы, а это вполне возможно в схеме репликации.
1. программа проверяет родителя к которому вы хотите сохранить ваш документ и выдает ошибку если его нет, если есть — добавляет. (в данном случае в любом случае добавит, т.к. в вашей версии базы этот родитель еще не удален).
2. программа не проверяет наличие родителя, к которому вы хотите сохранить ваш документ и тупо добавляет в базу.
и только потом приходит репликация на второй сервер, на котором работает вы и удаляет то, что было у этого родителя до того, как вы нажали чего-то там не важно что…
в случае двух серверов в любом случае будет мусор.
Мусора не будет только в том случае, если дети удаляются так DELETE FROM childs WHERE parent=ParentID; — но это возможно только в том случае если у этих детей нет своих детей или по какой-то другой причине (поэтому я и говорю, что тут все очень сильно зависит от реализации приложения).
Доступно написал?
Если делать репликацию на уровне sql запросов, а не данных, то задержка с получением данных от второго сервера будет равнозначна тому, что второй админ просто чуть позже нажал кнопку удаления.
Я собирал подобную схему репликации из 5 серверов, на каждом из которых была своя СУБД и был настроен mysql proxy, который занимался вопросами синхронизации данных на серверах. Просто отправлял все изменяющие данные запросы на каждый сервер. Да, периодически была задержка, но никаких проблем с обычными wordpress, dle, IPB небыло, при том, что посещаемость была достаточная для того, чтобы проблемы могли вылезти (несколько десятков тысяч хостов и суммарно порядка миллиона хитов в сутки).
Я собирал подобную схему репликации из 5 серверов, на каждом из которых была своя СУБД и был настроен mysql proxy, который занимался вопросами синхронизации данных на серверах. Просто отправлял все изменяющие данные запросы на каждый сервер. Да, периодически была задержка, но никаких проблем с обычными wordpress, dle, IPB небыло, при том, что посещаемость была достаточная для того, чтобы проблемы могли вылезти (несколько десятков тысяч хостов и суммарно порядка миллиона хитов в сутки).
> Если делать репликацию на уровне sql запросов, а не данных, то задержка с получением данных от второго сервера будет равнозначна тому, что второй админ просто чуть позже нажал кнопку удаления.
утешайте себя этим :)
если запрос на удаление чайлдов такой: DELETE FROM childs WHERE parent=ParentID; — то да, проблем не будет, а если удаление происходит так: SELECT * FROM childs WHERE parent=ParentID; и потом в цикле DELETE FROM childs WHERE ID=ChildID; (это кстати нормальный вариант ООП подхода) — то проблемы будут (мусор останется).
> посещаемость была достаточная для того, чтобы проблемы могли вылезти (несколько десятков тысяч хостов и суммарно порядка миллиона хитов в сутки).
а теперь посчитайте, сколько там было ИЗМЕНЕНИЙ в одной сущности в секунду и поймете, что вам просто повезло, что проблем не возникало или вам просто не сообщили о проблеме или не обнаружили ее.
В ваших доводах нет доказательств. Я же вам вполне четко доказал возможность нарушения целостности.
утешайте себя этим :)
если запрос на удаление чайлдов такой: DELETE FROM childs WHERE parent=ParentID; — то да, проблем не будет, а если удаление происходит так: SELECT * FROM childs WHERE parent=ParentID; и потом в цикле DELETE FROM childs WHERE ID=ChildID; (это кстати нормальный вариант ООП подхода) — то проблемы будут (мусор останется).
> посещаемость была достаточная для того, чтобы проблемы могли вылезти (несколько десятков тысяч хостов и суммарно порядка миллиона хитов в сутки).
а теперь посчитайте, сколько там было ИЗМЕНЕНИЙ в одной сущности в секунду и поймете, что вам просто повезло, что проблем не возникало или вам просто не сообщили о проблеме или не обнаружили ее.
В ваших доводах нет доказательств. Я же вам вполне четко доказал возможность нарушения целостности.
Ну и что будет? select выберет все нужные id (помните, на втором сервере они тоже не удалены?), а потом удалит каждый запросом, который пойдет на оба сервера сразу.
Мусор может быть, если были добавлены записи с тем-же parent, после того, как была сделана выборка id для удаления.
Тем не менее, мусор мешать работе сайта не будет.
Пришлось сделать хак для автоинкрементов, но для сайтов это все равно было прозрачно и на код не влияло.
вообще подход быдлокодерский, но какой уж есть, чужой код на то и чужой.
Мусор может быть, если были добавлены записи с тем-же parent, после того, как была сделана выборка id для удаления.
Тем не менее, мусор мешать работе сайта не будет.
Пришлось сделать хак для автоинкрементов, но для сайтов это все равно было прозрачно и на код не влияло.
вообще подход быдлокодерский, но какой уж есть, чужой код на то и чужой.
> Ну и что будет? select выберет все нужные id (помните, на втором сервере они тоже не удалены?), а потом удалит каждый запросом, который пойдет на оба сервера сразу.
правильно! он выберет только то что было на первом… он не выберет то что добавилось на втором, т.к. со второго на первый еще не отреплецировалось! И следовательно не удалит то, что добавилось на втором. Такую же схему можно и обрисовать и с обратной стороны — не удаления, а добавления…
> вообще подход быдлокодерский, но какой уж есть, чужой код на то и чужой.
не судите о других — они не знали, что вы новичек в репликации и будете проводить эксперименты на них, поэтому не оптимизировали приложения под master-master репликацию. в этом думаю не было вины программеров. в этом вина безголового админа, который элементарно не может понять понятия асинхронности.
дальнейшее обсуждение бесполезно, т.к. ответ на ваш вопрос я дал, а дальнейшие ваши утверждения только говорят о ваших ошибках в понимании технологии.
правильно! он выберет только то что было на первом… он не выберет то что добавилось на втором, т.к. со второго на первый еще не отреплецировалось! И следовательно не удалит то, что добавилось на втором. Такую же схему можно и обрисовать и с обратной стороны — не удаления, а добавления…
> вообще подход быдлокодерский, но какой уж есть, чужой код на то и чужой.
не судите о других — они не знали, что вы новичек в репликации и будете проводить эксперименты на них, поэтому не оптимизировали приложения под master-master репликацию. в этом думаю не было вины программеров. в этом вина безголового админа, который элементарно не может понять понятия асинхронности.
дальнейшее обсуждение бесполезно, т.к. ответ на ваш вопрос я дал, а дальнейшие ваши утверждения только говорят о ваших ошибках в понимании технологии.
>> они не знали, что вы новичек в репликации и будете проводить эксперименты на них
А еще не знали о том, что парсинг sql занимает время, о том, что сотни запросов вместо одного съедают сетевой трафик, а БД не всегда локальная, не знают о том, что БД будет пытаться пересчитывать индексы после каждого добавления итд.
А каскадные удаления и связывание структуры данных на основе внешних ключей вообще придумали потому, что надо было чем-то занять время.
А еще не знали о том, что парсинг sql занимает время, о том, что сотни запросов вместо одного съедают сетевой трафик, а БД не всегда локальная, не знают о том, что БД будет пытаться пересчитывать индексы после каждого добавления итд.
А каскадные удаления и связывание структуры данных на основе внешних ключей вообще придумали потому, что надо было чем-то занять время.
афигеть, вы еще скажите, что вы трафик на лупбэке считает :)) (не серкрет, что 80-90% хостеров мускулы держат прям на бэках и еще 80% из них даже фронта не имеют).
к вашему удивлению наверное, но не всегда рационально экономить трафик в пользу блокировок внутри мускула и медленному выполнению выборки.
вот пример (поле id — это ключ id_key):
1. один запрос: SELECT * FROM t WHERE id IN (1,2,3,4,5,...,N);
2. N запросов: SELECT * FROM t WHERE id=N;
2. HANDLER t OPEN id_key; N запросов: HANDLER t READ id_key=(N); HANDLER CLOSE;
сейчас я так понимаю вы проголосуете за первый запрос, ведь он меньше всего трафика жрет.
ради интереса протестируйте эти три варианта скажем на 1М итераций и сразу же прекратите считать трафик ;)
> А каскадные удаления и связывание структуры данных на основе внешних ключей
весьма полезные вещи в комплекте с мозгом. могу привести элементарные примеры, что это не рабает в ЛЮБОЙ распределенной системе. (да, где то можно юзать, но далеко не везде)
к вашему удивлению наверное, но не всегда рационально экономить трафик в пользу блокировок внутри мускула и медленному выполнению выборки.
вот пример (поле id — это ключ id_key):
1. один запрос: SELECT * FROM t WHERE id IN (1,2,3,4,5,...,N);
2. N запросов: SELECT * FROM t WHERE id=N;
2. HANDLER t OPEN id_key; N запросов: HANDLER t READ id_key=(N); HANDLER CLOSE;
сейчас я так понимаю вы проголосуете за первый запрос, ведь он меньше всего трафика жрет.
ради интереса протестируйте эти три варианта скажем на 1М итераций и сразу же прекратите считать трафик ;)
> А каскадные удаления и связывание структуры данных на основе внешних ключей
весьма полезные вещи в комплекте с мозгом. могу привести элементарные примеры, что это не рабает в ЛЮБОЙ распределенной системе. (да, где то можно юзать, но далеко не везде)
Множество select вместо одного могут быть оправданы при определенных условиях.
Но речь была о delete, да еще и в ситуации, когда данных может быть столько, что легко съест гигабайты памяти и засрет очередь запросов на много часов (ну ладно, такого не будет, код который так делает удаление, вряд ли пустят к данным такого объема).
Представляете, сколько будет выполняться удаление, тыщ, скажем, 50 записей (решили удалить неактивных пользователей на старом форуме, например).
Но речь была о delete, да еще и в ситуации, когда данных может быть столько, что легко съест гигабайты памяти и засрет очередь запросов на много часов (ну ладно, такого не будет, код который так делает удаление, вряд ли пустят к данным такого объема).
Представляете, сколько будет выполняться удаление, тыщ, скажем, 50 записей (решили удалить неактивных пользователей на старом форуме, например).
«был настроен mysql proxy, который занимался вопросами синхронизации данных на серверах. »
иными словами ВСЕ 5 серверов работали с ОДНИМ сервером БД, который занималася контролем целостности данных на остальных серверах БД? Да, такой вариант рабочий. Единственное ограничение скорости — время отработки транзакции на прокси сервере БД. Но в этом случае приложение должно знать, что читать данные оно должно с одного сервера БД, а писать — через другой. Т.е. изменение в приложение внести нужно.
иными словами ВСЕ 5 серверов работали с ОДНИМ сервером БД, который занималася контролем целостности данных на остальных серверах БД? Да, такой вариант рабочий. Единственное ограничение скорости — время отработки транзакции на прокси сервере БД. Но в этом случае приложение должно знать, что читать данные оно должно с одного сервера БД, а писать — через другой. Т.е. изменение в приложение внести нужно.
Нет, ну сервера разные были, mysql proxy занимался тем, что раскидывал изменяющиеся запросы по ним и делал выборку из локального сервера. Ну и пару преобработок выполнял.
Изменений не вносилось, это был принципиальный момент. Править код какой-нибудь джумлы я бы вряд ли осилил.
Изменений не вносилось, это был принципиальный момент. Править код какой-нибудь джумлы я бы вряд ли осилил.
т.е. на web серверах в качестве сервера БД указывались адреса разных mysql. А как в таком случае отрабатывает транзакция на изменение данных? Она ждет какого-то подтверждения от MySQL Proxy?
Устанавливается localhost. Если бы был не локалхост, то сделал бы сервер db (название хоста) и прописал бы файлике /etc/hosts. Чтобы конфиги сайтов тоже не пришлось менять.
естественно, что сайты работали с proxy, сервер mysql на другом порту слушался.
прокси, на сколько я помню, рассылал запрос по всем серверам, но возвращал управление когда запрос завершался на локальном сервере. Остальные сервера sql уже задержек для сайта не создавали.
естественно, что сайты работали с proxy, сервер mysql на другом порту слушался.
прокси, на сколько я помню, рассылал запрос по всем серверам, но возвращал управление когда запрос завершался на локальном сервере. Остальные сервера sql уже задержек для сайта не создавали.
en.wikipedia.org/wiki/CAP_theorem
вот есть хорошая теоремка. в ней популярно раписано как и что работает и почему нельзя достичь идеала. даже доказана эта теорема :)
вот есть хорошая теоремка. в ней популярно раписано как и что работает и почему нельзя достичь идеала. даже доказана эта теорема :)
При репликации запись синхронизируется сразу как только была добавлена. Сервер не накапливает пакет данных, для того чтоб в определённый момент времени отправить их на другой сервер.
в онлайн играх — да
Стоп, я бы хотял понять, как это поможет онлайн играм. В онлайн играх скорее всего используется сервер — флешовый или еще какой. Как сервер можно реплицировать по описанно выше схеме? Максимум, что можно — это грузить контент с ближаших серверов. Но не более.
стоп, вы ничего не говорили про репликацию по выше описанной схеме. я просто сказал, что для пользователя онлайн игр 1 сек имеет значение. задавайте вопрос более четко, если не хотите получить расплывчатый ответ
Я исключительно в теме поста — очевидно, что 1 сек важна, но в четко определенных приложениях (играх, коммуникациях). И соотвественно вопрос — как описанная в посте схема поможет выиграть эту секунду в «определенных приложениях»? Автор же предлагает просто раскидать статику/динамику по серверам, но в этом случае 1 сек не принципиальна.
На графике в одном месте время отклика «обычного» сайта меньше времени отклика сайта на гео–хостинге. Чем это может быть вызвано? В каких случаях происходит?
Акелла промахнулся? И пользователя направили на сервер, который, быть может, и находится ближе географически, но доступ к нему дольше.
Я видел подобное — пинг до хоста через дорогу шёл несколько минут — через Москву, Франкфурт и Лондон, а физически между компами было метров 300 — такой вот роутинг был между разными провайдерами в нашем городе на Дальнем Востоке :)
Я видел подобное — пинг до хоста через дорогу шёл несколько минут — через Москву, Франкфурт и Лондон, а физически между компами было метров 300 — такой вот роутинг был между разными провайдерами в нашем городе на Дальнем Востоке :)
Я так понимаю одна нода полетела
www.wipmania.com/ping/cache/chasy-bu.com/?c=c3c9370dd351543
Или гео непрнавильно работает? Также странно выглядит отдача азиатам с украинского сервера. Да и в америке не везде американская нода.
www.wipmania.com/ping/cache/chasy-bu.com/?c=c3c9370dd351543
Или гео непрнавильно работает? Также странно выглядит отдача азиатам с украинского сервера. Да и в америке не везде американская нода.
Нет не полетела, так как данный продукт находится в бета-тестировании, попадаются точки которые не совсем верно определяют место расположение посетителя. По нашему мнению это связано с обновлением IP адресов в базе GeoIP, периодически мы будем обновлять её чтоб исключать подобные моменты.
Вы верно заметили, что Азия перенаправляется в Украину, всё дело в том, что её мы не выделяли в отдельный сегмент, а просто направили на сервер по умолчанию в связи с договорённостью которая была между нами и нашим клиентом. Но на практике, и в дальнейшем мы сделаем полное разделение с большим количеством точек входа, между которыми и будет распределятся трафик.
Вы верно заметили, что Азия перенаправляется в Украину, всё дело в том, что её мы не выделяли в отдельный сегмент, а просто направили на сервер по умолчанию в связи с договорённостью которая была между нами и нашим клиентом. Но на практике, и в дальнейшем мы сделаем полное разделение с большим количеством точек входа, между которыми и будет распределятся трафик.
Вы б ещё ссылочку на патч дял bind дали — интересно посмотреть на реализацию.
Плохо понял, что будет, если изменения в БД будут внесены на slave-сервере.
Врядли это возможно. В схеме master-slave изменения могут вноситься только на мастере. Это, кстати, самая большая проблема всех гео решений. В случае, когда WEB приложение допускает внесение изменений, транзакция должна завершится. А в данном случае это возмодно только на мастере. Так что он — узкое место всей системы :(
В настройках сервера возможно прописать значения для auto_increment_increment и auto_increment_offset, данные опции позволяют оперировать данными с уникальными id для каждого сервера. Таким образом это можно обозвать либо мультимастер репликация либо просто расширенная репликация.
А кто будет разрешать конфликты? При одновременном изменении данных с разных серверов либо нужно жадть обновления на всех серверах БД (как поступить в случае недоступности одного из серверов?), либо допускать возможность, что пользователи разных узлов будут видеть разные данные.
забавно будет посмотреть на те позы из камасутры, в которые вам прийдется вставать, чтобы увеличить кол-во mysql нод больше чем первоначально заданное вами значение auto_increment_offset :)
Изначально было две ноды, и лишь спустя мы добавили 3-й сервер. При добавлении его мы не увидели проблем. Пришлось лишь перезапустить первый slave сервер. Как сказано в документации добавлять можно любое количество серверов. Возможно Вы сталкивались с подобной проблемой, нам было бы интересно узнать о методах решения этой проблемы.
я перепутал название опции. я имел ввиду auto_increment_increment.
я не сталкивался с этим и всячески буду этого избегать.
вот пример:
у вас стоит auto_increment_increment=2
1. на node1 добавляют запись. ID=1
2. на node2 добавляют запись. ID=2
3. на node2 добавляют запись. ID=4
4. на node2 добавляют запись. ID=6
4.5. все отреплецировалось…
5. вы меняете increment на 3 на node1
6. на node1 добавляют запись. ID=7. auto_increment=10
7. репликация от п.6. еще не прошла на node2.
8. на node2 добавляют запись. ID=8. auto_increment=10
9. репликация от п.6. еще не прошла на node2.
10. на node2 добавляют запись. ID=10. auto_increment=12
11. на node1 добавляют запись. ID=10. auto_increment=13
12. вы меняете increment на 3 на node2
13. репликация от п.6 и п.11 пришла на node2 и репликация встает из-за Duplicate key.
как решать данную проблему? я решения не знаю… подскажите — буду только рад :)
решение останавливать все ноды менять настройку и запускать все ноды обратно меня не устраивает в силу объективных причин, Особенно, если инстанс мускула стартует несколько минут.
Может в последних версиях мускула этот как-то изящно решается, но я не слышал.
я не сталкивался с этим и всячески буду этого избегать.
вот пример:
у вас стоит auto_increment_increment=2
1. на node1 добавляют запись. ID=1
2. на node2 добавляют запись. ID=2
3. на node2 добавляют запись. ID=4
4. на node2 добавляют запись. ID=6
4.5. все отреплецировалось…
5. вы меняете increment на 3 на node1
6. на node1 добавляют запись. ID=7. auto_increment=10
7. репликация от п.6. еще не прошла на node2.
8. на node2 добавляют запись. ID=8. auto_increment=10
9. репликация от п.6. еще не прошла на node2.
10. на node2 добавляют запись. ID=10. auto_increment=12
11. на node1 добавляют запись. ID=10. auto_increment=13
12. вы меняете increment на 3 на node2
13. репликация от п.6 и п.11 пришла на node2 и репликация встает из-за Duplicate key.
как решать данную проблему? я решения не знаю… подскажите — буду только рад :)
решение останавливать все ноды менять настройку и запускать все ноды обратно меня не устраивает в силу объективных причин, Особенно, если инстанс мускула стартует несколько минут.
Может в последних версиях мускула этот как-то изящно решается, но я не слышал.
Спасибо за комментарий, мы попробуем более детально рассмотреть данный вариант развития событий.
create table blabla (id bigint not null auto_increment);
и
auto_increment_increment = 65535
?
и
auto_increment_increment = 65535
?
1. bigint — это костыль и у него есть ряд неприятностей, описанных в доке.
2. впринципе решение, если добавить условие, что нод не может быть больше 65535. (ограничение на кол-во нод: 2^32)
2. впринципе решение, если добавить условие, что нод не может быть больше 65535. (ограничение на кол-во нод: 2^32)
1. а что за неприятности? медленней работает? я бегло просмотрел доку — не заметил ничего такого
2. что же вы там такое программируете, что вам не хватает 232 нод?
2. что же вы там такое программируете, что вам не хватает 232 нод?
1. ну как бэ да, ибо таких чисел в 32битной системе нет, поэтому реализация сделана в обход.
2. я не говорю, что мне не хватает, я говорю, что вы приравнивая auto_increment_increment=65535 сокращаете кол-во возможных нод с 2^32 до 65535. — просто сформулировал ограничение для системы.
2. я не говорю, что мне не хватает, я говорю, что вы приравнивая auto_increment_increment=65535 сокращаете кол-во возможных нод с 2^32 до 65535. — просто сформулировал ограничение для системы.
1. у нас сервера давно уже 64bit
2. виноват, 65536 = 216 :) но это вроде бы ограничение mysql на значение auto_increment_increment от 1 до 65535:
дока:
2. виноват, 65536 = 216 :) но это вроде бы ограничение mysql на значение auto_increment_increment от 1 до 65535:
дока:
auto_increment_increment and auto_increment_offset are intended for use with master-to-master replication, and can be used to control the operation of AUTO_INCREMENT columns. Both variables have global and session values, and each can assume an integer value between 1 and 65,535 inclusive. Setting the value of either of these two variables to 0 causes its value to be set to 1 instead. Attempting to set the value of either of these two variables to an integer greater than 65,535 or less than 0 causes its value to be set to 65,535 instead.
Рассмотрите казахстан как следующая страна размещения своего регионального сервера, спасибо.
А использование вашего Geo-DNS возможно в отдельном парядке, например если у компании (проекта) свои сервера?
CDN должен быть отказоустойчивым, это же серьезный инструмент для серьезных людей. Что будет, если у вас отвалится одна из нод?
На данном моменте тестирования при выходе из строя одной из нод, в ручном режиме происходит переключение региона на ближайший. В планах есть реализация механизма переключения в автоматическом или полуавтоматическом режиме.
Вы же понимаете, что DNS — такая штука, которая мгновенно не переключается, так что тут даже автоматика не спасет.
$20 в месяц — как-то дорого для трех нод выходит. И мне кажется, что в России имеет смысл российский CDN, а не общемировой
Еще одно решение для Bind: Geolocation-aware DNS with Bind
Идея использовать view понятна.
А вот насколько хорошо она работает с большим списком? Кроме того, вопрос failover — насколько быстро можно переключить на резервные. Т.к. если dns будет присылать адрес ближайшего, но не работающего сервера, то толку от этого мало.
А вот насколько хорошо она работает с большим списком? Кроме того, вопрос failover — насколько быстро можно переключить на резервные. Т.к. если dns будет присылать адрес ближайшего, но не работающего сервера, то толку от этого мало.
Списки можно сократить до регионов. Например в этом примере, с тремя серверами можно все страны заменить на номера регионов. К примеру
DE, GB, HU — 1;
RU, FI, EE — 2;
US, CA, MX, JP — 3
После этого сократить базу, получится компактная геобаза
А про failover — это уже вопрос реализации и постоянного мониторинга друг друга
DE, GB, HU — 1;
RU, FI, EE — 2;
US, CA, MX, JP — 3
После этого сократить базу, получится компактная геобаза
А про failover — это уже вопрос реализации и постоянного мониторинга друг друга
Хотя мне кажется, что для средних проектов — которым такое гео-распределение более важно, чем мелким статичным сайтам, или крупным(там уже свои встроенные решения можно) — лучше генерировать страницы в одном месте, а вот всю статику отдавать уже зонально:
static-us.example.com
static-ua.example.com
static-ru.example.com
static-hk.example.com
Решается проблема с базой данных и визуально страница грузится быстрее, потому как именно основной тормоз — это куча мелких картинок, js, css
static-us.example.com
static-ua.example.com
static-ru.example.com
static-hk.example.com
Решается проблема с базой данных и визуально страница грузится быстрее, потому как именно основной тормоз — это куча мелких картинок, js, css
Кстати, не будет работать, если у пользователей настроен не местный DNS провайдера, а например от гугла 8.8.8.8 и 8.8.4.4 или от Level3: 4.2.2.1 — 4.2.2.6
А гугл и L3 используют эникаст — отсюда невозможность определить страну юзера. Поэтому в нашей базе эти диапазоны как неопределенные.
А гугл и L3 используют эникаст — отсюда невозможность определить страну юзера. Поэтому в нашей базе эти диапазоны как неопределенные.
У вас всегда интересные и передовые решения, но поддержка… Я собственно с вас и спрыгнул из-за поддержки сначала на 3FN, а потом, после его кончины, на iWeb.
Про большие CDN, как реализуется гео-хостинг и ускорение приложений (баз данных) в них: lionet.livejournal.com/75636.html
Репликация в mysql идет одним потоком, слейв будет постоянно отставать от мастера. И да, то, что вы накуролесили патчем — решается шатно через view
Хотелось бы обратиться к двум моментам:
Насколько я смог осознать документацию по Unison, файлы обновляются не мгновенно — необходимо запускать unison по crontab. И работает он, проходя дерево файлов по одному и сравнивая состояние на двух серверах. Примерно как rsync, но только Unison двусторонний.
Как часто вы запускаете синхронизацию? Что если у пользователя 57 тысяч файлов (пример: Bitrix) — как долго она будет осуществляться?
Правильно ли я понимаю, что mysql slave используется для работы с базой локально на гео-точке и применяется для получения данных (select), а master — для сохранения данных (insert/update/delete)? Каким образом без изменения работы приложения вы заставляете, например, phpBB работать описанным образом — разделяя операции получения и сохранения данных?
Спасибо.
В первую очередь необходимо было найти систему, которая позволила бы копировать изменения в файловой структуре данных сайта. Причем синхронизировать данные нужно во всех направлениях, то есть когда изменения в файлы сайта вносятся с любой точки geo-хостинга. Для решения этой задачи нами была выбрана программа Unison.
Насколько я смог осознать документацию по Unison, файлы обновляются не мгновенно — необходимо запускать unison по crontab. И работает он, проходя дерево файлов по одному и сравнивая состояние на двух серверах. Примерно как rsync, но только Unison двусторонний.
Как часто вы запускаете синхронизацию? Что если у пользователя 57 тысяч файлов (пример: Bitrix) — как долго она будет осуществляться?
Система работает таким образом, что владельцу сайта не нужно изменять работу веб-приложения для работы с распределенной архитектурой.
Правильно ли я понимаю, что mysql slave используется для работы с базой локально на гео-точке и применяется для получения данных (select), а master — для сохранения данных (insert/update/delete)? Каким образом без изменения работы приложения вы заставляете, например, phpBB работать описанным образом — разделяя операции получения и сохранения данных?
Спасибо.
Привет конкурентам от имени CDNvideo :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Представляем нашу разработку – гео-хостинг