Do not use MySQL, please!

[Alexander Oryol]

Ребята, я понимаю что не по адресу, но все же не могу не предостеречь
соратников по паровозу.

Ситуация:
Машина на AMD Athlon, CentOS 4.6 x86_64
apache-2.0.63, php-5.1.6 as mod_php, mysql-5.0.62
Недостатка памяти или производительности не испытывается. Приличный
такой аптайм у машины: 542 days.

Приложение на PHP, соединения с базой обычное, не persistent. Все
работает 2 года и тут хренась!
В какой-то момент mysql_insert_id() для определенной таблицы резко
перескакивает с 46хх на 57ххх (на порядок, я не ошибся).
Позже перестают вставляться записи в эту же таблицу, точнее
mysql_affected_rows() == 0 после операции вставки.

Проверка базы myisamchk сказала про эту таблицу:
warning: Datafile is almost full, 65500 of 65534 used
хотя записей там всего лишь 389 штук.
После repair все стало вновь хорошо, значения primary_key вернулись на
свое место...

Теперь сижу как тяжелым стукнутый и думаю, ЧТО ЭТО БЫЛО???


--
Alexander Oryol

[Anton Ageev]

2008/7/30 Alexander Oryol <eagle...@gmail.com>:

> Ребята, я понимаю что не по адресу, но все же не могу не предостеречь
> соратников по паровозу.

> Теперь сижу как тяжелым стукнутый и думаю, ЧТО ЭТО БЫЛО???

Таблицы типа MyISAM часто повреждаются (с разнообразными ошибками) в
случае некорректного завершения работы сервера.

Хотите надежности - используйте InnoDB.

--
WBR, Anton

[Alexander Oryol]

On 30 июл, 21:10, "Anton Ageev" <ant...@gmail.com> wrote:
> Таблицы типа MyISAM часто повреждаются (с разнообразными ошибками) в
> случае некорректного завершения работы сервера.

Аптайм у машины: 542 days. Все висит на бесперебойниках и генераторе.
Так что эта версия отпадает.


P.S. mysql из репозитория centosplus, последней доступной версии.


--
Alexander Oryol

[Alexey Kovyrin]

Если за все время существования базы НИ РАЗУ мускуль не крашился и
никто и никогда не делал ему kill -9, то, вероятнее всего, вы
наступили на оооочень редкий баг в myisam. Что делать - не юзать этот
идиотский storage engine и перестать писать такие идиотские заголовки,
которые ничего кроме вашего невежества в данном вопросе не показывают.

2008/7/30 Alexander Oryol <eagle...@gmail.com>:

--
Alexey Kovyrin
http://kovyrin.info/

[Alexander Oryol]

On 30 июл, 23:02, "Alexey Kovyrin" <ale...@kovyrin.net> wrote:
> Если за все время существования базы НИ РАЗУ мускуль не крашился и
> никто и никогда не делал ему kill -9, то, вероятнее всего, вы

MySQL ни разу не падал. Принудительно его никто не убивал (standalone
админ).

> наступили на оооочень редкий баг в myisam. Что делать - не юзать этот
> идиотский storage engine и перестать писать такие идиотские заголовки,

Я вот думаю, отвечать Вам в том же стиле, или промолчать?

> которые ничего кроме вашего невежества в данном вопросе не показывают.
>

> --
> Alexey Kovyrinhttp://kovyrin.info/

--
Alexander Oryol

[Oleg Andreev]

On 30.07.2008, at 23:26, Alexander Oryol wrote:

> Я вот думаю, отвечать Вам в том же
> стиле, или промолчать?

А поцчему Ви спгашиваете?

[Sergey Kostyushkin]

Да. Ковырин то еще грубиян. Готов поспорить в жизни он лузер, вот и
пытаеться здесь выделиться.
А насчет MySQL, советую сменить базу на PostgreSQL, по не которым
источникам, по производительности версия 8.3, даже обогнала MySQL, а
по надежности и говорить нечего.

[Max Lapshin]

2008/7/31 Sergey Kostyushkin <sergey.k...@gmail.com>

