Спасибо, что поделились примером топологии, таких примеров еще мало и всегда интересно изучать:
Я правильно понимаю, что топология похожа на ту, которая у вас сейчас в компании?
Видите ли вы проблемы с тем, что слева и справа от stream-aligned команд есть департаменты ИБ и сопровождения? не является ли это примером тех самых "высоких и толстых стен"?
Почему не используете в топологии "официальные" способы взаимодействия (collaboration, x-as-a-service, facilitating)?
Видите ли вы пересечения между задачами/активностями IT-сообществ и enabling командами?
Привет, в сентябре 2018 вышла еще одна книга про SRE — Seeking SRE, Conversations About Running Production Systems at Scale, ссылка shop.oreilly.com/product/0636920063964.do
Она содержит много примеров SRE практик в других компаниях.
Привет, да, у нас есть опыт перевода инфраструктурного кода с CentOS на Debian 6, с Debian 6 на 7 и с Ubuntu 12.04 на 14.04, да, даже переход с Chef 11 на Chef 12 приводит к проблемам. Алгоритм, в принципе, везде одинаковый: создаем образ с новой ОС, тестируем его локально с базовой ролью, находим ошибки, исправляем, потом проверяем с ролями сервисов, когда локальное тестирования проходит, переходим к обновлению окружений — preqa/qa/production. Я бы рекомендовал переустанавливать сервер с 0 для обновления ОС, когда у вас инфраструктура в виде кода, ввод нового сервера занимает очень мало времени.
Подробнее мы рассказываем в отдельном цикле статьей, скоро выйдет вторая часть. Какие именно тесты писать, зависит от вашего кода, примеры можно посмотреть в нашем кукбуке, если вы используете Chef. Если другую систему, то смотрите в репозиториях, как тестируют самые популярные community модули или роли.
Кастомную сборку лучше всего выполнять в launchpad.net или в OBS openbuildservice.org и уже через chef подключать репозиторий и выполнять package install.
innodb_flush_log_at_trx_commit — имеет три допустимых значения: 0, 1, 2. При значении равном 0, лог сбрасывается на диск один раз в секунду, вне зависимости от происходящих транзакций. При значении равном 1, лог сбрасывается на диск при каждой транзакции. При значении равном 2, лог пишется при каждой транзакции, но не сбрасывается на диск никогда, оставляя это на совести ОС. По умолчанию используется 1, что является самой надежной настройкой, но не самой быстрой. В общем случае вы можете смело использовать 2, данные могут быть утеряны лишь в случае краха ОС и лишь за несколько секунд (зависит от настроек ОС). 0 — самый быстрый режим, но данные могут быть утеряны как при крахе ОС, так и при крахе самого сервера MySQL (впрочем данные лишь за 1-2 секунды).
А вам не кажется, что самый быстрый режим это 2?
А для мониторинга работы сервера лучше использовать mytop, innotop и утилиты из maatkit.
Итого — читайте официальную документацию и блог www.mysqlperformanceblog.com/, а не переводы с «понятным» изложением.
Спасибо, что поделились примером топологии, таких примеров еще мало и всегда интересно изучать:
Я правильно понимаю, что топология похожа на ту, которая у вас сейчас в компании?
Видите ли вы проблемы с тем, что слева и справа от stream-aligned команд есть департаменты ИБ и сопровождения? не является ли это примером тех самых "высоких и толстых стен"?
Почему не используете в топологии "официальные" способы взаимодействия (collaboration, x-as-a-service, facilitating)?
Видите ли вы пересечения между задачами/активностями IT-сообществ и enabling командами?
Она содержит много примеров SRE практик в других компаниях.
Уже запустил на домашнем NAS под Ubuntu.
А вам не кажется, что самый быстрый режим это 2?
А для мониторинга работы сервера лучше использовать mytop, innotop и утилиты из maatkit.
Итого — читайте официальную документацию и блог www.mysqlperformanceblog.com/, а не переводы с «понятным» изложением.