MySQL в авиации

Да, тут нужна определенная смелость. Если накроется Oracle, то все разведут руками, ну уж если Oracle накрылся, то что поделаешь.

Если накроется MySQL все будут кричать о криворукой поделке.

Ну, вообще-то в этом бизнесе есть много разных ниш и задач. Возможно, что где-то подходит и MySQL. Лично я сомневаюсь, что MySQL ставят на критические участки, связанные с безопасностью полета. А вот склад или архив на MySQL - это можно. Тем более, что Oracle там - слишком дорого.

А почему это разведут руками , Оракл что какая-то крутая база или очень сложна в администрировании :)

Я бы Oracle двигал, или бы Postgres(если запросы не так быстро отдавать надо)...ну никак не mysql

Гы, а чем oracle сильно надежнее MySQL? Тем что если он рухнет, то потом поднимется из лога транзакций. Не произойдет потерь данных. Но время в которое он не работает, система все равно работать не будет. Если же требуется сделать систему которая _вообще_не_падает_, то тут разница между ними по надежности мне не очевидна.

А при чём тут безопасность полётов? " Due to the limited resources of the company, it also needed to be fairly straightforward in terms of installation, upgrading, and ongoing support and maintenance. Seamless integration with the Web server was also essential. " Им нужна база не для "управления" полётами, а для создания справочной службы, доступной через веб.

>Я бы Oracle двигал, или бы Postgres ..

лучше двигать телом

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

> Гы, а чем oracle сильно надежнее MySQL? Тем что если он рухнет, то потом поднимется из лога транзакций.

Тем что может встать раком (RAC Real Apliaction Cluster) :)
если самолет в окно не влетит простоя не будет.

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

и у них еще обязательно писать сочинения на тему left outer join on ... ?

п.с. вот если бы запросики посложнее он также быстро делал было бы гораздо интересней.

> а инкрементный бэкуп ? стедбай ? ну хоть что нибудь от порчи железа ?

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

теперь не летать этими самолетами

Ну когда ж народ за#бётся пресс-релизы MySQL AB читать? Очередной опус на тему "NASA переходит на MySQL", где мелким шрифтом написано, что на MySQL перевели задрипанный вебсайт и список рассылки.

На борт все равно никто ставить MySQL не собирается. Да и без предварительной сертификации FAA никто не сможет это сделать. А в некритическом применении - почему бы и нет.

> теперь не летать этими самолетами

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

> На борт все равно никто ставить MySQL не собирается.

А что нынче рекомендуется ставить на борт? Текстовые файлы? ;)

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

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

anonymous (*) (2003-09-03 16:19:50.14055):

> Мудак! Mysql используется для продажи и бронирования билетов,

Мудак! Нет в пресс-релизе ни слова о продаже билетов (кто ж это Мысклю доверит). Там этот расчудесный сервер всего лишь информацию о вылетах хранит.

да вот мудаки у нас тут в америке работают, однозначно уж postgres нужно было бы выбрать, но не как не mysql, mysql для простых задач!

Вопрос тем, кто развонялся на тему "САМОЛЕТАМ ТЕПЕРЬ НЕ ЛЕТАТЬ": нахера на борту самолета что-то делать с базой данных?

Ой, а давайте как в ru.prikol: Взлетит ли самолет? Только теперь к этой задаче добавляется условие "если на нем установлена MySql".

Я так понял,речь шла о чистой информационной службе - тоесть 99.99999% запросов на чтение. Тут вроде как и репликации не причем, залив хоть на сотню MySql серверов с одного центра. Тут и башлять за Oracle-овские навороты незачем. Нормально решение, только вот можно было бы ЕЩЕ проще. Apache+MM - нет проблем: в общей памяти тупую базу на какойнить библиотеки, коих оочень много. Вот такая штука жжужжала бы изумительно .... хотя детали надо проработать ;-)

> а каждый месяц платить всяким гениям

Гениям нужно заплатить всего один раз. Бездарностям - да, всю
жизнь будешь платить вне зависимости от выбранной БД.

