Comments 49
PermitRootLogin without-password
Вообще, PermitRootLogon отключен по-умолчанию из-за того, что это облегчает работу брутфорсерам — если просто так «долбить», то надо знать и логин и пароль, а так можно обойтись только паролем, поэтому вообще я бы не включал PermitRootLogon никогда, чтобы не испытывать судьбу, а использовал бы вариант с включением пользователя или группы в sudoers без пароля и соответственно логиниться под этим пользователем по ssh и использовать после этого sudo.
из man sshd_config:
PermitRootLogin
Specifies whether root can log in using ssh(1). The argument
must be ``yes'', ``without-password'', ``forced-commands-only''
or ``no''.
PermitRootLogin
Specifies whether root can log in using ssh(1). The argument
must be ``yes'', ``without-password'', ``forced-commands-only''
or ``no''.
«SELECT, RELOAD, SUPER, REPLICATION SLAVE.» для репликации? сильно…
1. В скрипте rsync нет проверки «запущен ли скрипт?». Может привести (и приведет) к нехорошей ситуации.
2. Репликация если упадет, как восстанавливать будите? Нужен скрипт проверки/восстановления репликации — сэкономит уйму времени в критический момент.
PS: автор молодец.
2. Репликация если упадет, как восстанавливать будите? Нужен скрипт проверки/восстановления репликации — сэкономит уйму времени в критический момент.
PS: автор молодец.
Спасибо =) Проверка «запущен ли скрипт?» согласен нужна, повезло что за пол года ничего страшного на серверах не произошло. В ближайшее время подправлю.
Расскажи плиз про скрипт проверки/восстановления репликации? как делаешь maatkit?
maatkit не использую, по крону каждую ночь мне приходят отчёты о состоянии серверов — в случае со вторым сервером — выход команды SHOW SLAVE STATUS\G;
восстанавливаю репликацию также вручную, т.к. за пол года репликация сломалась только один раз, по причине сильных изменений в бд.
Мне кажется, лучше этот процесс не автоматизировать, а добиться того, чтобы репликации не ломались.
восстанавливаю репликацию также вручную, т.к. за пол года репликация сломалась только один раз, по причине сильных изменений в бд.
Мне кажется, лучше этот процесс не автоматизировать, а добиться того, чтобы репликации не ломались.
У меня там довольно большой скрипт, который проверяет статус репликации и запускает все этапы восстановления по очереди.
Возможно, тут статью напишу про этот скрипт, а то вдруг кому пригодиться, а разъяснять нужно многое.
Репликация у меня падает в случае, если кто-нибудь сделает INSERT/UPDATE на слэйв. А это может произойти в случае банального захода на резервный сервер для проверки — в этом случае произойдет запись в таблицу статистики, и прощай репликация. Даже опция игнорирования дубликатов почему-то не всегда спасает (возможно, причина в другом и я что-то не понимаю).
Кстати, у меня тоже по году не падает она. Но однажды упала в самый неподходящий момент. Скрипт выручал два раза после этого.
Возможно, тут статью напишу про этот скрипт, а то вдруг кому пригодиться, а разъяснять нужно многое.
Репликация у меня падает в случае, если кто-нибудь сделает INSERT/UPDATE на слэйв. А это может произойти в случае банального захода на резервный сервер для проверки — в этом случае произойдет запись в таблицу статистики, и прощай репликация. Даже опция игнорирования дубликатов почему-то не всегда спасает (возможно, причина в другом и я что-то не понимаю).
Кстати, у меня тоже по году не падает она. Но однажды упала в самый неподходящий момент. Скрипт выручал два раза после этого.
поподробнее о первом пункте плз
Если запустятся два rsync, то они будут мешать друг-другу. ЕМНИП, будут создаваться файлы с названиями вида index.php, index.php.001, index.php.002 (примерно).
Поэтому, в скрипте нужно сделать проверку вида:
Поэтому, в скрипте нужно сделать проверку вида:
#!/bin/sh
if [ -f /home/admin/adm_scripts/rsync.lock ]
then
echo lockfile exists!
exit 1
fi
touch /home/admin/adm_scripts/rsync.lock
rsync -e ssh --progress -lzutr --compress-level=9 /home/videos/ www-data@server.ru:/home/videos
rm /home/www/adm_scripts/rsync.lock
#End
if [ -f /home/admin/adm_scripts/rsync.lock ]
then
echo lockfile exists!
exit 1
fi
touch /home/admin/adm_scripts/rsync.lock
rsync -e ssh --progress -lzutr --compress-level=9 /home/videos/ www-data@server.ru:/home/videos
rm /home/www/adm_scripts/rsync.lock
#End
У меня просто похожая проблема — запускается rsync, и через некоторое время его процессы начинают плодиться, соответственно, количество соединений к серверу растет. Непонятно из-за чего.
Попробуйте использовать семафор, который я привел выше.
Тот же самый вопрос. Как сделать репликацию самовосстанавливающейся?
Я тоже делал rsync + репликация MySQL. И я так понял, достаточно ребутнуть слейв, чтобы репликация посыпалась.
Я тоже делал rsync + репликация MySQL. И я так понял, достаточно ребутнуть слейв, чтобы репликация посыпалась.
На втором сервере в my.cnf:
max-user-connections = 50
master-host = 192.168.0.1
master-user = repluser (наш пользователь)
master-password =
server-id = 2 (должно отличатся от ID мастера!)
replicate-do-db = base (имя бд)
зачем это прописывать в конфиг? это можно задать в одну строку вместе с CHANGE MASTER. А если потребуется перекидывать мастер на другой сервак? В случае с конфигом без перезапуска не обойтись.
max-user-connections = 50
master-host = 192.168.0.1
master-user = repluser (наш пользователь)
master-password =
server-id = 2 (должно отличатся от ID мастера!)
replicate-do-db = base (имя бд)
зачем это прописывать в конфиг? это можно задать в одну строку вместе с CHANGE MASTER. А если потребуется перекидывать мастер на другой сервак? В случае с конфигом без перезапуска не обойтись.
Может я конечно не прав но!, это похоже на велосипед:
Для Apache можно сделать общие хранилище, использую drbd и ocfs2. Настраиваются ну очень просто, да и материал тут есть.
Этим мы убиваем rsync и непонятную синхронизцию через ssh с включенным root.
ну а mysql два варианта:
1) они лежат на drbd+ocfs2 и при подении одого включается другой heartbeat
2) или они нрмально работают в режиме репликации
Для Apache можно сделать общие хранилище, использую drbd и ocfs2. Настраиваются ну очень просто, да и материал тут есть.
Этим мы убиваем rsync и непонятную синхронизцию через ssh с включенным root.
ну а mysql два варианта:
1) они лежат на drbd+ocfs2 и при подении одого включается другой heartbeat
2) или они нрмально работают в режиме репликации
Предлагаю автору посмотреть в сторону DRBD, чтобы не мучаться с rsync.
p.s.: linux only
p.s.: linux only
Для FreeBSD есть HAST.
а если веб-сервер настроен nginx + apache что то нужно менять? по скрипту могу сказать что вы не сам сервис синхронизируете, а только файлы сайта, так?
При создании дампа можно указать опцию mysqldump --master-data. Тогда на слейве не нужно делать CHANGE MASTER, записывать всякие циферки… Очень упрощает жизнь.
К FreeBSD 8.1 Pawel Jakub Dawidek допилил наконец HAST — Highly Available Storage.
Пользуйтесь: wiki.freebsd.org/HAST
Пользуйтесь: wiki.freebsd.org/HAST
а как будете переключать репликацию обратно, если учесть:
1. после момента переключения еще могли произойти изменения в основной базе
2. на основном сервере (по каким-то причинам выпавшем) еще могут выполнятся задачи по крону, которые вносят изменения в БД.
там неизбежны коллизии в БД при существенной активности посетителей или крона, например.
в heartbeat нужно бы еще сделать, что он флаги расставлял на серверах, кто мастер, а кто слейв… чтобы скрипты синхронизации и прочего понимали гд они запущены…
1. после момента переключения еще могли произойти изменения в основной базе
2. на основном сервере (по каким-то причинам выпавшем) еще могут выполнятся задачи по крону, которые вносят изменения в БД.
там неизбежны коллизии в БД при существенной активности посетителей или крона, например.
в heartbeat нужно бы еще сделать, что он флаги расставлял на серверах, кто мастер, а кто слейв… чтобы скрипты синхронизации и прочего понимали гд они запущены…
Сервера аналогичны, задачи в кроне соответственно тоже. Единственное они закоментированны, сделать чтобы они начинали выполняться автоматом, пока руки не доходят. Всё что выполняется на одном сервере, должно происходить и на другом.
Задача была сделать полностью аналогичную копию основного сервера. После поломки основного — базы меняются ролями. Слейв становится мастером(вручную скриптом, время реакции не важно). Единственная проблема — на втором сервере могут отсутствовать файлы, залитые на первый, но не успетые быть перекинутые rsync-ом. Вот это уже приходится делать вручную. Кстати сессии пользователей хранятся в Memory таблице, а значит после падения первого сервера, пользователь ничего не заметит (теоретически, практически примерно двух секундная пауза)
Задача была сделать полностью аналогичную копию основного сервера. После поломки основного — базы меняются ролями. Слейв становится мастером(вручную скриптом, время реакции не важно). Единственная проблема — на втором сервере могут отсутствовать файлы, залитые на первый, но не успетые быть перекинутые rsync-ом. Вот это уже приходится делать вручную. Кстати сессии пользователей хранятся в Memory таблице, а значит после падения первого сервера, пользователь ничего не заметит (теоретически, практически примерно двух секундная пауза)
Скажите, кто знает, а HAST как будет работать, если между серверами всего 5 Мегабит канал, а объем файлов сайта примерно 120 гигабайт и их несколько сотен тысяч?
Хинт: публичный ключ быстро копируется на другой сервер при помощи ssh-copy-id либо github.com/mattwynne/ssh-forever.
UFO just landed and posted this here
Я только что попробовал ваш скрипт… имею 2 сервера. При отключений сервера №2 (резерв) и созданием на сервере №1 (основной) новых файлов то при восстановлении работы сервера №2 при синхронизаций файлы на сервере №1 удаляются. Тоже самое происходит даже если сервер №2 просто в режиме ожидания но на сервере №1 создаются новые файлы.
Вот пример отредактировано мной скрипта
Вот пример отредактировано мной скрипта
#!/bin/sh
if [ -f /root/scripts/rsync.lock ]
then
echo lockfile exists!
exit 1
fi
touch /root/scripts/rsync.lock
/usr/bin/rsync -e 'ssh -l root -i /root/.ssh/id_rsa' --progress -lzuogthvr --compress-level=9 --delete-after /var/www/wiwxp/ root@livewiw1:/var/www/wiwxp/ >> /root/logs/sync.wiwxp
rm /root/scripts/rsync.lock
#End
Забыл указать что в качестве ОС я использую Debian Lenny
rsync по сути тот же «copy», то есть первым параметром указываем откуда копируем, вторым куда. Значит, если запускаем с первого сервера:
Если на втором:
а у меня получается ошибка в тексте и только сейчас заметили, спасибо )
/usr/bin/rsync -e 'ssh -l root -i /root/.ssh/id_rsa' --progress -lzuogthvr --compress-level=9 --delete-after /var/www/wiwxp/ root@livewiw2:/var/www/wiwxp/ >> /root/logs/sync.wiwxpЕсли на втором:
/usr/bin/rsync -e 'ssh -l root -i /root/.ssh/id_rsa' --progress -lzuogthvr --compress-level=9 --delete-after root@livewiw1:/var/www/wiwxp/ /var/www/wiwxp/>> /root/logs/sync.wiwxpа у меня получается ошибка в тексте и только сейчас заметили, спасибо )
Не за что. Вы запускаете rsync с обоих серверов или только с одного? Если с обоих то как сделать чтоб они не пересекались по времени запуска?
Какой версии MySQL?
Как называется тип репликации, который вы используете?
Как чинить сломанную репликацию? (скажем, случайно запустили базу на запись и записали)
Как называется тип репликации, который вы используете?
Как чинить сломанную репликацию? (скажем, случайно запустили базу на запись и записали)
1) репликации появились с три какой-то версии mysql, в пятёрках описанное работает без проблем
2) обычная master-slave репликация
3) если таки существует возможность записи в slave бд, лучше тогда блокировать возможную запись, до смены ролей heartbeat-ом. К примеру убирая конфиг с подключением к бд на сайте, после смены ролей — конфиг возвращаем.
Кстати, описанный способ синхронизации данных, намного быстрее и легче для системы, чем способ с общим хранилищем данных, к примеру с помощью HAST. Но если данных всё же много или они часто изменяются лучше использовать «тяжёлые» способы.
2) обычная master-slave репликация
3) если таки существует возможность записи в slave бд, лучше тогда блокировать возможную запись, до смены ролей heartbeat-ом. К примеру убирая конфиг с подключением к бд на сайте, после смены ролей — конфиг возвращаем.
Кстати, описанный способ синхронизации данных, намного быстрее и легче для системы, чем способ с общим хранилищем данных, к примеру с помощью HAST. Но если данных всё же много или они часто изменяются лучше использовать «тяжёлые» способы.
Sign up to leave a comment.
Синхронизация двух серверов Apache + MySQL на FreeBSD