Linux

В процессе длительной работы с двумя и более MySQL баз данных, между которым происходит репликация, можно столкнуться с массой мелких ошибок, вызванных, например, конфликтами первичных ключей, повреждениями журналов и т.п. Особенно, если репликация настроена, как мастер-мастер, конфликты гарантированы. Естественно, из-за мелких ошибок никто не станет полностью заново синхронизировать две базы данных, а скорее всего, пропустит ошибку через установку SQL_SLAVE_SKIP_COUNTER или slave-skip-errors. Со временем, две БД накопят некий запас неконсистентности, благодаря таким пропущенным конфликтам. Итак, что делать, если нужно восстановить полную консистентность, или в случае, когда ошибка в репликации совсем критичная и не решается вышеописанными способами? Единственный выход - полная синхронизация двух БД "с нуля" и сброс состояния репликации.

Порядок действий таков - на мастере:

На днях на одном из серверов внезапно остановилась репликация. Команда SHOW SLAVE STATUS показала ошибку: Last_Error: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave. Выглядит внушительно и слегка пугающе - все таки, не каждый день повреждаются файлы на жестком диске, к тому же файлы журнала репликации. Так или иначе, с ошибкой надо что-то делать и как всегда есть два варианта: простой, надежный, но муторный, связанный с ручной синхронизацией БД через импорт/экспорт, либо быстрый, но требующий внимания, т.к. связан со сбросом текущего положения "курсора" репликации на проблемном сервере.

Какое бы решение вы не приняли, оно поможет от любых ошибок репликации, связанных с повреждением журнала на подчиненном (слейв) сервере. Если бинарный журнал повредился на главном (мастер) сервере, статью дальше можно не читать. Итак, я пошел вторым путем, т.е. через сброс состояния репликации. Все, что нужно сделать - это выполнить несколько команд на проблемном сервере. Поехали:

Работая в системе Linux, каждый, рано или поздно, сталкивался с проблемой, когда нужно извлечь примонтированный диск/флешку/камеру, но система дает отлуп, ссылаясь на то, что устройство занято каким-то другим процессом:

Чтобы найти процессы, использующие данный ресурс и безопасно их завершить, нам поможет утилита fuser:

Первой командой мы направили процессам 1454 и 24398 сигнал SIGTERM, а затем отмонтировали наш диск. Если же umount по прежнему не дает извлечь устройство, можно, в крайнем случае, отправить сигнал SIGKILL, но это уже не будет безопасным извлечением :)

Сегодня после удаленного рестарта системы неожиданно сервер отказался подниматься... просто пал смертью храбрых. Добравшись до машины и подключив монитор, увидел в терминале следующее:

Ну что поделать, раз просят запустить fsck, так и сделал. Он нашел какие-то ошибки, спросил меня, стоит ли их исправить и велел рестартовать систему. Но увы, машина опять не поднялась и все с той же ошибкой. Проблему решил более грамотный запуск fsck:

Многие используют в MySQL функцию Master - Slave репликации для зеркалирования или бекапа данных. А что, если slave должен иметь возможность записать данные в БД, которые затем должны реплицироваться на Master? Настройка Master - Master репликации на самом деле не представляет из себя ничего сложного.

Дано:

• Хост 1 (192.168.1.1) - главный сервер
• Хост 2 (192.168.1.2) - второй сервер, зеркало первого, который должен реплицировать все с главного, а также передавать ему свои изменения

Необходимо настроить мастер-мастер репликацию между главным сервером и зеркалом. Поехали!

На главном сервере:

• В файле конфигурации MySQL (my.cnf) отключаем параметр skip-networking и прописываем в bind-address внешний IP данного сервера

Iptables - это достаточно надежный, конфигурируемый файервол для Linux-систем, поставляющийся со всеми дистрибутивами на базе ядер 2.4.х и выше. Настройка достаточно простой процесс и не займет у вас много времени.

Первое, что нужно сделать - убедиться, что в файле конфигурации /etc/sysconfig/iptables-config параметр IPTABLES_SAVE_ON_STOP="yes". Это заставит сервис iptables сохранять свою конфигурацию в файл при каждом завершении работы, чтобы не пришлось конфигурировать все повторно. Начнем с того, что создадим начальный файл конфигурации

На свежеустановленной системе файл будет иметь примерно следующее содержимое:

В последнее время на рынке появилась масса предложений по так называемым "неттопам". Ассоциативно на ум приходит Asus eee pc, но это нетбук, а неттоп - это по сути тоже самое, только без дисплея. Внешне, неттоп представляет из себя маленькую коробку размером с обычный домашний роутер, которую предполагается вешать за монитор и таким образом наслаждаться работой за моноблоком. Я решил использовать данный девайс немного по-другому...

В этой статье хотел бы немного рассказать о такой замечательной возможности SSH как Port Forwarding (или SSH Tunneling). Начну с того, что ssh - это вообще сам по себе отличный инструмент администрирования, который несомненно придет на помощь, когда нужно удаленно зайти на сервер, поуправлять различными сервисами, передать или загрузить файлы и т.д. Собственно, знают это и пользуются этим все, но немногие помнят про то, что ssh еще может "пробрасывать" порты.

Лучше всего сразу продемонстрировать все на примерах. Представим, что у вас дома работает некий сервер homeserver, находящийся в локальной сети и на нем запущен допустим VNC server на порту 5900, принимающий соединения только из этой самой локальной сети. Усложним задачу тем, что на homeserver нету SSH-сервера, но в локалке есть другая машина, принимающая внешние соединения по SSH (назовем ее homegateway).

Озаботился на днях установки почтового сервера с поддержкой протокола TLS (Transport Layer Security) и SMTP-аутентификации. Ставил на CentOS 5. Итак, начал естественно с

Теперь пойдем по шагам:

• Генерим сертификаты для TLS:
  
  mkdir /etc/postfix/ssl
  cd /etc/postfix/ssl/
  
  openssl genrsa -des3 -rand /etc/hosts -out smtpd.key 1024
  #вводим пароль для нашего файла-ключа smtpd.key
  
  chmod 600 smtpd.key
  openssl req -new -key smtpd.key -out smtpd.csr

Для того, чтобы получить доступ к удаленной машине по протоколу SSH необходимо знать, как минимум логин и пароль. Не всегда удобно вводить их каждый раз, особенно если используемых удаленных сервером слишком много. Для упрощения жизни, можно использовать доступ по общему ключу.

Процедура довольно простая.
1. На локальной машине необходимо сгенерировать публичный и приватный ключи без passphrase: