в автоматическом режиме dev.mysql.com/doc/refman/5.0/en/innodb-backup.html
откатывает незавершенные транзакции на момент падения, это даже с отключенными бинарными логами.
А с бинарными логами подобное можно сделать с контрольной точки, в них лог всех действий в базе.
Поднятие из дампа только в случае физического повреждения данных, ну или с холодного бекапа, смотря что применялось. Плюс при наличии бинарных логов, можно восстановиться до последней успешной транзакции перед падением.
Механизм схож с тем, что делает Оракл в случае «неожиданной» остановки, что в общем то и не удивительно =)
приставка все таки специализированная железка, с хардварным чипом с поддержкой декодирования видео. Линукс там крутится на каком нибуть простеньком MIPS в уголке и занимается только рисованием менюшек на экране.
а я не говорил про каши быстрого приготовления, которые разбавил и ешь. Я про обычные крупы, покупаю на вес на рынке или в магазине. Просто если не варить сложныю кашу — с мясом или овощями, которые требует до 1-1.5 часов на варку, то обычно крупа в молоке или воде разваривается как раз за 15-20 минут, максимум полчаса. Потом в тарелку, маслица сливочного и ням-ням =)
Да и «сухой» кашей получается только гречка, просто потому что есть ее как суп не вкусно, в нее побольше масла, ну или как в детстве молока можно добавить, но это на любителя =)
К рецептам я бы еще каши добавил разные — гречневую, рисовую, дружбу, различные сборные — типа «5 злаков», и конечно же офсянку. Для любителей можно мюсли. Готовиться быстро на воде или молоке (с утра пока на работу собираетесь за 15-20 минут вполне можно сварить), здоровый сытный завтрак-обед — полный набор витаминов, клетчатки и микроэлементов ;-)
С вечера можно сложные каши варить — например овсянку с тушенкой, или гречку с мясом.
я ж говорю Европе еще далеко до СССР в этом плане. В СССР были централизованные пункты приема стеклотары, если не изменяет память от 10 копеек за бутылку, в зависимости от ее вида. Помнится, детьми мы так на мороженное собирали =)
> в Союзе бумагу на вторсырьё не перерабатывали, а зачем — просторы
> широкие, лесов сколько хочешь, руби — не хочу)
Мда… поколение NEXT, СССР были лидером по переработке вторсырья, Европы с Америками еще только идут к тому, что было в СССР — унифицированная стеклотара — молоко, пиво, соки-воды. Сбор мукулатуры пионерами, я даже норматив еще помню — 20 кг мукулатуры — 1 новая книга. Металлолом пионеры тоннами собирали. 90% упаковки товаров было из перерабатываемых материалов.
Пивовары кстати недавно задумались над возвратом единого стандарта стеклотары.
А персловутый периметр, или машина судного дня, это система сдерживания, а не нападения. И она должна быть именно такой — исключать человеческий фактор, по другому в условиях ядерной угрозы нельзя.
Вообще-то вы несколько неточно поняли обвинение, вопрос не в распространении-нераспространении официальной информации, а в том, что закон опеределяет клевету — как распространение заведомо ложных сведений. То есть с точки зрения закона — человек знал достоверную и официальную информацию из первых рук, и был в курсе ситуации, но при этом решил «пофантазировать».
«Нельзя обычного, простого, малосведущего человека обвинить в том, что он распространил непроверенную информацию, повторил сплетню, услышанную на улице. Для обычного человека это может быть даже и простительная слабость, он не знает как работать с информацией. Может быть, он только со сплетнями всю жизнь и имел дело. И в этом смысле он просто скажет: да, я думал, что это правда, а теперь выяснилось, что это ложь. И никого нельзя судить за то, что он сегодня умнее, чем был вчера, то есть это просто ошибка.» это цитата отсюда bonipan.livejournal.com/4139.html — похожее дело о клевете.
господа, все просто — корпоративные клиенты дают 60-80% выручки провайдера. За счет их в принципе и возможны низкие тарифы для физлиц, потому как только за счет физлиц сеть будет окупаться десятилетиями, если вообще окупиться.
ЗЫ. И ненадо говорить что вас это касаться не должно, вы же (копроративные клиенты) на благотворительных началах своих услуги-товары не раздаете?
Я уже отмечал в предыдущем посте, абстракции и фреймворки это палка о двух концах, с одной стороны мы ускоряем (не упрощаем, а именно ускоряем) выход рабочего кода, но при этом ловим все баги фреймворка и «псевдогибкость» абстракций пытающихся описать неописуемое.
В моей работе время от времени возникают ситуации, когда непредвиденное поведение программы связано со сторонней библиотекой или фреймворком. Так что цена «удобства» разработки — вычитка чужого кода.
А быдлокод можно написать и с фреймворками, и с абстракциями, они эту проблему ни в коем разе не решают.
Про 1С. Пользователи то как раз и жалуются, я постоянно вижу как бухгалтерия сидит ночами и выходными, только чтобы успеть в отведенные временные рамки по закрытию отчетного периода, и немалую часть времени занимает ожидание чего же там «додумает» 1С.
Насчет Макконела — рассуждения в книге здравые, и я не собираюсь их оспаривать. Оптимизация ради оптимизации — всегда зло. Другое дело, что тот же Макконел замечает, что «написание эффективного кода — это уже признак серьезного программиста».
Но мы несколько отвлеклись, данный топик как раз показывает случай когда оптимизация нужна по условиям задачи и не решается красивой высокоуровневой абстракцией.
По поводу работы с БД кстати рекомендую Тома Кайта почитать, Oracle Experts, в русском переводе «Оракл для профессионалов». Книга конечно прежде всего про оракл, но общие вводные главы содержат много примеров как надо и как ненадо работать с БД, чтобы она не стала узким местом.
Вы клиенту текст программы даете почитать? Читаемость программы это следствие корпоративных стандартов оформления кода и профессионализма разработчика, а не использования прослоек.
Увеличение количества рисков это прямое следствие от усложнения программы, в данном случае шансов нарваться на непредвиденную ситуацию с прослойкой больше, чем с нативным функционалом БД с которой работаете. Да в принципе этот топик и показывает такую непредвиденную ситуацию.
Да и неиспользование оптимальных отработанных алгоритмов, в угоду мифической читаемости программы и красоты GUI, это движение в сторону получения на выходе кашки в красовой обертки.
ЗЫ. Мне это напоминает 1С бухгалтерию, когда 1Сники в захлеб рассказывают какая у них там большая база, целых 4Gb, и как быстро у них там проводка генерится — аж целых 5 секунд. И впадают в ступор, когда моя маленькая база в 120+Gb, выдает за теже 5 секунд аналитику по десятку миллионов строк.
5k строк за 30 секунд это совсем ненормально на современном оборудовании, даже при красивом GUI.
У меня дампы на 150-200Мб в мускул грузятся за 10-15 секунд, на стареньком P4 именно за счет bulk-insert. Тот же самый дамп, но в старой нотации — один инсерт-одна запись будет грузиться минимум пару часов.
там четырехбуквенный пароль. Посмотрите внимательнее на цифровой хеш пароля, там четные цифры постоянны для одной и тойже длины пароля, а нечетные по какому-то алгоритму мапятся из букв в цифры ;-)
похожи на сельхоз поля с радиальной системой полива… у нас тоже такие можно кое-где встретить — трубопровод на колесах крутится вокруг центра из которого осуществляется подача воды.
откатывает незавершенные транзакции на момент падения, это даже с отключенными бинарными логами.
А с бинарными логами подобное можно сделать с контрольной точки, в них лог всех действий в базе.
Поднятие из дампа только в случае физического повреждения данных, ну или с холодного бекапа, смотря что применялось. Плюс при наличии бинарных логов, можно восстановиться до последней успешной транзакции перед падением.
Механизм схож с тем, что делает Оракл в случае «неожиданной» остановки, что в общем то и не удивительно =)
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -m recent --set -j ACCEPT
пара строк в файерволе, и перебор паролей идет лесом.
PS. В кратце — коннект на 22 порт не чаще чем раз в 30 секунд, если чаще — бан с обнулением времени таймера при каждой следующей попытке.
Да и «сухой» кашей получается только гречка, просто потому что есть ее как суп не вкусно, в нее побольше масла, ну или как в детстве молока можно добавить, но это на любителя =)
С вечера можно сложные каши варить — например овсянку с тушенкой, или гречку с мясом.
> широкие, лесов сколько хочешь, руби — не хочу)
Мда… поколение NEXT, СССР были лидером по переработке вторсырья, Европы с Америками еще только идут к тому, что было в СССР — унифицированная стеклотара — молоко, пиво, соки-воды. Сбор мукулатуры пионерами, я даже норматив еще помню — 20 кг мукулатуры — 1 новая книга. Металлолом пионеры тоннами собирали. 90% упаковки товаров было из перерабатываемых материалов.
Пивовары кстати недавно задумались над возвратом единого стандарта стеклотары.
А персловутый периметр, или машина судного дня, это система сдерживания, а не нападения. И она должна быть именно такой — исключать человеческий фактор, по другому в условиях ядерной угрозы нельзя.
«Нельзя обычного, простого, малосведущего человека обвинить в том, что он распространил непроверенную информацию, повторил сплетню, услышанную на улице. Для обычного человека это может быть даже и простительная слабость, он не знает как работать с информацией. Может быть, он только со сплетнями всю жизнь и имел дело. И в этом смысле он просто скажет: да, я думал, что это правда, а теперь выяснилось, что это ложь. И никого нельзя судить за то, что он сегодня умнее, чем был вчера, то есть это просто ошибка.» это цитата отсюда bonipan.livejournal.com/4139.html — похожее дело о клевете.
ЗЫ. И ненадо говорить что вас это касаться не должно, вы же (копроративные клиенты) на благотворительных началах своих услуги-товары не раздаете?
У нас на работе был случай, когда мониторинг сбойнул и вальнул через почтовый шлюз 2000+ смсок… Дошли все, неуспевали очищать историю в телефонах.
В моей работе время от времени возникают ситуации, когда непредвиденное поведение программы связано со сторонней библиотекой или фреймворком. Так что цена «удобства» разработки — вычитка чужого кода.
А быдлокод можно написать и с фреймворками, и с абстракциями, они эту проблему ни в коем разе не решают.
Про 1С. Пользователи то как раз и жалуются, я постоянно вижу как бухгалтерия сидит ночами и выходными, только чтобы успеть в отведенные временные рамки по закрытию отчетного периода, и немалую часть времени занимает ожидание чего же там «додумает» 1С.
Насчет Макконела — рассуждения в книге здравые, и я не собираюсь их оспаривать. Оптимизация ради оптимизации — всегда зло. Другое дело, что тот же Макконел замечает, что «написание эффективного кода — это уже признак серьезного программиста».
Но мы несколько отвлеклись, данный топик как раз показывает случай когда оптимизация нужна по условиям задачи и не решается красивой высокоуровневой абстракцией.
По поводу работы с БД кстати рекомендую Тома Кайта почитать, Oracle Experts, в русском переводе «Оракл для профессионалов». Книга конечно прежде всего про оракл, но общие вводные главы содержат много примеров как надо и как ненадо работать с БД, чтобы она не стала узким местом.
Увеличение количества рисков это прямое следствие от усложнения программы, в данном случае шансов нарваться на непредвиденную ситуацию с прослойкой больше, чем с нативным функционалом БД с которой работаете. Да в принципе этот топик и показывает такую непредвиденную ситуацию.
Да и неиспользование оптимальных отработанных алгоритмов, в угоду мифической читаемости программы и красоты GUI, это движение в сторону получения на выходе кашки в красовой обертки.
ЗЫ. Мне это напоминает 1С бухгалтерию, когда 1Сники в захлеб рассказывают какая у них там большая база, целых 4Gb, и как быстро у них там проводка генерится — аж целых 5 секунд. И впадают в ступор, когда моя маленькая база в 120+Gb, выдает за теже 5 секунд аналитику по десятку миллионов строк.
У меня дампы на 150-200Мб в мускул грузятся за 10-15 секунд, на стареньком P4 именно за счет bulk-insert. Тот же самый дамп, но в старой нотации — один инсерт-одна запись будет грузиться минимум пару часов.
для импорта CSV файлов
А также на синтаксис Insert — multirow insert (bulk-insert)
dev.mysql.com/doc/refman/5.0/en/insert.html
Который гораздо быстрее одиночных инсертов.