cockroach не является SQL - от SQL там только оболочка. Идея CAP-теоремы противоречит ставит SQL в принципиальный конфликт распределенности.

У них там база на блоки побита и мини лидер на каждый блок. В итоге чуток обманули реальность

У них там база на блоки побита и мини лидер на каждый блок. В итоге чуток обманули реальность

да, и тем самым база не совсем ACID

но это противоречит концепции SQL-баз данных

А чтобы он не зафейлился, у меня есть staging для того же самого кода.

Запомните этот твит!

лол

да, и тем самым база не совсем ACID

Я не юрист, но вроде ацид. Сначала все локи берут потом все комитят

Я не юрист, но вроде ацид. Сначала все локи берут потом все комитят

буква C не соблюдается – по логике доступность данных должна быть гарантированно 100%-й а этого не происходит (что в общем-то разумно, ибо реально С мало кому нужен)

Я не юрист, но вроде ацид. Сначала все локи берут потом все комитят

афир (ну а кто же еще) писал, что там очень некислая привязка ко времени, как в спаннере

и что при смещении часов больше чем на N миллисекунд все летит в жопу

и что при смещении часов больше чем на N миллисекунд все летит в жопу

При смещении оси вращения диска тоже все летит в жопу. Жить то надо как-то :)

не, эт не аргумент

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

@not_logan "One of the headline features of CockroachDB is its full support for ACID transactions"

Статью не читал, но тут уж похоже классическое определение он здох или тупит по таймауту . На практике часы синхронизировать до единиц мс вполне реалистично

@not_logan то есть может быть ты таки что-то не понимаешь?

@not_logan, я тут случайно обнаружил, что ты добавил меня в свой блэклист. Скажешь хотя бы, почему? Я вроде тебе в личку не писал никогда.

Статью не читал, но тут уж похоже классическое определение он здох или тупит по таймауту . На практике часы синхронизировать до единиц мс вполне реалистично

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

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

и тараканчик как раз был помоему первой базой которая прошла его тесты

ну или одной из первых

но это говорит лишь о том что в документации нет вранья

По факту он каждый раз проверяет линеаризуемость одного регистра )

По факту он каждый раз проверяет линеаризуемость одного регистра )

потому что это чаще всего нарушается, да

@not_logan то есть может быть ты таки что-то не понимаешь?

возможно, я давно не освежал в памяти теорию. кокроуч, насколько я помню, как-бы acid, но не SQL. Насколько я помню, ACID у cockroach локальный. Но это память, надо проверять

возможно, я давно не освежал в памяти теорию. кокроуч, насколько я помню, как-бы acid, но не SQL. Насколько я помню, ACID у cockroach локальный. Но это память, надо проверять

https://www.cockroachlabs.com/tags/acid/

@not_logan, я тут случайно обнаружил, что ты добавил меня в свой блэклист. Скажешь хотя бы, почему? Я вроде тебе в личку не писал никогда.

это странно. Я не добавляю людей в блеклист просто так. Уберу.

они о себе пишут много, можешь две статьи прочитать

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

и описано как они доибваются каждой из буковок

ну вообще кокроуч, если я его правильно понимаю, вполне себе CP. A в нём очень частичное.

в двух статьях

@not_logan, я тут случайно обнаружил, что ты добавил меня в свой блэклист. Скажешь хотя бы, почему? Я вроде тебе в личку не писал никогда.

а что ты хотел мне сказать? Говори.

https://www.cockroachlabs.com/tags/acid/

почитаю, спасибо. Умнее умного стать вряд ли получится.

а что ты хотел мне сказать? Говори.

Нет, ничего конкретного, просто вызвал удивление факт.

Когда надо брать cockroach по сравнению с PostgreSQL + stolon скажем?

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

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

