Это можно сделать развве что незадолго до переезда, так как:
1) нагрузка на DNS будет повышенная; 2) весь сёрфинг будет состоять для клиента из постоянного опроса DNS; 3) всё равно кэширующие DNS на эти параметры могут не обратить должного внимания.
Если есть nginx:
Надо в правила nginx старого сервера вставить переброс запросов на новый сервер. Получится петля, но реально не так уж много клиентов не заметят смену DNS; зато никто не потеряется и не надо будет делать никаких синхронизаций базы и сайта, так как реально будет работать только новый сайт. Всего-то надо 1) остановить nginx, 2) синхронизировать серверы, 3) запустить nginx с новым конфигом . Весь переезд можно уложить в минуты или секунды. Как только на старый nginx перестанут приходить запросы - его можно гасить.
Наоборот, хорошо что есть такие предложения - пользователь имеет возможность за пару долларов получить опыт и вникнуть в особенности организации хостинга, а грамотный пользователь это как раз то что нужно. То, что убеждать приходится это нормально, - мы же, покупая джинсы, смотрим на кучу параметров.
А от этой ispCP есть положительные впечатления? Она первым пунктом инструкции на Debian ориентирована, мне это очень интересно.
Тем более что APC обещали включить в состав PHP.
Уже забыл, что-то для php.
Но что это за панель управления, для запуска которой надо 10 доступов по руту? Получается, что она и слететь может в любой момент, и установка её на сервер при переустановке сервера опять потребует ручной работы, и процесс установки невоспроизводим... Одно хорошо - действительно, разработчики доступны.
Я как раз в этом вижу плюс - у них есть автоматическая инсталляция системы, и, судя по всему, второй винт они просто не включили в процедуру инсталляции. И слава богу - используя его как диск для backup , можно надеяться на неисчезновение данных при крахе и переинсталляции сервера.
Камень в сторону ISPmanager - плохо работает в Debian. Не соблюдает политики, глюки с установкой модулей. Правда, ставил я его на рабочую систему - но глядя на его конфиги, которые он генерит - доверия к нему мало. Есть версия, что на FreeBSD он работает лучше.
Странно что /tmp - вроде сессии лежат в /var где-то по умолчанию в debian.
Но что раздуваются - почему бы и нет, всё зависит от количества сессий и правил хранения сессии. В моём проекте такие настройки:
ini_set('session.use_cookies', 1);
ini_set('session.cache_expire', 60*60*24*31);
ini_set('session.cache_limiter', 'none');
ini_set('session.cookie_lifetime', 60*60*24*31);
ini_set('session.gc_maxlifetime', 60*60*24*31);
ini_set('session.use_only_cookies', 1);
ini_set('session.use_trans_sid', 0);
define('SESSION_SAVE_PATH', DOCUMENT_ROOT.'/../session');
ini_set('session.save_handler', 'sqlite');
ini_set('session.save_path', SESSION_SAVE_PATH . '/phpsess.db');
Последние три - хранить сессии не в файлах, а в sqlite базе, мне это кажется оправданным.
😮 Так их! И можно заодно принимать заказы на выравнивание трафика :)
Нормальная вроде статистика.
Из Германии:
Из Москвы:
