Pull to refresh

Comments 49

Вообще, PermitRootLogon отключен по-умолчанию из-за того, что это облегчает работу брутфорсерам — если просто так «долбить», то надо знать и логин и пароль, а так можно обойтись только паролем, поэтому вообще я бы не включал PermitRootLogon никогда, чтобы не испытывать судьбу, а использовал бы вариант с включением пользователя или группы в sudoers без пароля и соответственно логиниться под этим пользователем по ssh и использовать после этого sudo.
AllowUsers root@192.168.0.2
PermitRootLogin yes

root доступен только одному адресу, да и ssh в ipfw открыт на серверах только для внутренней подстети, а значит во внешке его не видно
Я же говорю — чтобы не искушать судьбу :). Против вашего способа я ничего не имею, мне показалось уместным написать, что в большинстве случаев PermitRootLogon — это плохая идея
из 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''.
«SELECT, RELOAD, SUPER, REPLICATION SLAVE.» для репликации? сильно…
Не совсем понял, какая привилегия лишняя:
— для команды FLUSH TABLES WITH READ LOCK нужна RELOAD
— для LOAD DATA FROM MASTER нужен SUPER. Нужно здесь или нет — спорно.
Пользователю repluser мы указали использовать только IP 192.168.0.2

Те же привилегии советуют использовать и в других мануалах.
LOAD DATA FROM MASTER — деприкейтед. не нужно ее использовать.
1. В скрипте rsync нет проверки «запущен ли скрипт?». Может привести (и приведет) к нехорошей ситуации.
2. Репликация если упадет, как восстанавливать будите? Нужен скрипт проверки/восстановления репликации — сэкономит уйму времени в критический момент.

PS: автор молодец.
Спасибо =) Проверка «запущен ли скрипт?» согласен нужна, повезло что за пол года ничего страшного на серверах не произошло. В ближайшее время подправлю.
Расскажи плиз про скрипт проверки/восстановления репликации? как делаешь maatkit?
maatkit не использую, по крону каждую ночь мне приходят отчёты о состоянии серверов — в случае со вторым сервером — выход команды SHOW SLAVE STATUS\G;
восстанавливаю репликацию также вручную, т.к. за пол года репликация сломалась только один раз, по причине сильных изменений в бд.
Мне кажется, лучше этот процесс не автоматизировать, а добиться того, чтобы репликации не ломались.
я вот так же считаю, поэтому и задал вопрос Nastradamus
У меня там довольно большой скрипт, который проверяет статус репликации и запускает все этапы восстановления по очереди.
Возможно, тут статью напишу про этот скрипт, а то вдруг кому пригодиться, а разъяснять нужно многое.

Репликация у меня падает в случае, если кто-нибудь сделает 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

У меня просто похожая проблема — запускается rsync, и через некоторое время его процессы начинают плодиться, соответственно, количество соединений к серверу растет. Непонятно из-за чего.
Попробуйте использовать семафор, который я привел выше.
вот прям сейчас посмотрел у себя на freebsd — точно такой же скрипт работает нормально.

Можно еще заменить на такую конструкцию (работает точно в bash)

if [! -e filename ];
then
echo File not found
else
echo File found!
fi
спасибо, я просто не знал, что если в первой строке скрипта написать
#!/bin/sh
то скрипт будет обработан башем
у меня все выполнялось через /bin/csh
еще раз спасибо за быстрый ответ!
Не-не.
#!/bin/sh — это стандартный шелл
а
#!/bin/bash — баш :)

Тот же самый вопрос. Как сделать репликацию самовосстанавливающейся?
Я тоже делал rsync + репликация MySQL. И я так понял, достаточно ребутнуть слейв, чтобы репликация посыпалась.
Не сыпется репликация, ни при ребуте первого, ни второго серверов. После update-ов сервера перезагружаются (естественно по очереди), heartbeat моментально срабатывает, после перезагрузки обоих серверов, на первом выполняю /usr/local/lib/heartbeat/hb_takeover. Всё. Репликация не рушится.
На втором сервере в 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. А если потребуется перекидывать мастер на другой сервак? В случае с конфигом без перезапуска не обойтись.
Может я конечно не прав но!, это похоже на велосипед:

Для Apache можно сделать общие хранилище, использую drbd и ocfs2. Настраиваются ну очень просто, да и материал тут есть.
Этим мы убиваем rsync и непонятную синхронизцию через ssh с включенным root.

ну а mysql два варианта:
1) они лежат на drbd+ocfs2 и при подении одого включается другой heartbeat
2) или они нрмально работают в режиме репликации
+1 за ocfs2
еще как вариант glusterfs

при большом кол-ве файлов rsync будет убивать диск достаточно продолжительное время.

Предлагаю автору посмотреть в сторону DRBD, чтобы не мучаться с rsync.
p.s.: linux only
а если веб-сервер настроен nginx + apache что то нужно менять? по скрипту могу сказать что вы не сам сервис синхронизируете, а только файлы сайта, так?
только файлы сайта, верно. nginx + apache и использую если быть точнее, ничего менять не надо
При создании дампа можно указать опцию mysqldump --master-data. Тогда на слейве не нужно делать CHANGE MASTER, записывать всякие циферки… Очень упрощает жизнь.
а как будете переключать репликацию обратно, если учесть:
1. после момента переключения еще могли произойти изменения в основной базе
2. на основном сервере (по каким-то причинам выпавшем) еще могут выполнятся задачи по крону, которые вносят изменения в БД.

там неизбежны коллизии в БД при существенной активности посетителей или крона, например.

в heartbeat нужно бы еще сделать, что он флаги расставлял на серверах, кто мастер, а кто слейв… чтобы скрипты синхронизации и прочего понимали гд они запущены…
Сервера аналогичны, задачи в кроне соответственно тоже. Единственное они закоментированны, сделать чтобы они начинали выполняться автоматом, пока руки не доходят. Всё что выполняется на одном сервере, должно происходить и на другом.
Задача была сделать полностью аналогичную копию основного сервера. После поломки основного — базы меняются ролями. Слейв становится мастером(вручную скриптом, время реакции не важно). Единственная проблема — на втором сервере могут отсутствовать файлы, залитые на первый, но не успетые быть перекинутые rsync-ом. Вот это уже приходится делать вручную. Кстати сессии пользователей хранятся в Memory таблице, а значит после падения первого сервера, пользователь ничего не заметит (теоретически, практически примерно двух секундная пауза)
Скажите, кто знает, а HAST как будет работать, если между серверами всего 5 Мегабит канал, а объем файлов сайта примерно 120 гигабайт и их несколько сотен тысяч?
UFO landed and left these words here
Пока rsync справляется на отлично, и так как сервер занят всего лишь одним сайтом и все ресурсы идут на него, я думаю он будет справляться ещё довольно долго.
Но вообще я полностью согласен с вами, и в ближайшее время попробую реализовать общее хранилище для файлов по другому.
Я только что попробовал ваш скрипт… имею 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. Но если данных всё же много или они часто изменяются лучше использовать «тяжёлые» способы.
Only those users with full accounts are able to leave comments. Log in, please.