Да. Ковырин то еще грубиян. Готов поспорить в жизни он лузер, вот и
пытаеться здесь выделиться.

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

А насчет MySQL, советую сменить базу на PostgreSQL, по не которым
источникам, по производительности версия 8.3, даже обогнала MySQL, а
по надежности и говорить нечего.

Такие заявления без источников — умышленная провокация к флейму. Короче, это предупреждение.

[Max Lapshin]

2008/7/30 Alexey Kovyrin <ale...@kovyrin.net>

Если за все время существования базы НИ РАЗУ мускуль не крашился и
никто и никогда не делал ему kill -9, то, вероятнее всего, вы
наступили на оооочень редкий баг в myisam. Что делать - не юзать этот
идиотский storage engine и перестать писать такие идиотские заголовки,
которые ничего кроме вашего невежества в данном вопросе не показывают.

Алексей, ты чего на человека набросился?

[Dmytro Shteflyuk]

2008/7/31 Max Lapshin <max.l...@gmail.com>:

> Алексей, ты чего на человека набросился?

Вполне обоснованно набросился, потому что заголовок и правда
идиотский. MyISAM - морально устаревший engine, склонный ломать базу
по любому поводу. Не зря на смену ему сейчас пишут другой (Maria,
будет в 6.0), такой же быстрый, но умеющий восстанавливаться после
crash. Судить обо всем продукте (причем рекомендуя всем от него
отказаться) по движку, который рекомендуется использовать только если
вы знаете, что делаете (а топикстартер врядли осознавал это) -
глупость редчайшей воды.

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

ЗЫ. Alexander Oryol, do not use MySQL, please! It is too hard to learn for you!

--
Best regards, Dmytro Shteflyuk
http://kpumuk.info/

[Max Lapshin]

Дима, к тебе мои увещевания тоже относятся. Если человек просто не нравится, это ещё не повод здесь в группе
его оскорблять.

[Alexander Oryol]

On 31 июл, 12:32, "Dmytro Shteflyuk" <kpu...@kpumuk.info> wrote:
> Вполне обоснованно набросился, потому что заголовок и правда
> идиотский. MyISAM - морально устаревший engine, склонный ломать базу
> по любому поводу. Не зря на смену ему сейчас пишут другой (Maria,
> будет в 6.0), такой же быстрый, но умеющий восстанавливаться после
> crash. Судить обо всем продукте (причем рекомендуя всем от него
> отказаться) по движку, который рекомендуется использовать только если
> вы знаете, что делаете (а топикстартер врядли осознавал это) -
> глупость редчайшей воды.

Теперь факты:
1. Базы создаются в MyISAM до сих пор по дефолту.
2. За столько лет эта "редчайшая ошибка" не исправлена (не вылезала?)
3. До сих пор по дефолту базы создаются в latin1, а не в UTF8

Да, я действительно на простеньких проектах, не требующих транзакций,
при создании базы не задумываюсь о storage engine. Возможно зря.

Да, заголовок действительно эмоциональный, но посмотрел бы я на вас,
когда у вас на глазах, без аппаратных сбоев, крахов сервера, демона и
вообще на ровном месте порушилась база. При этом, замечу, это именно
_логический_ сбой, от которого нельзя застраховаться ни бекапом, ни
дополнительными проверками в коде. При поверхностном размышлении я не
придумал как от такого вообще застраховаться.

Лично для меня, по совокупности признаков, вывод ясен - держать MySQL
на расстоянии пушечного выстрела от production.

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

Для начала было бы неплохо узнать как на самом деле пишется PostgeSQL.

> ЗЫ. Alexander Oryol, do not use MySQL, please! It is too hard to learn for you!

Я так понимаю что "звездная болезнь" начинает поражать все больше и
больше трудящихся. Искренне жаль.

--
Alexander Oryol

[Closer]

[skipped]

При этом, замечу, это именно _логический_ сбой, от которого нельзя

застраховаться ни бекапом...[skipped]

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

P.S.
От себя скажу что не разобравшись в причине сбоя не стоило всё валить
на MySQL и призывать к отказу от него.
P.P.S.
Собственный опыт показывает что эмоции лучше сдерживать т.к. более
адекватный диалог получается. Сам видишь к чему твои эмоции привели,
вместо того чтобы понять в чём проблема все начали поливать друг друга
грязью.

[Alexander Oryol]

On 31 июл, 13:45, Closer <closer.m...@gmail.com> wrote:
> [skipped]
> При этом, замечу, это именно _логический_ сбой, от которого нельзя
> застраховаться ни бекапом...[skipped]
> ээээ... не понял юмора? Чем чаще делаешь бекап, тем больше шансов при
> какой либо проблеме (неавжно логический что-либо повредилось или
> физический) оказаться с довольно актуальным бекапом и данными в нём в
> руках.

Чем мне поможет бекап вчерашний, если у меня потерялась логическая
связность в сегодняшних данных?
Если у меня теперь некоторая часть _сегодняшних_ записей вида
something_id указывает в "никуда" ?
Естественно после чекания базы это несоответствие никуда не делось.
Более того, часть записей в этой битой таблице отсутствует.

> P.S.
> От себя скажу что не разобравшись в причине сбоя не стоило всё валить
> на MySQL и призывать к отказу от него.

Что значит не разобравшись? Все ясно, виновник найден.
Призывать? Да к черту, я всего лишь высказал свое мнение.

> P.P.S.
> Собственный опыт показывает что эмоции лучше сдерживать т.к. более
> адекватный диалог получается. Сам видишь к чему твои эмоции привели,
> вместо того чтобы понять в чём проблема все начали поливать друг друга
> грязью.

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

Ребята, давайте жить дружно.


--
Александр Орел

[Timur Vafin]

Alexander Oryol пишет:

> On 31 июл, 13:45, Closer <closer.m...@gmail.com> wrote:
>> [skipped]
>> При этом, замечу, это именно _логический_ сбой, от которого нельзя
>> застраховаться ни бекапом...[skipped]
>> ээээ... не понял юмора? Чем чаще делаешь бекап, тем больше шансов при
>> какой либо проблеме (неавжно логический что-либо повредилось или
>> физический) оказаться с довольно актуальным бекапом и данными в нём в
>> руках.
>
> Чем мне поможет бекап вчерашний, если у меня потерялась логическая
> связность в сегодняшних данных?
> Если у меня теперь некоторая часть _сегодняшних_ записей вида
> something_id указывает в "никуда" ?
> Естественно после чекания базы это несоответствие никуда не делось.
> Более того, часть записей в этой битой таблице отсутствует.

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

Ваш опыт ясен. Если у вас какое либо другое решение проблемы, какой то
комплекс превентивных мер, кроме как отказаться от mysql и перевести
проект на что то более другое?

--
Timur Vafin

http://blog.timurv.ru

[Max Lapshin]

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


Конструктив по поводу мускля такой (накушавшись проблем к этому пришли): ставится второй сервер и два мускля в режиме мастер-мастер. Причём между ними реплицируется база, пользовательские файлы и нагрузка. Таким образом необходимость бекапа падает.

Как известно, у бекапа есть ряд проблем: скорость его восстановления и гарантия того, что он полный. В случае с вторым мастером (на котором может быть не 50% нагрузки, а меньше), эти проблемы снимаются.

Однако, сам бекап всё таки не лишний.

[Timur Vafin]

Max Lapshin пишет:

> Конструктив по поводу мускля такой (накушавшись проблем к этому пришли):
> ставится второй сервер и два мускля в режиме мастер-мастер. Причём между
> ними реплицируется база, пользовательские файлы и нагрузка. Таким образом
> необходимость бекапа падает.

У меня был годовой опыт использования master-master для rails проекта.

За это время по причине обрыва связи или неправильно проведенных
мигретов, 3-4 раза возникали коллизии, которые кроме как руками
разрешить нельзя.

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

Макс, скажи, пожалуйста, как вы реализуете репликацию файлов, если
реализуете?

[Michael Bykov]

> Конструктив по поводу мускля такой (накушавшись проблем к этому пришли):
> ставится второй сервер и два мускля в режиме мастер-мастер.

Господа, я не сталкивался с такой технологией, объясните, пожалуйста,
в двух словах, что происходит при сбое? Откуда второй мастер знает,
что его данные верны, а у первого сбой? Есть автоматика или нужно
руками выяснять, кто виноват и что делать?

(Ясно, что обрывов связи можно избежать, если поставить два мускуля в
виртуальные машины рядышком на один хост)

М.

[Alexander Oryol]

On 31 июл, 14:48, "Michael Bykov" <m.by...@gmail.com> wrote:
> > Конструктив по поводу мускля такой (накушавшись проблем к этому пришли):
> > ставится второй сервер и два мускля в режиме мастер-мастер.
> Господа, я не сталкивался с такой технологией, объясните, пожалуйста,
> в двух словах, что происходит при сбое? Откуда второй мастер знает,
> что его данные верны, а у первого сбой? Есть автоматика или нужно
> руками выяснять, кто виноват и что делать?

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

В качестве временной меры перевел эту базу на InnoDB, а вообще сервис
уже переписывается на рельсы и pg.

--
Александр Орел

[Eugene Korbut]

On Thursday 31 July 2008 21:48:25 Michael Bykov wrote:

> (Ясно, что обрывов связи можно избежать, если поставить два мускуля в
> виртуальные машины рядышком на один хост)

А какой смысл вообще так делать - ставить 2 мускуля внутри 1 физического
сервера?
--
Eugene

[Max Lapshin]

2008/7/31 Timur Vafin <m...@timurv.ru>

У меня был годовой опыт использования master-master для rails проекта.

За это время по причине обрыва связи или неправильно проведенных
мигретов, 3-4 раза возникали коллизии, которые кроме как руками
разрешить нельзя.

У нас бывало что просто один из мастеров прекращал своё существование.
А как можно руками разрешить коллизии?
 

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

Макс, скажи, пожалуйста, как вы реализуете репликацию файлов, если
реализуете?

http://github.com/maxlapshin/attacheable при заливке файла копирует по scp файлы на другие мастеры.

[Maxim Kulkin]

31 июля 2008 г. 13:26 пользователь Alexander Oryol
<eagle...@gmail.com> написал:

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

[Timur Vafin]

Eugene Korbut пишет:

Иметь свежайший бекап

[Timur Vafin]

Michael Bykov пишет:

>> Конструктив по поводу мускля такой (накушавшись проблем к этому пришли):
>> ставится второй сервер и два мускля в режиме мастер-мастер.
>
> Господа, я не сталкивался с такой технологией, объясните, пожалуйста,
> в двух словах, что происходит при сбое? Откуда второй мастер знает,
> что его данные верны, а у первого сбой? Есть автоматика или нужно
> руками выяснять, кто виноват и что делать?

Чаще всего это проблема с primary keys.

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

[Eugene Korbut]

Каким образом? Если возникнет хардварная проблема - то она скорее всего
затронет обе виртуальные машины.
--
Eugene

[Timur Vafin]

Max Lapshin пишет:

> 2008/7/31 Timur Vafin <m...@timurv.ru>
>
>> У меня был годовой опыт использования master-master для rails проекта.
>>
>> За это время по причине обрыва связи или неправильно проведенных
>> мигретов, 3-4 раза возникали коллизии, которые кроме как руками
>> разрешить нельзя.
>
>
> У нас бывало что просто один из мастеров прекращал своё существование.
> А как можно руками разрешить коллизии?

Смотрим на каком сервере коллизия
Допустим, на slave:
show slave status\G;

Там видим что то вроде
Last_Error: Error 'Lock wait timeout exceeded; try restarting
transaction' on query. Default database: 'asb'. Query: 'UPDATE
marketer_site_traffics SET `marketer_site_id` = 13, `domain` =
'www.site.com', `traffic` = 8515252, `created_on` = '2007-08-09
00:00:00' WHERE `id` = 275482'