(либо время рассыпалось (((( )

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

Можно убить производительность и синкать wal на каждую транзакцию. У десяточки есть чудесная штука, когда оно комитит в слейва , там вообще потерять постараться надо

Можно убить производительность и синкать wal на каждую транзакцию. У десяточки есть чудесная штука, когда оно комитит в слейва , там вообще потерять постараться надо

если это про sync replica - то оно и в 9-ке есть

но стоит блин....

Можно убить производительность и синкать wal на каждую транзакцию. У десяточки есть чудесная штука, когда оно комитит в слейва , там вообще потерять постараться надо

проблема двух генералов

можно наоборот нахватать того, что на самом деле не закоммитилось

проблема двух генералов

генералы не про то, генералы не доверяют друг другу

окей, проблема одностороннего генерала (

??

хотя, не про доверие - это византийская проблема. проблема двух генералов именно в гарантированном подтверждении

проблема генералов в том, что среди участников могут быть злоумышленники.

распределенный консенсус в доверительной среде - гораздо проще.

проблема генералов в том, что среди участников могут быть злоумышленники.

это византийская проблема

да

а ты о какой? о_О

есть еще одна проблема про генералов?

она называется проблемой византийских генералов. А не двух. Я чуть мозг не вскипятил себе, пытаясь понять, что вы имеете ввиду

https://en.wikipedia.org/wiki/Byzantine_fault_tolerance

я об этой

а я о проблеме двух генералов, которые не могут договориться о том, во сколько атаковать, потому что нет "финального подтверждения"

https://en.wikipedia.org/wiki/Two_Generals%27_Problem

annnnddddd.... https://en.wikipedia.org/wiki/Byzantine_generals

и на русском - https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%B4%D0%B0%D1%87%D0%B0_%D0%B2%D0%B8%D0%B7%D0%B0%D0%BD%D1%82%D0%B8%D0%B9%D1%81%D0%BA%D0%B8%D1%85_%D0%B3%D0%B5%D0%BD%D0%B5%D1%80%D0%B0%D0%BB%D0%BE%D0%B2

annnnddddd.... https://en.wikipedia.org/wiki/Byzantine_generals

это действительно две разные задачи.

https://en.wikipedia.org/wiki/Two_Generals%27_Problem

спасибо!

да, действительно, спасибо

век живи - век учись

если это про sync replica - то оно и в 9-ке есть

Я в этом вопросе ОБС ретранслирую, так что может суровая реальность и не такая радужная, но в 9 оно менее полезно на практике т.к. там список подтверждений был жестко задан. В 10 появилась ANY когда говоришь, что мне любые N из M пусть подтвердят , что развязывает руки - можно любой слейв приземлить и мастер не застопорится

что лучше юзать weave или flannel ?

Короче, я к тому, что если у вас на слейв отправляется команда "закомить вот это", но сам мастер считает за коммит 1..N успешных ответов от слейва, то вполне реальна ситуация, когда слейв закоммитил, а мастер закрашился (и, кстати, почему двухфазные, трехфазные, семидесятифазные коммиты из классического SQL на самом деле не масштабируются). Для того, чтобы эта левая транзакция потом не была видна, нужен какой-то дополнительный слой контроля и, видимо, опрос всего кластера, чтобы вся эта байда хоть как-то приводилась к единой истории.

Короче, я к тому, что если у вас на слейв отправляется команда "закомить вот это", но сам мастер считает за коммит 1..N успешных ответов от слейва, то вполне реальна ситуация, когда слейв закоммитил, а мастер закрашился (и, кстати, почему двухфазные, трехфазные, семидесятифазные коммиты из классического SQL на самом деле не масштабируются). Для того, чтобы эта левая транзакция потом не была видна, нужен какой-то дополнительный слой контроля и, видимо, опрос всего кластера, чтобы вся эта байда хоть как-то приводилась к единой истории.

Так надо мастером здорового назначит

А кто в оставшемся кластере здоровый?

Кто не крашнулся и у кого счетчик транзакций больше

И мы таким образом влегкую теряем часть транзакций

Если откосило всех идущих впереди, то мы теряем ту историю, которые они успели записать

И мы таким образом влегкую теряем часть транзакций

кворум не соберется.

Тут надо баловаться с кворумом, что в постгре пока никак, но это тоже не спасет

если нод достаточное число для кворума - значит хотя бы одна из них имеет максимально возможный счетчик

И мы таким образом влегкую теряем часть транзакций

Так комит в слейвы синхронный, как потерять то?

Потому что слейв с фантомной транзакцией может тоже выбыть, следующий мастер может съесть одну транзакцию, затем тоже выбыть, а слейв с фантомной транзакцией - вернуться

И вот вам расхождение историй

Нету там синхронности. Только очередность, где он сначала применяется. Синхронностью это выглядит исключительно для клиента.

Потому что слейв с фантомной транзакцией может тоже выбыть, следующий мастер может съесть одну транзакцию, затем тоже выбыть, а слейв с фантомной транзакцией - вернуться

Ну, если был мастером но перестал, то Rm -rf

мы говорим про моргание сетки в пределах минут, если не секунд

мы говорим про моргание сетки в пределах минут, если не секунд

Говорили про краши :)

еще раз переспрошу, перебив такую оживленную беседу ;)

что лучше юзать weave или flannel ?

что лучше юзать weave или flannel ?

калико

network partition - это когда ты соседа не видишь, а почему - это не принципиально

Нету там синхронности. Только очередность, где он сначала применяется. Синхронностью это выглядит исключительно для клиента.

Ну,если слейв подтвердил, потом мастер у себя подтвердил, потом клиенту подтвердил - синхронность

network partition - это когда ты соседа не видишь, а почему - это не принципиально

я всё пытаюсь понять, откуда фантомные транзакции возникают

можно ещё раз кейс по стадиям?

Мастер может сделать две вещи: закоммитить у себя и разослать по слейвам и в обратном порядке. В случае, если ему требуется подтверждение от слейвов, то он может разослать коммит, но не успеть принять его. Таким образом на N слейвах данные будут, а в остальном кластере их не будет.

можно и вообще слейвам ничего не отсылать

тогда всё сломается само

не стараясь

D:

но я бы рекомендовал попытаться прочитать, как работает 2pc/3pc и raft/paxos.

Мастер может сделать две вещи: закоммитить у себя и разослать по слейвам и в обратном порядке. В случае, если ему требуется подтверждение от слейвов, то он может разослать коммит, но не успеть принять его. Таким образом на N слейвах данные будут, а в остальном кластере их не будет.

Ну так клиенту никто и не подтвердит такую траназкцию. А значит ничего и не было. Важно же не терять данные с точки зрения клиента

Ну так клиенту никто и не подтвердит такую траназкцию. А значит ничего и не было. Важно же не терять данные с точки зрения клиента

нет, важна консистентность в кластере

потому что если у вас разошлись истории, вы рискуете столкнуться с тем, что транзакция применится на половине кластера