Если вы вырубить питание внезапно в середине записи транзакций, то не факт что запись успеет дойти до всех кэшов. Можно и битую таблицу получить, то есть отказ.
Сильно сомневаюсь, что MySQL в при COMMIT'е выполняет fsync().
Мы какие-то разные надёжности рассматриваем. Я — на полный отказ, вы — на частичный.
Нет, теперь вы выдернув из контекста мои фразы пытаетесь заставить меня такое сказать.
MySQL опирающаяся на FS не может быть надёжнее последней. В случае отказа FS, которую использует MySQL, MySQL откажет так же.
> под надёжностью я и все разумные люди всё-таки подразумеваем
Это уже ad hominem.
Хорошо. Когда у вас есть фундамент, а потом вы строите над ним дом, то фундамент является отдельным объектом, а дом без фундамента объектом не является (поскольку фундамент в доме неустраним без разрушения дома).
Тогда способность дома выполнять требуемые функции в заданных режимах и условиях применения зависит от способности фундамента, как составной части, делать это. То есть надёжность фундамента входит в надёжность дома (в том числе и при расчёте).
А если писать сплошным потоком прямо на диск постоянно, то ничего не повредится. И если взять хорошую FS — то ничего не повредится даже в этом случае. Как я уже сказал: A не может быть надёжнее B в случае если B использует один экземпляр A. Это же аксиома надёжности электрических цепей.
> во втором случае вы получите, что в таблице есть все данные, которые успели туда записаться до выключения. всё!
Здорово! Только данные там будут не все, и это уже отказ (потеря надёжности).
Ещё раз: у нас под надёжностью понимается вероятность неотказа на некотором промежутке времени. Вы используете своё, особое, определение надёжности, определяемое на журналиуремость и выделение блоков.
>и сравнивая надежность mysql на отдельном диске против надежности ФС на том же диске, мы получим, что mysql надёжней.
Слова, конечно, не интересны. Покажите, почему mysql надёжнее. Простая задача: предоставить механизм когда mysql работает после 100 запросов после крушения файловой системы.
UPD: Баг был потому, что ошибочно опознавался номер аргумента как специальный флаг, который должен делать переменную REF'ом, что и ошибочно делалось. В остальном всё правильно.
У слова «Надёжность на некотором отрезке времени» есть ровно одно значение: $1 — вероятность отказа за этот отрезок времени$.
Я лишь показал, что MySQL зависит от FS на настолько простом уровне, что даже InnoDB не сможет стартовать если /dev созданы неправильно. Не говоря уже о записи в файлы.
Потому, что MySQL опирается на FS. Если FS порушится и удалится конфиг-файл MySQL то он и не запустится.
Если FS откажет, то MySQL встанет боком и свистнет раком. Если MySQL откажет, то FS этого и не заметит.
Разве это не очевидный результат из теории вероятности? Более сложный компонент опирается на простой -> вероятность отказа сложного не меньше, чем простого.
Тогда нужно два gearman'а и или регистрировать клиента как worker'а — вся идея идёт на смарку (никто не гарантирует что во втором случае задача не попадёт на ту же машину).
InnoDB может работать без файловой системы
Everything is file. Нельзя работать с устройством без файловой системы: VFS и сотоварищи незримо присутствуют.
Сделайте перед запуском rm -f /dev/* и посмотрите, что получится у mysqld и InnoDB.
я оспариваю
Надёжность A не может быть выше надёжности B, если A в своей работе использует только один экземпляр B. А код FS у MySQL ровно один — одно ядро используется (mysql-cluster и подобные это другая история, они используют не один экземпляр FS).
Сильно сомневаюсь, что MySQL в при COMMIT'е выполняет fsync().
Мы какие-то разные надёжности рассматриваем. Я — на полный отказ, вы — на частичный.
Нет, теперь вы выдернув из контекста мои фразы пытаетесь заставить меня такое сказать.
MySQL опирающаяся на FS не может быть надёжнее последней. В случае отказа FS, которую использует MySQL, MySQL откажет так же.
> под надёжностью я и все разумные люди всё-таки подразумеваем
Это уже ad hominem.
Хорошо. Когда у вас есть фундамент, а потом вы строите над ним дом, то фундамент является отдельным объектом, а дом без фундамента объектом не является (поскольку фундамент в доме неустраним без разрушения дома).
Тогда способность дома выполнять требуемые функции в заданных режимах и условиях применения зависит от способности фундамента, как составной части, делать это. То есть надёжность фундамента входит в надёжность дома (в том числе и при расчёте).
Не читайте советских газет во время обеда. © Профессор Преображенский.
А если писать сплошным потоком прямо на диск постоянно, то ничего не повредится. И если взять хорошую FS — то ничего не повредится даже в этом случае. Как я уже сказал: A не может быть надёжнее B в случае если B использует один экземпляр A. Это же аксиома надёжности электрических цепей.
> во втором случае вы получите, что в таблице есть все данные, которые успели туда записаться до выключения. всё!
Здорово! Только данные там будут не все, и это уже отказ (потеря надёжности).
Ещё раз: у нас под надёжностью понимается вероятность неотказа на некотором промежутке времени. Вы используете своё, особое, определение надёжности, определяемое на журналиуремость и выделение блоков.
Слова, конечно, не интересны. Покажите, почему mysql надёжнее. Простая задача: предоставить механизм когда mysql работает после 100 запросов после крушения файловой системы.
У слова «Надёжность на некотором отрезке времени» есть ровно одно значение: $1 — вероятность отказа за этот отрезок времени$.
Я лишь показал, что MySQL зависит от FS на настолько простом уровне, что даже InnoDB не сможет стартовать если /dev созданы неправильно. Не говоря уже о записи в файлы.
Если FS откажет, то MySQL встанет боком и свистнет раком. Если MySQL откажет, то FS этого и не заметит.
Разве это не очевидный результат из теории вероятности? Более сложный компонент опирается на простой -> вероятность отказа сложного не меньше, чем простого.
Поэтому мой патч оказался не верным, однако баг был найден правильно. Интересно, помогло ли это майнтейнеру бага.
А как вы результаты забираете?
Everything is file. Нельзя работать с устройством без файловой системы: VFS и сотоварищи незримо присутствуют.
Сделайте перед запуском rm -f /dev/* и посмотрите, что получится у mysqld и InnoDB.
я оспариваю
Надёжность A не может быть выше надёжности B, если A в своей работе использует только один экземпляр B. А код FS у MySQL ровно один — одно ядро используется (mysql-cluster и подобные это другая история, они используют не один экземпляр FS).
А можно создать задание, отдетачится, а потом получить данные? Тоже, так сразу не нашёл.