Останавливаем репликацию
stop slave;

Пропускаем запрос и запускаем репликацию
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; start slave;

Проверяем сколько еще осталось подкачать данных
show slave status \G;

Если 0 то все данные зареплецировались и можно открывать сервер к нагрузке.

Между прочим есть тулза, я до нее не добрался
http://blog.kovyrin.net/mysql-master-master-replication-manager/

>> Так же замечу, что репликация делалась с целью повысить доступность
>> приложения и увеличить сохранность данных.
>>
>> Макс, скажи, пожалуйста, как вы реализуете репликацию файлов, если
>> реализуете?
>
>
> http://github.com/maxlapshin/attacheable при заливке файла копирует по scp
> файлы на другие мастеры.

Окей, ясно.

[Alexander Oryol]

On 31 июл, 15:25, "Maxim Kulkin" <maxim.kul...@gmail.com> wrote:

> А я целиком поддерживаю Алексея. Надо знать и уметь то, чем пользуешься.
> А Алексендер спалился на всю рассылку.

Т.е. я должен был промолчать и позволить каждому наступить на
собственные грабли?
Хорошо что мы выяснили виновность MyISAM, может это кому-то будет
стимулом перейти на InnoDB.
Но каково думать что используешь "серьезную" базу и она заваливается в
одночасье?

Еще один пример, раз пошло такое дело. Где-то год назад. ReiserFS.
Отвалилось целое дерево подкаталогов. Без причины. Ни ребутов, ни
скачков по питанию, ничего. Просто пропадает кусок ФС. Тоже
промолчать? После этого случая перешли на XFS, т.к. ext3 не устраивает
своим быстродействием при многих подкаталогах и куче мелких файлов.
Я опять спалился?

--
Александр Орел

[Max Lapshin]

Так это для мастер-мастер конфигурации или для мастер-слейв?

[Dmitry Shaposhnik]

Райзер 3.6 или 4?

---
Best wishes, Dmitry

[Timur Vafin]

Max Lapshin пишет:

> Так это для мастер-мастер конфигурации или для мастер-слейв?

master-master

[Michael Bykov]

>> > А какой смысл вообще так делать - ставить 2 мускуля внутри 1 физического
>> > сервера?
>>
>> Иметь свежайший бекап
>
> Каким образом? Если возникнет хардварная проблема - то она скорее всего
> затронет обе виртуальные машины.

это не так важно, если у вас рейд. А вот в свете этого треда может
быть актуально. Сейчас виртуальные сервера стали удобны.

В общем, спасибо за тред.

М.

[Closer]

On 31 июл, 15:50, Alexander Oryol <eagle.a...@gmail.com> wrote:
[skipped]

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

Странное ты место выбрал для этого. Форум по Ruby&Rails. Это наверное
будет последнее место где я буду искать решение моих проблем с MySQL.
Я бы на твоём месте нашел более специализированный форум (ИМХО подошел
бы форум самих разработчиков MySQL) т.к. возрастает вероятность что
большее кол-во людей узнают об этой проблеме и будут её учитывать при
работе c MySQL.

> Хорошо что мы выяснили виновность MyISAM, может это кому-то будет
> стимулом перейти на InnoDB.

Ещё бы не хорошо. Хорошо что только MyISAM, а не весь MySQL.

> Но каково думать что используешь "серьезную" базу и она заваливается в
> одночасье?

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

> Еще один пример, раз пошло такое дело. Где-то год назад. ReiserFS.
> Отвалилось целое дерево подкаталогов. Без причины. Ни ребутов, ни
> скачков по питанию, ничего. Просто пропадает кусок ФС. Тоже
> промолчать? После этого случая перешли на XFS, т.к. ext3 не устраивает
> своим быстродействием при многих подкаталогах и куче мелких файлов.

Интересно в каком форуме ты поведал об этом? :) На канале об аниме?

[skipped]

P.S.
Сори за возможно излишнюю язвительность и за флейм. Я не со зла. :)

[Max Lapshin]

