Здравствуйте, chaotic-kotik, Вы писали:
CK>Объясни тогда, зачем ZFS, Btrfs, Postgres (начиная с 9.3 кажется), тот же Hadoop, да что угодно вообще — считают чексуммы для страниц/блоков?
Не знаю. Судя по официальным докам, в SQL Server нет чексумм для страниц, что не мешает ему входить в тройку лидеров.
В процитированной вами части работы написано, что checksum помогает отловить ошибки сбоя записи. И, что "Checksum mismatches can be detected anytime a disk block is read".

CK>Вот я тут привел ссылку на исследование подтверждающее мои слова
Я не вижу никакого подтверждения. К полному исследованию доступа у меня нет, в процитированной части нет ничего про то, что контроллер может "не заметить" сбой CRC при чтении данных.
CK>Да нет, ты не об этом писал, ты писал про то что CAP — булшит. Хотя очевидно, что человек, который читал и понимает, осознает ее применимость.
Пока что я не видел применения CAP ни к чему, кроме рассуждений уровня "мы применяем NoSQL потому, что CAP".

CK>Потому что тема называется "Выбор NoSQL".
О, ну вот опять. NoSQL потому что CAP. Ещё раз поясню непонятную мне линию рассуждений: вы утверждаете, что High Availability — это возможность потерять до трети машин, потому что так вам рассказали в CAP. И следом же пишете, что CAP — она вообще не про availability.
А я вам пишу, что HA — это аптайм выше некоторого порога, например 99.99%. И потеря трети или четверти машин сама по себе ничего не значит, т.к. реальный процент аптайма будет зависеть от времени возврата их в строй.

CK>>>Можно иметь 100% аптайм, но не иметь возможности получить или записать данные.
S>>Нет, нельзя. По определению.
CK>Надо просто понять ((c) Sinclair), что запрос на запись может отвалиться по таймауту даже если с железом все ОК, нет ошибок конфигурации и всего такого.
У вас в голове явно есть одновременно два термина availability, с конфликтующими определениями. Availability означает способность выполнять запрошенные операции. То есть если операция отпала по таймауту — это значит, что система non-available. По определению. Поэтому невозможно иметь аvailability без возможности записи/чтения. А у вас получается "прибор работает, но не включается, потому что включается, но не работает".

CK>Ну это шутка была. Ну просто я не знаю как можно это всерьез обсуждать. Можно наверное было поговорить о том, что машина у меня на самом деле — пяти колесная, ведь я всегда вожу запаску в багажнике!
Запаска — плохой пример. Точнее, хороший пример плохой HA. Хороший пример — БТР. У него нет никаких запасок. Тем не менее, ему не страшны повреждения до трёх колёс (если с разных бортов) или 2х с одного.
Вот если бы мы обсуждали дизайн БТР, и вы бы мне впаривали шестиколёсную конфигурацию с двумя запасками (тот самый hot standby), то я бы парировал восьмиколёсной конфигурацией, т.к. она позволяет снизить нагрузку на каждую из шин и сделать их дешевле, при сохранении того же фактора избыточности.

CK>А при единичном сбое машина превращается в 4х колесную, она уже не HA, пока запаску обратно не положишь.
Конечно. А вы не знали? Или вы думали, что наличие запаски обеспечит вам 100% аптайм, независимо от времени ремонта пробитого колеса? Ну так вот нет, не обеспечит. Поэтому опытные собаководы берут с собой две запаски когда едут в такие места, где шиномонтаж занимает слишком много времени.

CK>Это я к тому, что все это — пустое словоблудство. Я тут вообще про кластер из ~100 машин рассказывал, с которым доводилось работать, откуда вообще взялась эта трех машинная конфигурация в обсуждении?
Она взялась из "минимальной HA" конфигурации. Вы же тут утверждали, что кластер из двух машин не является HA.
Ну давайте возьмём кластер из 300 машин. Предположим, MTBF у нас — 1 год, а MTTR = 1000 лет. Какова availability этого кластера при эксплуатации в течение неограниченного времени?
Возьмём двухмашинный кластер. Предположим, MTBF у нас по-прежнему 1 год, а MTTR — 5 минут. Какова availability этого кластера?