лолшто

неучтенный подводный камень, да, забыл. географическое удаленное расположение мастеров означает большие пинги и т.д. то есть синхронная репликация невозможна. у асинхронной есть большие минусы - в первую очередь ненадежность.

неучтенный подводный камень, да, забыл. географическое удаленное расположение мастеров означает большие пинги и т.д. то есть синхронная репликация невозможна. у асинхронной есть большие минусы - в первую очередь ненадежность.

если бы ты задал вопрос про геораспределенную штуку с транзакциями, я бы тебе все равно ответил, что транзакции не нужны, а штука на мускуле не взлетит

Barracuda. Compress. )

@AlexCAD легко. нет необходимости иметь точные данные на данную миллисекунду. если пик, клиент получит ответ все равно немедленно. а в БД попадет ну спустя секунды три, например

А, ясно, он вышел из конфы.

Из того что я видел в нагруженых системах. Они обычно решают кэшированием всей фигни на стороне приложения. В смысле всегда почти можно предсказать чего там приложению понадобится и выдать ему сразу весь пакет. Типа пусть возится.

Тогда уж к клиенту

Дык я и кэширую повсюду. Там задача уменьшить отклик юзеру

На текущем месте работы первое, что я сделал - выкинул кэширование запросов к БД... ну и mysql заодно

И как ты инвалидируешь кеш при нарушении лимитов ?

Но да наймите или хорошего CTO или DBA

"инвалидируешь кеш" вот это словообразование можно на более простом русском пожалуйста?

"инвалидируешь кеш" вот это словообразование можно на более простом русском пожалуйста?

Подозреваю что они сами мало понимают что обозначают слова которыми пользуются

Подозреваю, что вам тоже гугл поможет

Это типа меня так изыскано послали? Если вы не в силах обьяснить свой совет. То лучше помолчите тихонько в уголку. Тут не конкурс "кто напишет кирилицей больше странных слов"

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

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

Из того что я видел в нагруженых системах. Они обычно решают кэшированием всей фигни на стороне приложения. В смысле всегда почти можно предсказать чего там приложению понадобится и выдать ему сразу весь пакет. Типа пусть возится.

При следующем запуске приложения и узнает.

это какой-то праздник феерии, нельзя же так откровенно бросаться своей некомпетентностью

ВАСЯ, РЕБУТНИ СЕРВАК КЭШ УСТАРЕЛ

Это не про сервак а про приложение на клиентской стороне.

снимать нагрузку кэшированием на клиентской стороне?

Остановись :)

а кто им выдал бейдж "нагруженной системы"?

Там бывает понамешано такое что лучше не смотреть

Извиняюсь, возможно, был тут Игорь, писал всегда очень невежливо, но открыл глаза на интересные вещи.

А что здесь вообще происходит?

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

Завидую вашей доброте :)

Есть задача. Надо сделать максимально быстрой отклик в любой части планеты. Проект - рекламный трафик. Нужно записывать КАЖДЫЙ переход в базу, при этом делать это максимально быстро. В момент захода на сервер скрипт делает 2 запроса выборки данные и до трёх INSERT´ов. Сейчас сделано по принципу 1 мастер и 3 репликации. Мастер стоит в Ирландии, рядом сервер со скриптом, там код отдаётся за 9мс, второй слейв стоит в северной вирджинии, там время отдачи 1с, ещё один в мумбае, там примерно 2с. Задержка из-за INSERT´ов, это время максимальное, при всех трёх (один минимум). Задача: поднять локации по всему миру с минимальным откликом. В планах решить сразу несколько вопросов: 1. Подтянуть мастера к удалёным точкам 2. Сделать резервные копии на случай выпадения мастера по жести Выбранная схема: Мультимастер Актив-Актив, 3 штуки, в Ирландии, Сингапуре и Северной Вирджинии, репликации "все на всех", чтобы не было зависимости от "кольца". Далее у каждого мастера будут ещё свои слейв репликации по стандартной топологии звезды мастер-слейв актив-пассив. Не стал сразу всё делать, а вынашиваю идею уже полтора месяца и постепенно начитался и наслушался, но пора начинать. Постепенно понял, что мне не нужно реплицировать ВСЕ данные во все стороны. А именно, данные деляться на 3 типа: 1. Записи трафика во время прохода, один проход одна стрoка в таблице 2. Данные из админки, настройки компаний и прочая шелуха 3. Сводные данные трафика, раз в час идёт выжимка из первого типа данных, где групируется по источнику, чтобы по ним потом отдавать гибкую статистику. Первые данные надо раскидывать репликой Мультимастер Актив-Актив, это для резервного бэкапа и для других вычислений. Вторые данные в принципе по сути будут всегда писаться из админки, её я пока не планирую разносить, будет в одном месте, писать будет в один мастер (если тот не отвалится), потому не уверен, есть ли смысл её реплицировать по той же схеме. Третьи данные, это вообще жесткая такая нагрузка на базу, когда надо несколько миллионов, а может и несколько десятков миллионов прогнать математикой и записать. Потэтому не сильно хочется хочется грузить все мастера такой задачей, было бы интересней придумать схему, где скрипт, который это делает, опрашивал бы все 3 мастера на предмет загруженности ЦПУ, выбирал бы самый слакающий и на нём гнал, а остальным передавал row based репликацию. Либо же эту сводную базу не реплицировать, а каждый будет делать из своих данных, учитывая, что раз в час он обновляет не только часовую сводку но и немного предыдущей, то любые лаги репликации будут догоняться. В качестве ДБ сервера подумываю взять последнию Перкону, она базируется на последнем mysql, а значит там есть и многопоточная репликация и паралельная репликация. Какие подводные камни я уже наметил: авто инкреминенты надо юзать с настройкай шага и оффсета забыть про юник ключи в мастер-мастер схемах забыть про триггеры, процедуры и прочие безконтрольные элементы, которые могут сломать репликацию Не использывать запросы из разряда генерируемых сервером или основывающиеся на других данных, которые могут быть разными на разных мастерах. Помогите котику найти брод в этом океане подводных камней. Просьба: Не предлагайте уйти от мультимастера. Всё остальное преветствуется ^_^

Я в этом чате админ

Мультимастер актив-актив это же педерастия в чистом виде

Мать моя женщина

Отец твой мужчина, надо было вопрос сисадминам вбрасывать, не ожидал такого проёба времени.

Там будет тоже самое. Очевидно же универсального решения нет. И человека с подобным опытом ты если и встретишь, то врятли тебе его опыт поможет.