> ЕЩЕ проще. Apache+MM - нет проблем

ну и мууудааакк... ;)

При сравнении МуСКЛа с Постгре не забывайте про Firebird :) Уже то, что в Мускле нет транзакций (по крайней мере в 3... версиях) говорит о его пригодности для ответственных задач :-)

> в Мускле нет транзакций (по крайней мере в 3... версиях)

А чего ты не вспомнишь 2.х версии? Или Oracle for DOS?
Такой то же был ;)

Ну и мудакиииии....

мискль, пэ-ха-пэ, слакварь, халява. - вот вас портрет тутошних пионэров.

> Репликация у mysql вроде есть,

вроде да, согласно доке, не пробовал :)

> а инкрементный бэкуп ?

Есть логи запросов, изменяющих содержимое базы. Делаешь серверу flush-logs, он начинает файл журнала с увеличенным номером. Это имеете в виду?

> стедбай ?

не знаю, а что что за зверь? :))

> ну хоть что нибудь от порчи железа ?

Вы пользуетсть СУБД, спасающей от порчи железа? Рад за Вас! Если у вас есть деньги на оракл, так, наверное, и рэйды можно поставить фирменные, а не доморощенные от ядра, а?

Про репликации Вы сами упомянули. А update-логи копировать по крону на машину в другом помещении. Рухнет сервак (сгорит, украдут :) - чревато простоем, но восстановить можно в сравнит. короткий срок. Репликации тоже спасают в такой ситуации, но как уже сказал - не довелось проверить.

> и у них еще обязательно писать сочинения на тему left outer join on ... ?

outer можно не писать. Есть другие формы записи, являющися sql-стандартом?

> п.с. вот если бы запросики посложнее он также быстро делал было бы гораздо интересней.

А! Эт тебе не вжик! - сказали суровые сибирские мужики. (после того, как японская бензопила взвигнула на рельсе). Сдались эти сложные запросы, которые бывают раз в году и (как правило) решаются, но не одним запросом, а несколькими. Все эти подселекты которых нет в mysql и без них не жизнь. Большей часть только и слышишь - фу! select во временную таблицу! Какая кака, мы так не могем!

Это что - цель такая писать многострочные запросы и что б было минимум sql-операторов?

MySQL InnoDB - отличная штука! Легко администриться, куча док, отлично оттестированный продукт. Оракл администриться очень нелегко - нужен штат админов - то есть если их содержать непозволительно то от неумения его администрить риски что что-то заработает не так очень высоки! То есть мне нравится MySQL :))! А с ораклом -- он для меня непрозрачен :(

> мискль, пэ-ха-пэ, слакварь, халява. - вот вас портрет тутошних пионэров.

Я знаю "пионеров", пишущих на "мискль, пэ-ха-пэ, слакварь"
с окладом $1200. В России. Привет пионервожатым ;)

> есть деньги на оракл, так, наверное, и рэйды можно поставить фирменные, а не доморощенные от ядра, а?

А что сэр имеет против ядреных рэйдов? А знает сэр, что ядреные
рэйды используются на очень профессиональных серверах в
комбинации с хардверным рэйдом?

ничего не имею против софт-рэйдов, я их ставил - нормально работают. Но полагаю, что хардварные надежнее, т.к. не зависят от работоспособности-загрузки-падения-взлома операционки - только они не всем по карману. Сэры, покупающие Ораклы, наверное, могут себе их позволить :)

hidden

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

Я тебе скажу от чего они зависят.
От наличия/отсутствия/кривизны их драйверов. И _очень_ сильно зависят.

