Стратегия обновления ПО на серверах

Работает - не трогай.

А

хочется новых фичей

в сочетании с шаловливыми ручками обычно приводит к печальным последствиям.

Это касательно новых версий. А с обновлениями из штатных репозиториев обычно проблем нет, как раз там баги и фиксятся.

Троллим? :)
Есть вещи, для которых истинно «работает-не трогай» (см.пункт 1), а есть вещи для которых это совсем не так.

Вообразим такой пример, реально его не было, но сценарий не то что вероятный, жизненный сценарий. Возьмём к примеру mysql, допустим, во время старта проекта использовалась версия 5.1. Потом проект вышел на продакшн. Появились новые требования к проекту, увеличился размер базы

I. Оказалось что существующая схема бэкапа через mysqldump не гарантирует требуемой ссылочной целостности без блокировки БД. А ссылочная целостность необходима, и блокировка БД на пол-часа недопустима, а денег на сервак для репликации не дают, а без бэкапа нельзя. Можно сделать горячий бэкап без блокировок, но это возможно лишь для версий > 5,5.

II. Новый программист предложил кардинальное усовершенствание системы, но для этого нужны триггеры и хранимые процедуры из версии 5,5.

Какой реальный выход можно предложить из этой ситуации, кроме обновления версии mysql?

Мы в таком случае разворачиваем копию боевого сервака и ставим нужное либо с бэкпортов, либо собираем руками и тестим сначала на нем. В случае, если косяков не выявлено - ставим в работу. Но это усложнение поддержки и часто куча геморроя. Репозитории тестинга вроде нигде не подключены.

1. Объяснить начальнику его словами, что нужен еще один сервер
2. Сам собираешь новый пакет и следишь за ним

Дружище, то что я написал про сервер, это был лишь пример ситуации, призванный показать что в нашей практике часто возникает объективная необходимость обновления ПО. Ты отличай маленько общую проблему от примера.
Если ты хочешь сказать , что недопустимо решать подобные вопросы путём обновления ПО на новую версию, отстутсвующую в текущем наборе пакетов, так и пиши.

Сам собираешь пакет следишь за ним

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

тут выбираешь... «шашечки или ехать»

Увы, они правы. Версии пакетов замораживаются не только для того, чтобы тебе насолить. Т.ч. правильные способы:

• или выбросить из требований стабильность и использовать bleeding-edge дистрибутивы
• или добавить в требования к ПО версию твоего дистрибутива
• или покупать поддержку свежих пакетов у более шустрых поставщиков

Другие варианты гарантируют тебе лишнюю и малоинтересную работу.

Я выбираю гибридный путь. Где-то ppa от разрабов, где-то sudo checkinstall. Сторонние репы редко использую - ссыкотно.

ручная сборка намного сложнее и рискованей.

хз, хз, у меня не было проблем. На крайняк можно посмотреть как собирается в дистре apt-get source в помощь.

Оказалось что существующая схема бэкапа через mysqldump не гарантирует требуемой ссылочной целостности без блокировки БД.

Ключевое слово здесь - «ОКАЗАЛОСЬ». Гениально повели себя первоначальные разработчики и админы, сделав то, что оказалось неюзабельным. Реально, смешно.

По факту. Как сделать бэкап. Объясняю. При установке Slackware (Debian идет лесом прямо с места и навсегда), вы разбиваете диск (неважно куда вы там это всё ставите - на USB или хороший аппаратный рейд-контроллер) на 2 раздела. 1-й раздел с / для всего (пусть будет sda1). 2-й раздел в конце диска для свопа. обоим дискам вы присваиваете тип «fd» (Linux raid autodetect).

Далее, выполняете такие сильные колдунства, как: mdadm /dev/md0 --create --force --level=mirror --raid-devices=1 --metadata=0.90 /dev/sda1 mdadm /dev/md1 --create --force --level=mirror --raid-devices=1 --metadata=0.90 /dev/sda2 в связи с чем получаете 2 софтверных зеркальных рейда, каждый из которых будет состоять из одного раздела.

Ставите Slackware на /dev/md0, /dev/md1 разметите как своп после установки. Как ставить лило на софтверный рейд поинтересуйтесь у Гугла, он всеведущ. Получаете в итоге отлично работающую систему!

А бэкап... да что там бэкапить-то? Воткнул USB-винт и сказал синхронизировать рейды. После синхронизации отключил. И всё. Можно даже скрипты написать, чтобы не заморачиваться ручками.

обновлениями из штатных репозиториев обычно проблем нет

Да-да. Но вот когда проблемы таки ЕСТЬ, внезапно ложится пол-Инета. Вспомнить хотя бы апдейт CeontOSа, который дефолтом делал сборку ядра с PAT. Всё, что PAT не поддерживало, вдруг перестало работать....

