- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
В общем, взял еще сервер, отдельно под mySQL.
На основном серваке все стандартное и CPanel. На втором все то же, но CPanel не ставил. Надо ли?
Прошу поделиться опытом, как быстрей и проще скопировать mysql базы с одного сервера на другой в такой конфигурации. Доступ по SSH.
Судя по вопросу обычный mysqldump вызывает высокую нагрузку, а значит нужно смотреть в сторону
ionice/nice, либо можно использовать перловый скрипт mysqlhotcopy.
Если критично время синхронизации, то лучше использовать полноценную кластерную репликацию (с mcluster-ом у меня строго негативные ассоциации и посему его не рекомендую разворачивать)
Ну если надо именно быстрее и проще, я бы сами файлы данных скопировал. Перед копированием желательно базу остановить.
поддерживаю Поручик
имхо если копировать, то остановить обязательно!... и быстрее и проще....
Надо сделать бэкап базы с помощью mysqldump.
Максимально его сжать (например gzip'ом) (необязательно) и передать на удаленный сервер с помощью sftp.
На удаленном сервере распаковать архив (при необходимости) и залить бэкап - все.
1. У нас админ просто копированием это дело делает. Остановить серв базы, конечно надо не забыть. Вообще надо остановить серв в любом случае ибо наверняка критично чтобы данные совпадали. Пущай часок повисит, ничего страшного. Просто делать лучше на выходных либо ночью. И желательно подгадать так, чтобы в это время была бы мала вероятность посещения робота яшки.
2. Подумать заранее, как быстро потом перенастроить все скрипты обращающиеся к базе на новый хост.
ЗЫ. Конечно лучше сначала сделать это в тестовом режиме, например, перенести только пару баз, убедиться, что все работает и повторить операцию переноса уже для ВСЕХ баз данных на 100%.
Лучше всего действительно переносить копированием файлов данных. Только сервер останавливать не надо - просто сделать flush tables и залочить на запись.
Лучше всего действительно переносить копированием файлов данных. Только сервер останавливать не надо - просто сделать flush tables и залочить на запись.
а что про это подумают пехапескрипты? imho надо погасить вебсервер и кронтаб, а потом уже, убедившись что туда никто не пишет, сделать mysqldump... если там myisam то проще файлы скопировать.
а что про это подумают пехапескрипты?
А они там есть? :)
Строго говоря, при бешеной посещаемости, конечно лучше переходить в maintenance mode. Но, на практике, несколько секунд, требуемых для копирования, занимают меньше времени, чем процесс остановки и запуска серверов. А Innodb, конечно, лучше дампить.
CPanel ставить на втором - не надо.
В связи с тем, что по SSH порой не пролезают файлы более 4 гиг, рекомендую дамп писать сразу на второй сервер:
mysqldump -u root -p -h****** > db.sql, где ****** - ip адрес вашего первого сервера
предварительно остановив апач:
service httpd stop
на первом сервере
mysqldump -u root -p -h****** > db.sql, где ****** - ip адрес вашего первого сервера
Это если юзеру разрешено ходить не с локалхоста и mysql слушает хоть что-то вместо сокета, что встречается довольно редко.