еще можешь сказать - зависит от кривости кода прошивки контроллера. И ты на обычном скази контроллере будешь зависеть от его драйвера. обычного скази-контроллера. Другое дело, что поддержание самого рэйда на ядро не взваливают. Если сказевый диск грохнется на ходу, то ядро может застрять в модуле скази-диска (наблюдали), загадит весь messages, консоль, и ничего в этой ситуации не сделать, даже в систему не войти - будешь жать ресет. Хардварный рэйд, детектируя ошибку диска - выведет его из использования, система этого не заметит, только тормознется на дисковых операциях пока рэйд будет перестраиваться. Твое же дело после этого - подойти и сменить диск на котором горит индикатор ошибки. Софт рэйд хорош, пока диск не сыпанется, увеличить скорость при стрипе, миррор получить. А 5-й уровень на софте только для самоуспокоения, IMHO.

hidden

после того как mysql база ебанулась несколько раз на всего одной железке и после её чекалки вынесло десятки тыщ записей... ну его нахуй ставить такое чудо туда, где важна надежность. быстрый - да. но если бабки считать нужно до копейки... sybase крутится на десятках серверов и ничего не потерялось ни разу.

разъярённо: о какой вообще, нафиг, надёжности может идти речь в СУБД в которой штатно содержится команда REPAIR TABLE?

> Если сказевый диск грохнется на ходу, то ядро может застрять
в модуле скази-диска (наблюдали), [...] Софт рэйд хорош, пока
диск не сыпанется

Не понял. Вот стоит софтверный raid-1. Выдергиваем питание у
одного из дисков. Ругается - да, но работает. Вывод на консоль
во-первых можно убрать, а во-вторых закрепить за одной
физической консолью. Что-то у вас с руками совсем плохо.

> Хардварный рэйд, детектируя ошибку диска - выведет его из использования,

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

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

> разъярённо: о какой вообще, нафиг, надёжности может идти речь в СУБД в > которой штатно содержится команда REPAIR TABLE?

и что вас так раз'ярило? Присутствие e2fsck в операционной системе вас часом не бесит?

есть myisamchk, но для его использования необходимо иметь привилегии доступа к файлам базы на уровне ОС. REPAIR TABLE можно воспользоваться даже не имея shell-account на серваке, в случае хостинга, например, или админ базы != админ системы

2 sg > после того как mysql база ебанулась несколько раз на всего одной > железке

железку надо было сменить после первого раза. и как это у других все работает годами без сбоев? ;-) Самое простое сказать - поставили, а он упал, записи потерял. А какую версию брали, как компилили, какя ось была, че за железо - сами могли проколоться в 10-х мест, даж не сомневаюсь, что так и было. СУБД не без недостатков, но достало ваше хаяние по части надежности. Пока не очень то обоснованое.

hidden

Тому кто выступал что в MySQL не так давно (3 года) появились транзакции - да, потому что самой базе данных всего 12 лет! Postgres стартанул в 1984 году, транзакции появились только в Postgres95 , если не ещё позже.

Oracle версий 2 и 3 тоже была безтранзакционная.

Это история, и MySQL из всех этиз баз - самая молодая. И быстрее всех развивается!

> А про драйвера я сказал не зря. Ты много знаешь хардверных > рэйдов, нормально работающих в линуксе?

Нет, вообще не знаю. ПРосто не знаю, не потому что их нет. :)

Но - ты имееешь в виду SCSI-контроллер с функциями RAID-контроллера, я полноценный рэйд - полностью внешний, который сам содержит в себе контроллер и коннектится на обычный scsi-контроллер в компе, соответств. никакие спец-дрова не нужны. Такие знаю, например Infotrend. Вот это вещь которая будет жить своей жизнью и работать под любой ОС.

Про раэйд карту в pci-64 слот точно не знаю. Видели еще года три назад, что адаптек начал выкладывать драйверы под линукс, должны были уже обкатать их. Мы тогда не взяли, ушли на софтверный рэйд. Мне это не принцип. вернее я понимаю, что в большей части случаев надо будет ставить именно софтверный. Конторы офиц. использующие Оракл, нормальные хардовые рэйды себе поставят. И о вопросов о надежности СУБД в смысле самост. выкарабкивания из дисковых обрухов там не возникнет. Карты со своими драйверами под Линукс, их я с ядреным рэйдом не сравниваю. Вполне допускаю, что там полно и "поделок", абы как сваянных. Тока ради красного словца "raid-0,1,3,5".

