Усли уж берется src.rpm то все подготовительные действия в виде создания дерева rpmbuild аболютно лишние, при установке src.rpm все будет создано автоматически.
И собственно не понятно зачем вы собирали свои пакеты если все равно был взят spec от remi. Подключите Remi и не мучайтесь.
Мало ли какая у вас задача, я говорю о том что при написании статьи стоит все-таки описать решаемую задачу если вы хотите чтобы не было таких вопросов.
Кстати раз уж вы диспользуете wsgi то стоит, наверно, поднять это все не на Apache, а на том же Lighttpd или Nginx.
Видимо уже поменяли.
В кешах до сих пор находятся статьи описывающие коннективити с гуглоднс по v6.
А вот тут даже есть ссылки на FAQ, в котором раньше была процедура запроса на подключение к Google DNS по V6.
Очень интересно как автор себе представляет работу сайта по IPv6 без поддержки протокола на DNS сервере.
И откуда вообще взята информация, у того же гугла вполне себе отлично работает IPv6 DNS.
Изменения в nginx 1.3.13 19.02.2013
*) Добавление: поддержка проксирования WebSocket-соединений.
Спасибо Apcera и CloudBees за спонсирование разработки.
2. Репликация позволяет не потерять данные, а во время снятия дампа будет лок, а не останов. При снятии дампа у вас будет master status, который даст возможность долить все транзации которые были после копирования дампа.
А в вашем случае ваши 500 МБ пока перельются у вас уже может миллион транзакций произойти.
4. вы же пафосно написали "без простоя и потери данных", вот для этого самого
а то что вы написали и с простоем и с потерей данных
или Вы потерю данных БД за 5,10,15 минут и т.д. потерей не считаете?
1. Заранее (зависит от текущего TTL) делаем маленький TTL (до часа)
2. Двусторонняя репликация базы.
3. rsync либо всего сразу либо посайтово
4. настраиваем прозрачное проксирование через nginx всех запросов со старого на новый сервер
5. еще раз rsync без удаления
6. меняем DNS
Пока вы этим скриптом будете переносить даные БД, потом пока остановите старый MySQL, потом пока настроите сайты ходить на новую машину… в старую БД будут все еще писаться данные, которые Вы, да, потеряете.
И собственно не понятно зачем вы собирали свои пакеты если все равно был взят spec от remi. Подключите Remi и не мучайтесь.
Кстати раз уж вы диспользуете wsgi то стоит, наверно, поднять это все не на Apache, а на том же Lighttpd или Nginx.
В кешах до сих пор находятся статьи описывающие коннективити с гуглоднс по v6.
А вот тут даже есть ссылки на FAQ, в котором раньше была процедура запроса на подключение к Google DNS по V6.
И откуда вообще взята информация, у того же гугла вполне себе отлично работает IPv6 DNS.
Изменения в nginx 1.3.13 19.02.2013
*) Добавление: поддержка проксирования WebSocket-соединений.
Спасибо Apcera и CloudBees за спонсирование разработки.
Зачем изобретать кривой велосипед непонятно
А в вашем случае ваши 500 МБ пока перельются у вас уже может миллион транзакций произойти.
4. вы же пафосно написали "без простоя и потери данных", вот для этого самого
а то что вы написали и с простоем и с потерей данных
или Вы потерю данных БД за 5,10,15 минут и т.д. потерей не считаете?
1. Заранее (зависит от текущего TTL) делаем маленький TTL (до часа)
2. Двусторонняя репликация базы.
3. rsync либо всего сразу либо посайтово
4. настраиваем прозрачное проксирование через nginx всех запросов со старого на новый сервер
5. еще раз rsync без удаления
6. меняем DNS