Как вы себе представляете гарантии uptime настроенного по ТЗ софта, когда у клиента есть root-доступы к серверу?
Я согласен с вами, совершенствование должно быть постоянным, это не просто этап разработки. Сегодняшние лучшие решения завтра будут примером глупых решений. Поэтому архитектура проектов в системном администрировании должна быть ориентирована на легкость поддержки. Т.е. должна быть возможность быстро внести изменения в конкретном элементе.
Постоянно изучать систему и вносить изменения может личный системный администратор. Такой человек спит и видит конкретный проект. Он стоит 60+. И не факт, что админ будет проактивным. Будут придумываться оправдания и руководитель вряд ли поймет правда это или нет.
Или можно время от времени обращаться к специалистам, которые за 1500 сделают обзор и оптимизацию. Если проект не огромный, то это очень даже выгодно.
Зарегистрировали аккаунт, подтвердили его с почты, значит вы как минимум интересуетесь нашей компанией. Рассылка начнет к вам приходить, это очевидно.
Хотите, чтобы рассылку убрали с аккаунта, надо хотя бы подтвердить, что аккаунт ваш.
1. Очень похоже на тонкий троллинг. :)
Я уже писал, что речь идет не отдельно об утилитах. Вопрос рассматривается системно. Название статьи — схемы резервного копирования, а не утилиты. ;)
Расскажите как сбросить кеши в схеме с mdadm и если это не сложнее, чем с схеме с LVM, я соглашусь с вашим первым утверждением.
2. Ключевая фраза — «если не указана прямая запись на диск».
Я писал о том, что некорректно утверждать какой из методов должен быть первый, а какой второй.
В проекте, под который написан был тот скрипт бекапа — flush на диск идет при помощи fsync().
У меня там данных на диск пишется в разы меньше чем в БД (а это типичная ситуация) и выполнять sync после блокировки и сброса кешей MySQL подобно смерти — там накопится огромная очередь запросов, и не дай бог, oom-killer.
А когда MySQL пишет не на диск, а в кеш, безусловно пользоваться надо вашим методом.
1) Согласен, только речь шла как раз о результате, т.е. о кооперации с ОС этих утилит. Сложность нормального сброса кешей с mdraid и lvm разная. mdraid/drbd тоже можно довести до ума, только надо корректно скидывать кеши.
2) Разве MySQL всегда пишет данные в буффер ОС? И там и там вызывается fsync(), т.е. подтверждение записи ожидается от дисковой подсистемы.
Выше есть предупреждение о холиварах php-fpm/Apache.
Это как-то противоречит моим словам?)
Обычно, дешевое администрирование — это учеба за счет клиента.
Как вы себе представляете гарантии uptime настроенного по ТЗ софта, когда у клиента есть root-доступы к серверу?
Я согласен с вами, совершенствование должно быть постоянным, это не просто этап разработки. Сегодняшние лучшие решения завтра будут примером глупых решений. Поэтому архитектура проектов в системном администрировании должна быть ориентирована на легкость поддержки. Т.е. должна быть возможность быстро внести изменения в конкретном элементе.
Постоянно изучать систему и вносить изменения может личный системный администратор. Такой человек спит и видит конкретный проект. Он стоит 60+. И не факт, что админ будет проактивным. Будут придумываться оправдания и руководитель вряд ли поймет правда это или нет.
Или можно время от времени обращаться к специалистам, которые за 1500 сделают обзор и оптимизацию. Если проект не огромный, то это очень даже выгодно.
Зарегистрировали аккаунт, подтвердили его с почты, значит вы как минимум интересуетесь нашей компанией. Рассылка начнет к вам приходить, это очевидно.
Хотите, чтобы рассылку убрали с аккаунта, надо хотя бы подтвердить, что аккаунт ваш.
Я уже писал, что речь идет не отдельно об утилитах. Вопрос рассматривается системно. Название статьи — схемы резервного копирования, а не утилиты. ;)
Расскажите как сбросить кеши в схеме с mdadm и если это не сложнее, чем с схеме с LVM, я соглашусь с вашим первым утверждением.
2. Ключевая фраза — «если не указана прямая запись на диск».
Я писал о том, что некорректно утверждать какой из методов должен быть первый, а какой второй.
В проекте, под который написан был тот скрипт бекапа — flush на диск идет при помощи fsync().
У меня там данных на диск пишется в разы меньше чем в БД (а это типичная ситуация) и выполнять sync после блокировки и сброса кешей MySQL подобно смерти — там накопится огромная очередь запросов, и не дай бог, oom-killer.
А когда MySQL пишет не на диск, а в кеш, безусловно пользоваться надо вашим методом.
2) Разве MySQL всегда пишет данные в буффер ОС? И там и там вызывается fsync(), т.е. подтверждение записи ожидается от дисковой подсистемы.