>Присутствие e2fsck в операционной системе вас часом не бесит?

бесит. А тебя разве нет? Мои соболезнования. И твоей конторе.

>REPAIR TABLE можно воспользоваться даже не имея shell-account на серваке

Это-то причём? Хы-хы

>железку надо было сменить после первого раза. и как это у других все работает годами без сбоев?

такие базёхи наверное смешные. Вон впробывали ulog'овские базы хранить за пару месяцев - набегало что-то районе нескольких сот миллионов строк (до 10Г) - этот самый repair table пришлось вообще в крон вставлять. То индексы повалятся, то TIMESTAMP'ы съедут, то последовательности начнут дублированные значения генерить. Пистец короче. Плюнули на понты - стали валить всё текстовые файлы и закидывать в db2. Жизнь наладилась.

Дак это в базе с 1(одной) таблицей и 1(одним) пользователем - демоном и с одной операцией - вставкой. Последнее вдвойне обидно - для нетранзакционной СУБД такая нагрука должна быть самым коньком.

Я уж не говорю про оптимизатор (вернее его отсутсвие).

...нет. У mysql'я беспорно есть ниша - хранилище оперативной информации для первичной обработки и последующей передачи в хранилище, например (и в о бсуждаемом случае так скорее всего и есть - глупо гонять оракела в какихнибудь "кассах аэрофлота"), но каким же красноглазым пионером надо быть, чтобы пытаться приписывать mysql совершенно несвойственными ему достоинства да ещё пытаться сравнивать DBase-переросток с настоящей СУБД.

хм... Яп понял ещё сравнение MySQL/2003г c NW SQL/1993г. Это да. Почти одноклассники... хотя... Уж-что что, а репаирить битривовские таблицы тоже ни разу не приходилось...

<цитата> >Присутствие e2fsck в операционной системе вас часом не бесит?

бесит. А тебя разве нет? Мои соболезнования. И твоей конторе. </цитата>

Тогда наверное и утилиты для backup тоже бесят? И пользуетесь, видимо, СУБД, где никакого backup не предусмотрено?

<цитата> набегало что-то районе нескольких сот миллионов строк (до 10Г) - этот самый repair table пришлось вообще в крон вставлять. </цитата>

Есть у нас базы и поболее на mysql. Без проблем. Что, кстати, вам с bugs.mysql.com ответили?

<цитата> но каким же красноглазым пионером надо быть, чтобы пытаться приписывать mysql совершенно несвойственными ему достоинства да ещё пытаться сравнивать DBase-переросток с настоящей СУБД. </цитата>

Когда появляются слова "красноглазый", "пионер",(или еще хуже - пионЭр), "переросток", и т.д. - сразу возникают сомнения в профессонализме.. Такой лексикон обычно сопутствует слабому владению вопросом.

>>>Присутствие e2fsck в операционной системе вас часом не бесит?

>>бесит. А тебя разве нет? Мои соболезнования. И твоей конторе.

>Тогда наверное и утилиты для backup тоже бесят?

нет. О причине попробуй догадаться самостоятельно. Она очевидны.

>Что, кстати, вам с bugs.mysql.com ответили?

Хм. А что можно было у них спросить? "товарищи учёные у нас в подвале раздаётся странный стук. Объясните пожалуйста, что происходит"?

>Когда появляются слова "красноглазый",

то, это значит, что речь идёт о фанатичных чайниках. Не более.

В данном конкретном случае чайниковость выдаёт вообще попытка сравнения MySQL с другой СУБД без привязки к конкретным условиям, да ещё на самом уязвимом участке опен-соурсе СУБД -- надёжности, которая складывается из многих факторов, значительная часть которых лежит вообще вне самой СУБД -- например... эээ... да хоть... то, насколько хорошо файловая система может работать в условиях почти заполненной партиции.