Не гарантирована констистентность данных.

репликация БД

кроме обновления версии mysql?

а почему бы не обновиться? :)

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

и засоряет систему

2. Использовать сторонние ppa-репозитории. Недостатки: зависимость от каких-то неведомых самостийных майтэйнеров, высок риск что через год-два от этих ppa и следа не останется

если параноик - можно брать только спеки

1. Использовать репозитории testing

нет, но опять же, из спеков можно пересобрать бэкпорт

backports

я за этот (и предыдущий) вариант

на «боевых» серверах
хочется новых фичей.

да ну?

Какой реальный выход можно предложить из этой ситуации, кроме обновления версии mysql?

собрать самим пакет с mysql и обновлять его в случае необходимости

Это почему, простите? Она не более «не гарантирована», чем при использовании репликации, на который у ТСа к тому же и денег нету. :)

А уж использование mysqldump'а еще более не гарантирует «констистентность» и вот почему:

mysqldump бэкапит БД по-таблично. Соответственно, пока одна табличка дампится, в остальные данные пишутся. Что в итоге дает волшебный «косой» срез БД по времени. О какой же «констистентности» вообще можно речь вести?

В этом отношении репликация более правильна. Для бэкапа останавливаем репликацию, дампим, получая «горизонтальный» срез по времени. Примерно то же самое получается с бэкапом через синхронизацию рейда. Единственный минус - это то, что во время остановки рейда, несколько транзакций могут быть незавершенными (в общем-то, аварийная остановка мускля) и после восстановления из бэкапа придется БД почекать. Впрочем, innodb такую ситуацию умеет разруливать и ничего страшного не случится.

Тем не менее, если уж так важна именно корректность сохраненных на бэкапе данных, можно перед остановкой рейда убить мускль, и после остановки рейда поднять снова. Конечно, если остановка сервиса на 1-2 минуты глубочайшей ночью позволительна.

wheel

и засоряет систему

О! Это что-то новенькое!!!!

configure --prefix=/usr/local/mysql-4.1.22

...

ln -s /usr/local/mysql-4.1.22 /usr/local/mysql

echo «/usr/local/mysql/lib» >> /etc/ld.so.conf

echo «/usr/local/mysql/lib/mysql» >> /etc/ld.so.conf ldconfig

запускать mysql всегда типа /usr/local/mysql/bin/mysqld_safe (ну или путь прописать этот в init'е).

Сильно системку засорило??? :) А вот апдейт мускля еще удобнее: сделать префикс какой-нибудь /usr/local/mysql-4.1.23 , откомпилировать, установить, _ПРОВЕРИТЬ_. Потом остановить боевой мускль, сменить цель у симлинка и запустить мускль. Если всё делать быстро или скриптом, простой сервера - единицы секунд и уж тем более никаких перезагрузок. Ктому же, если «что-то пойдет никак», вернуть систему к состоянию «до апдейта» легче легкого - просто изменить цель симлинка.

configure --prefix=/usr/local/mysql-4.1.22

имхо всё что не попадает под действие пакетного менеджера должно быть либо конфигом, либо в хомяке. Иначе - идите в слаку

и засоряет систему

Что имеется ввиду? Инсталляция *-dev пакетов для сборки?

а не в /opt ?

Инсталляция *-dev пакетов для сборки?

это можно маркировать в aptitude и потом снести

http://www.archserver.org/

Подключить их core - там система инициализации, пакетный менеджер, ssh, ядро, bash и всё остальное без чего система не запустится.

А extra и community взять от обычного арча. Там как раз всякие апачи с mysql'ями самых свижх стабильных версий.

ну или в /opt. Я всё-таки крупный софт предпочитаю ставить пакетами, а рукокомпиленные мелочи лежат в хомяке.

Красношапочники такие красношапочники! :) Гыыы.

В общем-то, действительно, зачем вам мозг, если есть пакетный менеджер! :)

Красношапочники

4.2

зачем вам мозг, если есть пакетный менеджер!

предпочитаю занимать мозг более подходящими вещами. Вот нафига мне помнить, что и куда поставлено?

А просто залочить и сдернуть снапшот/дамп не судьба? Ну и еще одно ограничение: этот подход неприменим для ovz/lxc контейнеров.

зачем вам мозг, если есть пакетный менеджер!

А если 10 однотипных серверов, и нужно еще 10 в другом ДЦ что будешь делать?

Какой путь вы, господа, считаете наиболее правильным?

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

Второй пункт не стоит рассматривать в принципе.

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

Совсем вакуумную ситуацию, думаю, рассматривать нет смысла.

А если 10 однотипных серверов, и нужно еще 10 в другом ДЦ что будешь делать?

подниму свой репозиторий с бэкпортированными пакетами.

Или это не мне вопрос?