2Closer:
Прекращай. Это последнее предупреждение.

[Sergey Kostyushkin]

On 31 июл, 11:17, "Max Lapshin" <max.laps...@gmail.com> wrote:
> 2008/7/31 Sergey Kostyushkin <sergey.kostush...@gmail.com>
>
> > Да. Ковырин то еще грубиян. Готов поспорить в жизни он лузер, вот и
> > пытаеться здесь выделиться.
>
> Без личностей и без оскорблений людей, имя которых ты даже в гугле поленился
> набрать.
>
>
>
> > А насчет MySQL, советую сменить базу на PostgreSQL, по не которым
> > источникам, по производительности версия 8.3, даже обогнала MySQL, а
> > по надежности и говорить нечего.
>
> Такие заявления без источников -- умышленная провокация к флейму. Короче, это
> предупреждение.
Да осознал свою ошибку, ссылки ниже, думаю будет интересно почитать.
Поверьте я не хотел начать холивар но мне лично до сих пор не понятно
за любить мускул. Пробовал в деле обе базы, и пришел к выводу что
PostgreSQL куда более продуман. Разработчики базы вносят изменения
очень аккуратно. Иной раз перед обьявлением релиза стабилным,
тестирование продолжаеться более года.
Это так статейка, которых много:
http://www.samag.ru/art/07.2007/07.2007_02.html
Это насчет скорости, вобщето тестили железо, но походу и базы себя
показали:
http://tweakers.net/reviews/657/6

А если этого мало, я могу еще накидать, просто лень вспоминать где я
видел авторитетные тесты.

[Sergey Kostyushkin]

> Я уже не говорю про имбицила из соседней ветки, и о его
> необоснованному наезду и ничем не подтвержденными агитациями
> Postgress.

Ну, ну. Может еще письками померяемься.
Можем, не только письками но и знаниями померяться, перед публикой,
чтоб точно выяснить кто больше подходит под то слово которым вы меня
назвали. В рельсах я новичок но в остальном. не вопрос.
А наезд вполне обоснован. Ковырин явно нагрубил, и мне лично все равно
сколько раз его имя упоминает гугл. Я знаю точно что уважающий себя
человек просто промолчит там где считает вопрос идиотским. Если
ответил грубостью зачит сам регулярно о себе такое слышит (мое
субьективное мнение).

> Почему-то до сих пор MySQL является лидером среди СУБД для
> стартапов с миллионной посещаемостью в сутки.

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

Сори за оффтопик.

[Dmytro Shteflyuk]

2008/7/31 Sergey Kostyushkin <sergey.k...@gmail.com>:

> человек просто промолчит там где считает вопрос идиотским. Если
> ответил грубостью зачит сам регулярно о себе такое слышит (мое
> субьективное мнение).

Уважаемый, Вы необоснованно назвали человека лузером. Видимо, Вам
постоянно приходится такое слышать о себе? (по Вашей же логике).
--
Best regards, Dmytro Shteflyuk
http://kpumuk.info/

[Max Lapshin]

Парни, на мои увещевания вам всем наплевать?

[Dmytro Shteflyuk]

2008/7/31 Max Lapshin <max.l...@gmail.com>:

> Парни, на мои увещевания вам всем наплевать?

Макс, ребята, сорри. У меня все по теме личных разборок.

ЗЫ. А вот насчет проблемы репликации в условиях битых таблиц я бы еще
почитал :-)

[Sergey Kostyushkin]

Ну во первых, я лично не считаю что лузер оскорбление, назови вы меня
так я бы Вас проигнорировал, во вторых, он не впервые оскорбляет
людей.
По моей логике напрашивается мнение, что так же и его постоянно
оскорбляют. Отсюда и лузер.

On 31 июл, 17:16, "Dmytro Shteflyuk" <kpu...@kpumuk.info> wrote:
> 2008/7/31 Sergey Kostyushkin <sergey.kostush...@gmail.com>:

[Sergey Kostyushkin]

Нет, не наплевать. Я со своей стороны попытался исправится.
Ну, а флема уже похоже не избежать.