Ну а фанатизм -- дак он вообще на поверхности - нет "лучшей СУБД". По определению. ...я вот лично, например, категорически против появления транзакций в MySQL - эта "фича" ему вредна и не нужна. Его задача - быстро принимать-модифицировать относительно небольшой объём данных при работе относительно многих пользователей. Реализация же транзакций, во-первых в её нынешнем виде убога, а во-вторых бъёт по главному достоинству MySQL - скорости модификаций базы. ...оно конечно, можно и плюнуть - мол не хочешь не пользуйся, но жалко усилий людей растрачиваемых только лишь, чтобы удовлитврить курики других красноглазых: "СУБД без транкзиций -- это не СУБД"(с)

...в то время, как позарез не хватает row-device'ов, снапшотов, SQL'я и оптимизтора. ...как впрочем и у прогрескуэля. Поэтому - не устаю повторять -- IBM DB/2 рулит :)

2dsa

>>Присутствие e2fsck в операционной системе вас часом не бесит?

>бесит. А тебя разве нет? Мои соболезнования. И твоей конторе.

Спасиб конечно. Хотя не замечал, что кто-то из нас страдал от этого, пожалуй ты первый будешь. Еще б меня за fsck'у спрашивали, что она раз в пол-года - год стартует на 21 монтировке :)

> Дак это в базе с 1(одной) таблицей и 1(одним) пользователем - демоном > и с одной операцией - вставкой. Последнее вдвойне обидно - для > нетранзакционной СУБД такая нагрука должна быть самым коньком.

Ты прав, странно. У меня нагрузка на сервак меньше, ulog'ов под гиг набирается месяца за 1-2, но и сервак не ахти какая круть - AMD 600, один старый винч 40 Mb/s и mysqld далеко не единственное, что на нем крутится. Зато клиентов по локали побольше, а не один процесс в системе. Да может ты сам и писал его, но тогда еще вопрос - где там бага - в клиенте или сервере? По крайней мере ничего из тобой перечисленного не отмечалось НИ РАЗУ. Так что поконкретней, пожалуйста - когда (в каком году :) это было, в какой системе/дистре, в какой версии mysql?

> ..чтобы пытаться приписывать mysql совершенно несвойственными > ему достоинства да ещё пытаться сравнивать DBase-переросток с > настоящей СУБД

Приятель, ты явно переутомился, твои глаза покраснее будут. Я про другие СУБД и слова не сказал, вчитывайся в посты внимательнее. Поскольку ты не помнишь то о чем не говорили, и не помнишь о чем шла речь повторюсь -

СУБД не без недостатков, но достало ваше хаяние по части надежности. Пока не очень то обоснованое.

Давай баги в студию, пока то что мы слышим иначе как гон не назовешь. Сезон однако. hidden

> А что можно было у них спросить? "товарищи учёные у нас в подвале > раздаётся странный стук. Объясните пожалуйста, что происходит"

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

<цитата> >Что, кстати, вам с bugs.mysql.com ответили?

Хм. А что можно было у них спросить? "товарищи учёные у нас в подвале раздаётся странный стук. Объясните пожалуйста, что происходит"? </цитата>

Ну тогда ваши рассуждения о багах выглядят гораздо менее убедительно. Я, кстати, не поленился, сходил на bugs.mysql.com, и поискал там (для примера) bugreport-ы со сьехавшими timestamp. Нет таких. Люди не жалуются на это.. У вас наверное был какой-то другой mysql. Не такой как у всех.

<цитата> , да ещё на самом уязвимом участке опен-соурсе СУБД -- надёжности, которая складывается из многих факторов, значительная часть которых лежит вообще вне самой СУБД -- например... эээ... да хоть... то, насколько хорошо файловая система может работать в условиях почти заполненной партиции. <цитата/>

Это оочень спорно.. Надежнось любой системы определяется качеством кода, в случае открытого кода (того же mysql) - количество людей, которые _вычитывают_ код - просто неизмеримо больше, чем любая лаборатория для тестировния в зарытой организации. В IB форумах до сих пор вспоминают, сколько было вычищено в коде IB, когда открыли его исходники.

