• Пряморукий DNS: делаем правильно
    0
    С какой ошибкой ломалась?

    PS. у нас row-based replication лет 7 работает, десятки RENAME TABLE каждый день, проблемы только если в RENAME указана нереплицируемая таблица (явный запрет в replicate_*) — но это человеческий фактор
  • Ошибка в ядре Linux отправляет поврежденные TCP/IP-пакеты в контейнеры Mesos, Kubernetes и Docker
    0
    Наткнулся на баг связанный со сбоем на loopback (как предполагаю): https://bugs.openvz.org/browse/OVZ-6684
    Суть в том, что в какой-то момент перестает работать tcp на 127.0.0.1, а пинги ходят без проблем. Проявлялось на нескольких разных машинах, рестарт контейнера не помогал.
  • WSGI/Rack для PHP
    +2
    php сильно зависит от расширений и для длительного выполнения нужно аккуратно подходить к их выбору

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

    imagick, например, также сильно зависит от библиотек и недавно мы поимели неприятную проблему с апгрейдом ImageMagick из-за старой версии lcms
  • WSGI/Rack для PHP
    0
    >так ли часто случаются именно фатальные ошибки?
    все мы люди и склонны ошибаться :)

    даже если мы ошибаемся редко — это не отменяетнеприятных последствий
  • WSGI/Rack для PHP
    0
    >прекратит нормальное функционирование до тех пор, пока не будет перезапущен по какой-либо причине (например, по достижении max-requests)
    Значит ли это, что пока не наберется max-requests, вассал будет возвращать ошибку на любые запросы?
  • WSGI/Rack для PHP
    +1
    Что будет с сервером, если в скрипте обнаружится fatal error?
  • Форки движка MySQL: MariaDB, Percona. who is who?
    0
    действительно, не только PK, почему-то у меня именно PK отложились в памяти… но тем лучше, задача более широкая, чем я думал :)

    упоминание HandlerSocket вполне соотносится с темой обзора: MySQL «на стероидах». не понимаю, что Вы так взъелись на это :)
  • Форки движка MySQL: MariaDB, Percona. who is who?
    0
    спасибо, это уже интересное добавление к обзору :)

    >NoSQL — очевидно, сеонизаторский прием.
    Это вы про HandlerSocket? По-моему, довольно классная штука — очень красиво оптимизировали узкую задачу — выборку по PK.
  • Форки движка MySQL: MariaDB, Percona. who is who?
    0
    располагаете тайным знанием? так поделитесь им!
  • Форки движка MySQL: MariaDB, Percona. who is who?
    +7
    вот тут рассмотрено немного больше форков: blogerator.ru/page/mysql-na-steroidah
  • Удачная модель ветвления для Git
    0
    >Обычно людей, перешедших с SVN, в командной строке страшит относительно сложное добавление отдельных файлов и коммит части изменений. В отличии от SVN (и других централизованных систем), где это — достаточно частая операция, в git и mercurial мне это не приходилось делать вообще (в основном, благодаря легкому созданию бранчей)

    а можно мысль развить — почему их это пугает? и при чем тут бранчи?

    в git как раз специально разделили процесс коммита файлов на 2 этапа — сначала формируется список изменений для следующего коммита, а потому уже они коммитятся. ключ -a сделан лишь для тех случаев, когда все изменения идут в один коммит (удобство)

    откройте для себя git add -i — из всех изменений даже одного файла можно сформировать несколько отдельных коммитов