.
Я уже комментировал этот пример. Люди намеренно сделали split brain. Фейловера, как такового, не произошло — часть клиентов стали работать с отдельной системой.
S>>Вы не то объясняете. Кто вам сказал, что фейловер — это "штатная ситуация"? ANS>Иначе нет никакого смысла огород городить.
Ещё раз: все огороды и весь смысл сводятся к подъёму MTBF и availability уменьшению downtime. Я в прошлый раз недописал.
Если у вас сервер падает 100 раз в день — у него MTBF 864 секунды, или примерно 15 минут. Если RT, рекавери после фейла занимает 5 минут, то его availability = 66%. Если рекавери вовсе нету, то два таких сервера в режиме фейловера, очевидно, сдохнут через полчаса. "Три сервера с кворумом" — через 45 минут. И так далее — серъёзно нарастить надёжность в системах, не предусматривающих восстановление, невозможно. Ну поставите вы 100 серверов. Сдохнут через сутки.
Так вот, если рекавери занимает 5 минут, то 33% времени кластер работает в режиме одного сервера. Фейл оставшегося сервера в это время приведёт к фейлу, наблюдаемому клиентом. В простой модели сбоев, равномерно распределённых во времени, второй сервер тоже лежит 33% своего времени.
То есть, MTBF всей системы равно 45 минутам, а availability = 86%. Если вас это устраивает, то всё хорошо. Если нет — надо делать что-то ещё. Пока что видно, что из двух серверов с такой надёжностью получить приемлемую систему не получается. Потому, что формула даёт нам MTBF2 = MTBF1*MTBF1/RT, а доступность, A2 = (MTBF2-RT)/MTBF2 = 1 — (RT/MTBF1)^2. Или 1 — (1-A1^2).
Отсюда понятно, что надо либо добавлять ещё сервера, либо быстрее восстанавливать их, либо улучшать MTBF.
Некоторые товарищи делают регулярный фейловер — но не потому, что это "штатная ситуация", а для того, чтобы убедиться, что всё сработает корректно и избежать ситуации, когда slave система приходит в негодность.
ANS>Когда говорят о консистентности, то, естественно, рассматривают отдельные операции чтения/записи. Границы транзакций это просто те диапазоны в пределах которых операции чтения/записи могут перемещаться системой.
Нет. Вы неправильно понимаете транзакции. Транзакции — это группы операций, для которых есть гарантия сериализуемости.
Определение сериализуемости — возможность построить некоторый порядок, в котором как будто бы выполнялись транзакции. Понимаете, некоторый, а не какой-то конкретный. Конкретный порядок есть только с точки зрения одного клиента. Перечитайте определения.
ANS>В твоей модели операции могут уезжать за границы транзакций, что есть ерунда.
Не могут.
S>>Конечно же, в этом случае ACID не даст вам никаких гарантий. Sequential consistency соблюдается между отдельными транзакциями.
ANS>Всё таки. Маша сделала комит и звонит Пете. Петя комита не видит, проходит пол часа потом видит. По твоему это для ACID базы нормально?
Конечно. Потому, что математическая модель сериализуемости не подразумевает никаких звонков кому бы то ни было. У Маши и Пети есть ровно один способ общаться — это СУБД, с которой они работают. "Звонок" означает, что Маша произвела транзакцию, которую увидел Петя. То есть Маша произвела транзакцию T1 (основную), затем T2 (звонок).
Тогда есть гарантии того, что Петя будет видеть их в том же порядке.
А в ситуации, которую вы описываете (два независимых канала асинхронных коммуникаций) ожидать какого-то определённого порядка событий не стоит.
Простой жизненный пример: Маша положила денег на счёт Пете через свой мобильный телефон, и тут же ему звонит. Из очевидных соображений понятно, что Петя запросто может увидеть деньги на счету значительно позже, чем услышать Машин голос. И никакому ACID это не противоречит: система перевода денег выдала Маше подтверждение коммита. Это означает, что она обязуется доставить деньги Пете, ни больше, ни меньше. Это не означает, что деньги доставлены Пете. Sequential consistency означает, что если Маша положила Пете сначала 100, а потом 200 рублей, то Петя не может сначала увидеть на счету 200, а потом 300. Только 100, а потом 300. Ну, или сразу 300, если будет долго тупить.
ANS>>>>>Совсем нет. Твоя ошибка в концовке фразы "При двух серверах падение любого ANS>Уточню. Ошибка в том, что ты поставил слово "ведь". Правильно так: "При двух серверах падение [i]любого — останется только один сервер. Получается катастрофа, потому что...".
Потому, что система из одного сервера ненадёжна. Вы несколько раз повторили (странный) тезис о том, что при отказе слейва нужно запрещать коммиты. Это и есть отказ от доступности. Фейл одной машины привёл к отказу обслуживания клиента.
ANS>Как вроде я тебя агитирую. Постов, где люди делают фэйловер на 2-х серверах и асинхронной репликации и удивляются результату, в инете есть. Хотя даже одного примера достаточно, чтобы показать, что схема в общем случае не рабочая. И, что интересно, речь тут не об NoSql.
Удивление людей — штука плохопредсказуемая. Вот вы удивляетесь совершенно очевидным вещам про ACID.
Рабочесть схемы — штука довольно-таки условная. Вот вы, к примеру, отказываетесь оперировать характеристиками надёжности, а в бинарной модели консистентных систем не бывает в принципе.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>>Разница подробно описана в посте про hadr и фэйловер на 2х серверах: http://www.rsdn.ru/forum/philosophy/4715865.1.aspx
. S>Я уже комментировал этот пример. Люди намеренно сделали split brain. Фейловера, как такового, не произошло — часть клиентов стали работать с отдельной системой.
Намеренно? Ну-ну.
S>>>Вы не то объясняете. Кто вам сказал, что фейловер — это "штатная ситуация"?
Формулы skipped. Мне не ясно, если работа системы это не "штатная ситуация", то что тогда "штатная"?
ANS>>Когда говорят о консистентности, то, естественно, рассматривают отдельные операции чтения/записи. Границы транзакций это просто те диапазоны в пределах которых операции чтения/записи могут перемещаться системой. S>Нет. Вы неправильно понимаете транзакции. Транзакции — это группы операций, для которых есть гарантия сериализуемости.
Да-а. "Консистентность" неприменима к транзакциям целиком. Только к отдельным операциям. И границы транзакций (совместно с уровнем изоляции) просто ограничивают возможность переупорядочивания операций чтения/записи. Вот смотри (то что обычно эти статьи об ОЗУ и процессорах пусть тебя не смущает).
В sequental consistency допустим такой результат:
T1: W(x)1 T
------------------------------
T2: T R(x)0 T R(x)1
"T" я задал границы транзакций. Чтение "R(x)0" нужно для проверки констрейнта. Оно возвращает, что записи нет (она приедет позже). Результат — ничего не работает. Значит, нужна модель консистентности строже чем "sequental".
S>Определение сериализуемости — возможность построить некоторый порядок, в котором как будто бы выполнялись транзакции. Понимаете, некоторый, а не какой-то конкретный. Конкретный порядок есть только с точки зрения одного клиента. Перечитайте определения.
Это так, но к делу отношения не имеет.
ANS>>В твоей модели операции могут уезжать за границы транзакций, что есть ерунда. S>Не могут.
Могут.
S>>>Конечно же, в этом случае ACID не даст вам никаких гарантий. Sequential consistency соблюдается между отдельными транзакциями.
См. выше.
ANS>>Всё таки. Маша сделала комит и звонит Пете. Петя комита не видит, проходит пол часа потом видит. По твоему это для ACID базы нормально? S>Конечно.
Не знаю обрадует это тебя или огорчит, но твоё мнение в мире уникально.
S>А в ситуации, которую вы описываете (два независимых канала асинхронных коммуникаций) ожидать какого-то определённого порядка событий не стоит. S>Простой жизненный пример: Маша положила денег на счёт Пете через свой мобильный телефон, и тут же ему звонит. Из очевидных соображений понятно, что Петя запросто может увидеть деньги на счету значительно позже, чем услышать Машин голос. И никакому ACID это не противоречит: система перевода денег выдала Маше подтверждение коммита.
Вообще-то, такое поведение называется "eventual consistency". И свойственно оно именно NoSql системам. Это просто подтверждение моего тезиса о том, что большинство современных систем в целом (со всеми кешами, очередями и пр.) уже NoSql-системы, не смотря на то, что где-то там внизу есть ACID СУБД. И какие гарантии консистентности там есть — неизвестно. Скорее всего они potentialy consistent
Здравствуйте, Andrei N.Sobchuck, Вы писали: S>>Я уже комментировал этот пример. Люди намеренно сделали split brain. Фейловера, как такового, не произошло — часть клиентов стали работать с отдельной системой. ANS>Намеренно? Ну-ну.
Конечно.
ANS>Формулы skipped. Мне не ясно, если работа системы это не "штатная ситуация", то что тогда "штатная"?
С точки зрения клиента, штатная ситуация — это когда клиент выполняет запрос и получает результат. Нештатная — это когда клиент выполняет запрос, но результата не получает.
С точки зрения сервера штатная ситуация — это работа сервера. Нештатная — отказ сервера.
То, что кластер скрывает сбои сервера от клиента не означает, что теперь сервер можно безопасно перегружать. Это как противопожарная пропитка — она не означает, что после неё в деревянном домике можно будет разводить костры. Она всего лишь означает, что деревянный домик будет немножко медленнее гореть.
Точно так же и кластер — он понижает частоту наблюдаемых клиентом нештатных ситуаций. А вы почему-то думаете, что он позволяет их избежать совсем.
ANS>Да-а. "Консистентность" неприменима к транзакциям целиком. Только к отдельным операциям.
Нет. Только к транзакциям целиком.
ANS>"T" я задал границы транзакций. Чтение "R(x)0" нужно для проверки констрейнта. Оно возвращает, что записи нет (она приедет позже). Результат — ничего не работает.
Ошибочное утверждение выделено. Всё прекрасно работает. Какой именно предикат сломался в вашей программе?
Поймите, что консистентность — это всего лишь некоторая функция от данных. Например, сумма остатков на всех счетах в банковской системе всегда должна быть равна нулю.
Все гарантии ACID сводятся к тому, что если у нас любая транзакция сохраняет этот инвариант, то и любая последовательность этих транзакций будет его сохранять. ANS>Значит, нужна модель консистентности строже чем "sequental".
Такая модель может использоваться. Но никакого требования её иметь нету. Почитайте Бернстайна, там подробно написано про транзакции. ANS>Это так, но к делу отношения не имеет.
Ну конечно же имеет. ANS>>>В твоей модели операции могут уезжать за границы транзакций, что есть ерунда. ANS>Могут.
Вы фантазируете.
ANS>Не знаю обрадует это тебя или огорчит, но твоё мнение в мире уникально.
Вот это — вряд ли.
ANS>Вообще-то, такое поведение называется "eventual consistency". И свойственно оно именно NoSql системам.
Вообще-то нет. Eventual позволяет переупорядочивать апдейты от одного и того же источника. Sequential — нет.
S>>Потому, что система из одного сервера ненадёжна. Вы несколько раз повторили (странный) тезис о том, что при отказе слейва нужно запрещать коммиты. ANS>Он тебе кажется странным из-за странного понимания термина "консистентность".
Ну тогда давайте разъясним его, объяснив, почему не нужно запрещать коммиты при отказе мастера.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, dimgel, Вы писали:
D>Чтобы меня можно было подпустить, прошу разъяснить первый пункт. Из трёх содержащихся в нём утверждений понимаю только одно — про LB. Про master-master и что такое локальность можно поподробнее? Спасибо.
Локальность — это минимизация response time для клиентов. Допустим, Вася и Маша расположены на расстоянии в 1200 миллисекунд друг от друга (roundtrip). Это означает, что принципиально невозможно дать им обоим ендпоинт, до которого будет расстояние в 400 миллисекунд. Master-master означает, что мы можем дать им два разных (локальных) ендпоинта, каждый из которых будет отвечать своему клиенту с достаточной скоростью, например — 200 миллисекунд.
Понятно, что никакая схема со strict consistency не даст в master-master ничего полезного. Потому что если Машин сервер стоит в 200 мсек от Маши, а Васин — в 200мсек от Васи, то от Машиного сервера до Васиного будет минимум 800 мсек. Так что нет никакого способа, при котором в ответ на Васину транзакцию его сервер успеет договориться с Машиным сервером о распределённой блокировке, и вернуть Васе резулььтат. Это займет столько же или больше, чем напрямую сходить на Машин сервер.
Поэтому люди, которые хотят иметь master-master, должны отдавать себе отчёт в том, что они делают.
Можно пожертвовать строгой консистентностью, и реализовать ручное разрешение конфликтов (применяется в многих документо-ориентированных системах).
Можно развести workflow так, чтобы в каждый момент у каждого документа был только один владелец. С точки зрения теории, эта реализация длинных транзакций выражается в терминах коротких транзакций, в которой первоначальная транзакция (acquire document lock) может быть долгой, зато после неё многие транзакции в тот же документ выполняются быстро. Требует некоторых ограничений от предметной области — например, локальности зависимостей. То есть мы считаем, что изменения в документ не зависят от изменений, внесённых другими авторами в другие документы.
Это кажется тривиальным и очевидным; но для более общего случая неприменимо. Например, в классическом примере перевода денег со счёта А на счёт Б нам было бы нужно сначала получить "длинный лок" на оба счёта, после чего "быстро" провести перевод денег и отпустить счета. Понятно, что смысла в этом особого нет, т.к. мы не ожидаем провести много операций с этими двумя счетами, и накладные расходы на получение блокировки будут значительными.
Для коммутативных операций можно обойтись без жесткого порядка.
Например, если у нас есть общее поле счётчика чего-то (голоса на выборах), и на каждом избирательном участке выполняются транзакции типа count+=delta, то не обязательно захватывать глобальную блокировку этого счётчика. Локальные последовательности модификаций, полученных на каждом избирательном участке, можно синхронизовывать друг с другом в любом порядке; главное — синхронизовывать delta, а не count.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Локальность — это минимизация response time для клиентов. S>[...]
Понятно, спасибо.
S>Для коммутативных операций можно обойтись без жесткого порядка. S>Например, если у нас есть общее поле счётчика чего-то (голоса на выборах), и на каждом избирательном участке выполняются транзакции типа count+=delta, то не обязательно захватывать глобальную блокировку этого счётчика. Локальные последовательности модификаций, полученных на каждом избирательном участке, можно синхронизовывать друг с другом в любом порядке; главное — синхронизовывать delta, а не count.
В данном use case, я так понимаю, и единая база с репликой на каждом участке не нужна (и даже вредна, если говорить о безопасности).
А — ясно. Я думал ты что новое скажешь (как то, что видимость изменений после комита в ACID не обязательна), а у тебя всё свелось к банальному "эти системы настолько легко делать, что правильно никто не умеет".
ANS>>Формулы skipped. Мне не ясно, если работа системы это не "штатная ситуация", то что тогда "штатная"? S>С точки зрения клиента, штатная ситуация — это когда клиент выполняет запрос и получает результат. Нештатная — это когда клиент выполняет запрос, но результата не получает. S>С точки зрения сервера штатная ситуация — это работа сервера. Нештатная — отказ сервера.
Хм. Для меня нештатная ситуация это когда люди по зданию бегают махая руками над головой и крича "всё пропало". А штатная — когда всё спокойно. Вот как отказ винта в рейдё.
ANS>>Да-а. "Консистентность" неприменима к транзакциям целиком. Только к отдельным операциям. S>Нет. Только к транзакциям целиком.
Если рассматривать транзакции целиком, то ты как бы сакрализируешь процес выполнения запроса. В то время как рассмотрение отдельных операций чтения-записи объясняет почему сервер работает так и не иначе. Следовательно это более удобная модель, а значит правильная.
ANS>>"T" я задал границы транзакций. Чтение "R(x)0" нужно для проверки констрейнта. Оно возвращает, что записи нет (она приедет позже). Результат — ничего не работает. S>Ошибочное утверждение выделено. Всё прекрасно работает. Какой именно предикат сломался в вашей программе?
Уникальность, внешний ключ.
S>Поймите, что консистентность — это всего лишь некоторая функция от данных. Например, сумма остатков на всех счетах в банковской системе всегда должна быть равна нулю.
Мы это уже проходили. Консистентность в ACID vs. "модели консистентности" в CAP.
S>Все гарантии ACID сводятся к тому, что если у нас любая транзакция сохраняет этот инвариант, то и любая последовательность этих транзакций будет его сохранять.
Но цена этого настолько велика, что люди активно ищут способа помножить эти гарантии на ноль.
ANS>>>>В твоей модели операции могут уезжать за границы транзакций, что есть ерунда. ANS>>Могут. S>Вы фантазируете.
ANS>>Не знаю обрадует это тебя или огорчит, но твоё мнение в мире уникально. S>Вот это — вряд ли.
Тогда тебя не затруднит найти ссылки на такое мнение.
ANS>>Вообще-то, такое поведение называется "eventual consistency". И свойственно оно именно NoSql системам. S>Вообще-то нет. Eventual позволяет переупорядочивать апдейты от одного и того же источника. Sequential — нет.
В eventual упор на видимость изменений. in-order он или out-of-order не важно. Если рассмотерть твой пример с постановкой перевода в очередь, то окажется что сам писатель (тот кто разместил перевод) не видит результатов своих действий. Т.е. "W(x)1 R(x)0". Sequential такое запрещает.
S>>>Потому, что система из одного сервера ненадёжна. Вы несколько раз повторили (странный) тезис о том, что при отказе слейва нужно запрещать коммиты. ANS>>Он тебе кажется странным из-за странного понимания термина "консистентность". S>Ну тогда давайте разъясним его, объяснив, почему не нужно запрещать коммиты при отказе мастера.
Это при синхронной репликации. Иначе бы она не называлась синхронной. Что будет при асинхронной — я давал ссылку
. Как можна "весь траффик автоматически переключается в работающий датацентр" при "потеря связности между датацентрами может составлять часы" мне лично не понятно.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Хм. Для меня нештатная ситуация это когда люди по зданию бегают махая руками над головой и крича "всё пропало". А штатная — когда всё спокойно. Вот как отказ винта в рейдё.
Мы же в техническом форуме. Тут лучше иметь более строгие критерии штатных и нештатных ситуаций, чем руки и крики.
ANS>Если рассматривать транзакции целиком, то ты как бы сакрализируешь процес выполнения запроса. В то время как рассмотрение отдельных операций чтения-записи объясняет почему сервер работает так и не иначе. Следовательно это более удобная модель, а значит правильная.
Я не понимаю, что такое "сакрализируешь". Не надо ничего изобретать — почитайте Бернстайна, он очень подробно разжёвывает, что такое транзакция, и как она работает. Ваша модель просто некорректна, поэтому неважно насколько она удобна.
ANS>Уникальность, внешний ключ.
Там нет никакой уникальности или внешнего ключа. В вашей транзакции вообще нет операций записи, которые могли бы сломаться. То, что вы ожидаете, что результат, полученный вами в пределах транзакции, останется действительным и после коммита — это ваши личные тараканы.
ANS>Мы это уже проходили. Консистентность в ACID vs. "модели консистентности" в CAP.
Вы это как-то плохо проходили.
ANS>Но цена этого настолько велика, что люди активно ищут способа помножить эти гарантии на ноль.
ANS>Тогда тебя не затруднит найти ссылки на такое мнение.
Почитайте учебники. Бернстайна например.
ANS>В eventual упор на видимость изменений. in-order он или out-of-order не важно.
Это вы откуда взяли?
S>>Ну тогда давайте разъясним его, объяснив, почему не нужно запрещать коммиты при отказе мастера. ANS>Это при синхронной репликации.
Вы не ответили на вопрос. Допустим, у нас синхронная репликация. Почему не нужно запрещать коммиты при отказе мастера?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали: S>Мы же в техническом форуме. Тут лучше иметь более строгие критерии штатных и нештатных ситуаций, чем руки и крики.
Ок. Отказ винта в рейде это уже нештатная ситуация?
S>Я не понимаю, что такое "сакрализируешь".
Транзакция у тебя работает, а как — не важно. Хотя по сути каждая транзакция состоит из множества отдельных операций чтения/записи в разделяемую память. Это можно игнорировать и работать с идеальной моделью, но только до определённого предела.
S>Не надо ничего изобретать — почитайте Бернстайна, он очень подробно разжёвывает, что такое транзакция, и как она работает. Ваша модель просто некорректна, поэтому неважно насколько она удобна.
Моя модель — это какая?
ANS>>Уникальность, внешний ключ. S>Там нет никакой уникальности или внешнего ключа. В вашей транзакции вообще нет операций записи, которые могли бы сломаться.
"Там" — это где? Я повторю вопрос. Есть две последовательные транзакции в которых вставляется по одной строчке. Как во второй транзакции проверить UNIQUE констрейнт если результат первой вставки станет видимым позже?
ANS>>Мы это уже проходили. Консистентность в ACID vs. "модели консистентности" в CAP. S>Вы это как-то плохо проходили.
Я тебя дал ссылку на статью где рассказывают о том, что такое "консистентность" (которая в CAP). Ты упорно ссылаешься на "консистентность", как определено в ACID. Упорство это достойно, но утомляет.
ANS>>Тогда тебя не затруднит найти ссылки на такое мнение. S>Почитайте учебники. Бернстайна например.
Ты точно помнишь о чем мы тут говорим? А то меня терзают смутные сомнения...
ANS>>В eventual упор на видимость изменений. in-order он или out-of-order не важно. S>Это вы откуда взяли?
Из определения.
S>Вы не ответили на вопрос. Допустим, у нас синхронная репликация. Почему не нужно запрещать коммиты при отказе мастера?
Очевидно, потому что slave никуда ничего не реплицирует.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Ок. Отказ винта в рейде это уже нештатная ситуация?
В некотором смысле да. Если его не заменить в течение регламентированного времени, то от "надёжности" рейда быстро останутся только воспоминания. ANS>Транзакция у тебя работает, а как — не важно. Хотя по сути каждая транзакция состоит из множества отдельных операций чтения/записи в разделяемую память. Это можно игнорировать и работать с идеальной моделью, но только до определённого предела.
Это не нужно игнорировать. Нужно просто разобраться в том, как работают шедулеры операций для того, чтобы обеспечить требования сериализуемости транзакций.
ANS>Моя модель — это какая?
Модель, в которой транзакции обозначают границы перемещения операций во времени.
Модель, к которой все границы транзакций привязаны к некоему источнику времени, общему для всех участников распределённой работы.
ANS>"Там" — это где?
В вашем протоколе транзакций. Перечитайте своё сообщение внимательно. У вас три транзакции, в двух из которых есть только чтение.
ANS>Я повторю вопрос. Есть две последовательные транзакции в которых вставляется по одной строчке.
Что вы называете "последовательными" транзакциями?
Если они выполняются с одного клиента, то у него есть гарантии sequential consistency, т.е. порядок выполнения изменений детерминирован.
Если две транзакции выполняются с разных клиентов, то вопрос об их последовательности весьма условен.
ANS>Как во второй транзакции проверить UNIQUE констрейнт если результат первой вставки станет видимым позже?
Очевидно, выполнив чтение перед записью.
Требования сериализуемости транзакций в ACID означают, что результат выполнения обеих транзакций будет эквивалентен некоторому последовательному их выполнению.
То есть, одна из транзакций будет обязана откатиться. Но кто из них первая, а кто вторая, сказать заранее невозможно. ANS>Из определения.
И чем тогда она отличается от sequential consistency S>>Вы не ответили на вопрос. Допустим, у нас синхронная репликация. Почему не нужно запрещать коммиты при отказе мастера? ANS>Очевидно, потому что slave никуда ничего не реплицирует. О, как здорово. Ну так и мастер без слейва ничего никуда не будет реплицировать. Сосредоточьтесь и ответьте, в чём же тут сакральная разница?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>В некотором смысле да. Если его не заменить в течение регламентированного времени, то от "надёжности" рейда быстро останутся только воспоминания.
"В некотором смысле" — это строгий критерий для технического форума?
ANS>>Как во второй транзакции проверить UNIQUE констрейнт если результат первой вставки станет видимым позже? S>Очевидно, выполнив чтение перед записью.
Так вот, при "sequential consistency" БД не обязана вернуть результат закомиченой вставки.
S>То есть, одна из транзакций будет обязана откатиться. Но кто из них первая, а кто вторая, сказать заранее невозможно.
Для того чтобы что-то откатить нужно увидеть, что в БД есть некие данные с которыми транзакция конфликтует. Если при их наличии система гарантировано эти данные возвращает это строгая консистентность. Если не гарантировано, то уровень слабее строгого.
ANS>>Из определения. S>И чем тогда она отличается от sequential consistency
Очевидно тем, что "sequential" — определение, а "eventual" — базворд.
S> О, как здорово. Ну так и мастер без слейва ничего никуда не будет реплицировать. Сосредоточьтесь и ответьте, в чём же тут сакральная разница?
Я уже отвечал, но повторюсь. Если при репликации не гарантируется, что закомиченные данные будут и в реплике, то это не синхронная репликация.
... ANS>>Как во второй транзакции проверить UNIQUE констрейнт если результат первой вставки станет видимым позже? S> S>Очевидно, выполнив чтение перед записью. S>Требования сериализуемости транзакций в ACID означают, что результат выполнения обеих транзакций будет эквивалентен некоторому последовательному их выполнению. S>То есть, одна из транзакций будет обязана откатиться. Но кто из них первая, а кто вторая, сказать заранее невозможно.
...
извините что влезаю. Мне вот стало интересно как можно вставить перепринятие решения внутрь уже закоммиченной транзакции которая будет проигрываться из лога в будущем. То есть есть Т1 она прочитала Х — не нашла его — на клиенте решила что можно писать — записала Х — закоммитилась. Приходит Т2 и делает то же самое и тоже успешно так как Т1 временно уехала. Теперь вопрос а кто именно будет определять что Т1 надо откатывать когда она заново применяется из лога после того как завершилась Т2?
Здравствуйте, SleepyDrago, Вы писали:
SD>извините что влезаю. Мне вот стало интересно как можно вставить перепринятие решения внутрь уже закоммиченной транзакции которая будет проигрываться из лога в будущем.
Тут дело не в том, что из лога. А в зависимостях между транзакциями.
Если она есть — то ACID реально становится источником "общего времени".
Например, у нас все клиенты выполняют такой стейтмент (в implicit auto-commit transaction):
update timer set timer.value = timer.value + 1 output inserted.value
Выдаваемые ими значения будут определять последовательность транзакций. При этом номера будут одинаково видимыми для всех клиентов.
Если Маша закоммитила свою транзакцию и получила 5, то Петя не может тоже получить 5. И меньше, чем Маша, он получить тоже не может.
Вася, который выполняет просто select timer.value в цикле, будет наблюдать неубывающую последовательность (в силу sequential consistency). Но он, в отличие от Пети, не имеет гарантий того, что полученное им значение соответствует тому, которое получил Вася минуту назад.
Понятно, что мы не можем взять назад обещание, данное Маше при подтверждении её коммита. Но мы можем предотвратить транзакцию Пети от завершения. Там есть несколько стратегий. В оптимистичной блокировке, например, Петя вполне может получить 5, но при попытке коммита получить исключение.
В пессимистичной блокировке всё несколько меняется: если мы позволяем себе вести диалог в процессе транзакции, то уровень гарантий меняется в зависимости от выставленного уровня изоляции (или детального контроля над блокировками). В частности, Вася, получающий shared lock с автоотпусканием (read commited), рискует увидеть stale data. А если он попытается получить exclusive lock, то СУБД будет обязана дождаться синхронизации всего.
Поэтому так делать не рекомендуют: это, фактически, позволяет одному невежливому клиенту остановить работу всего кластера.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>"В некотором смысле" — это строгий критерий для технического форума?
Я вам привёл критерии этого некоторого смысла. Вам их недостаточно?
S>>Очевидно, выполнив чтение перед записью. ANS>Так вот, при "sequential consistency" БД не обязана вернуть результат закомиченой вставки.
А, понятно. Да, в некоторых случаях ACID приходится давать более сильные гарантии, чем sequential. Грубо говоря, чтения могут отдавать stale data, но как только у нас появляется зависимость по записи, придётся сериализовывать. Либо отказывать в коммите тем, кому не повезло.
ANS>Очевидно тем, что "sequential" — определение, а "eventual" — базворд.
S>> О, как здорово. Ну так и мастер без слейва ничего никуда не будет реплицировать. Сосредоточьтесь и ответьте, в чём же тут сакральная разница? ANS>Я уже отвечал, но повторюсь. Если при репликации не гарантируется, что закомиченные данные будут и в реплике, то это не синхронная репликация.
Вы имеете в виду, что при синхронной репликации при отказе слейва можно продолжать принимать коммиты на мастере?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, gandjustas, Вы писали:
G>Убери memcached, ситуация изменится? Ни разу. Это общий вопрос распределенных систем — как только ты получил данные из внешней системы, они перестали быть актуальные.
При данном подходе возможна такая аномалия: мы можем получать данные в обратном хронологическом порядке. То есть сначала получили свежие данные, потом еще раз обратились и получили более старые данные в сравнении с тем, что было первый раз. И вообще не понятно, зачем это все надо, если приличные СУБД сами умеют кешировать не хуже memcached, но с учетом ACID.
И это еще без учета кластеризации. С ней в случае с memcached вообще полный капец наступает в плане каких-либо гарантий.