Насчет СУБД на файловой системе. Файловая система может накрыться не только в условиях почти заполненых партиций. И тогда возникнут проблемы у любой СУБД, у которой данные лежат на FS. Или вы считаете, что в вашей DB2, если я создам tablespace, который using (file "/hren/znaet/gne/no/na/fs" 1000000M), то он будет как-то застрахован от разрушения при разрушении файловой системы? (это кстати к вопросу о средствах восстановления). Не нравится файловая система - делайте данные на device. Точно также и в mysql - innodb имеет возможность держать данные без файловой системы, просто на partition или на устройстве (например у меня на /dev/hdс).

<цитата>Реализация же транзакций, во-первых в её нынешнем виде убога, а во-вторых бъёт по главному достоинству MySQL - скорости модификаций базы. ...</цитата>

Ну ка, ну ка, это интересно, в чем убогость транзакций от innodb? Вас никто за язык не тянул, давайте теперь обьясняйтесь.

<цитата>...в то время, как позарез не хватает row-device'ов, </цитата>

видимо raw device имеется в виду.

>Ну ка, ну ка, это интересно, в чем убогость транзакций от innodb?

"читайте книги. Они рулёз"(с) Ключевые слова - уровни изоляции.

>Или вы считаете, что в вашей DB2, если я создам tablespace, который >using (file "/hren/znaet/gne/no/na/fs" 1000000M),

...и это "хрен-знает-где" лежит на старой-доброй jfs на старом-добром AIX'е...

>Дык, до дела доходит писать уже не о чем?

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

>Надежнось любой системы определяется качеством кода

какой наив... Хе-хе... -O9 или апгрейд libc(например) способно угробить даже hello world. Что у любителей "собирать руками" сплошь и рядом. Но это во-вторых.

Во-первых и в главных - в "надёжных" СУБД нет, не было и быть не может никаких REPAIR TABLE. Это не обсуждабельно.

> того, чтобы _реально_ могло помочь разработчикам естественно нечего. > ошибка плавающая, логов нет, коре-дампов нет. Чего людей напрягать > попустому?

Ну вообще детсад какой-то начинается. О плавающих ошибках тоже можно сообщать - как о факте случившегося. Если ты не единственный кто с этим сталкнулся, то разработчики получая баг-репоты от разных сторон не подтвержденные логами в любом случае напрягутся, им совсем не обязательно иметь 10 протокольных бумажек с отчетами, хотя если отчет будет подробный им фиксить будет много легче. На обычных форумах разработчиков такие вопросы решаются, только это редко происходит с людьми которые итак_все_знают :) Только обычно их потом носом тыкают в какую-нибудь элементарную мелочь совсем не там проблема наблюдается. Хотя обобщать не буду, но че-т ты так и не ответил ни на один вопрос - когда и как это происходило. Может под тем же aix'om. Тогда понятно, почему ты так об этом скромно умолчал. Только не надо задавать мне вопрос , чем мне не нравится AIX, не в нем дело, а в том, что затачивают mysql не под него.

> > Надежнось любой системы определяется качеством кода

> какой наив... Хе-хе... -O9 или апгрейд libc(например) способно > угробить даже hello world. Что у любителей "собирать руками" сплошь > и рядом. Но это во-вторых.

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

> Во-первых и в главных - в "надёжных" СУБД нет, не было и быть не > может никаких REPAIR TABLE. > Это не обсуждабельно.

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

<цитата> >Ну ка, ну ка, это интересно, в чем убогость транзакций от innodb?

"читайте книги. Они рулёз"(с) Ключевые слова - уровни изоляции. </цитата>

Мы то как раз читаем... А вот вы то, похоже - нет. innodb поддерживает все 4 уровня изоляции, описанные в стандарте. И называются они в innodb, кстати, по стандарту. Это камень в огород DB2, где вообще чехарда с названиями уровней изоляции, ANSI REPEATABLE READ в DB2 стал CS (cursor stability). А то, что в DB2 - repeatable read -- в ANSI SQL называется SERIALIZABLE.

В том числе.