Если у вас есть сервер, на котором настроена MySQL репликация, то рано или поздно вы столкнетесь с разного рода ошибками этой самой репликации. Ошибки могут быть вызваны как некорректной настройкой mysql-сервера, так и неправильной структурой самой БД.
В моей практике, наиболее распространенной ошибкой была 1062 Duplicate entry '...' for key 1, которая возникает в случае нарушения уникальности какого-либо unique-поля таблицы. Если вы не можете изменить структуру таблиц так, чтобы избежать подобной ситуации, но, при этом, репликацию надо как-то запускать, есть простой выход - в настройки MySQL (my.cnf) добавить строку slave-skip-errors = 1062. С этого момента, сервер просто будет игнорировать именно эту ошибку и репликация останавливаться не будет. Но надо понимать, что при таком подходе вы будете терять часть данных, которые не попадут в реплицируемые таблицы из-за описанного выше конфликта.
Сегодня после удаленного рестарта системы неожиданно сервер отказался подниматься... просто пал смертью храбрых. Добравшись до машины и подключив монитор, увидел в терминале следующее:
Ну что поделать, раз просят запустить fsck, так и сделал. Он нашел какие-то ошибки, спросил меня, стоит ли их исправить и велел рестартовать систему. Но увы, машина опять не поднялась и все с той же ошибкой. Проблему решил более грамотный запуск fsck:
Многие используют в MySQL функцию Master - Slave репликации для зеркалирования или бекапа данных. А что, если slave должен иметь возможность записать данные в БД, которые затем должны реплицироваться на Master? Настройка Master - Master репликации на самом деле не представляет из себя ничего сложного.
Дано:
Необходимо настроить мастер-мастер репликацию между главным сервером и зеркалом. Поехали!
На главном сервере:
Iptables - это достаточно надежный, конфигурируемый файервол для Linux-систем, поставляющийся со всеми дистрибутивами на базе ядер 2.4.х и выше. Настройка достаточно простой процесс и не займет у вас много времени.
Первое, что нужно сделать - убедиться, что в файле конфигурации /etc/sysconfig/iptables-config параметр IPTABLES_SAVE_ON_STOP="yes". Это заставит сервис iptables сохранять свою конфигурацию в файл при каждом завершении работы, чтобы не пришлось конфигурировать все повторно. Начнем с того, что создадим начальный файл конфигурации
На свежеустановленной системе файл будет иметь примерно следующее содержимое:
Не так давно обратил внимание, на странные записи в лог файле Mac OS X (var/log/system). В них сервис crond ругался то на segmentation fault, то еще на что-то:
Товарищи на форумах в один голос советовали переходить с cron на встроенный в макинтош механизм launchd. Приведу простой пример, как это можно быстро сделать. Допустим у вас в cron есть запись:
В последнее время на рынке появилась масса предложений по так называемым "неттопам". Ассоциативно на ум приходит Asus eee pc, но это нетбук, а неттоп - это по сути тоже самое, только без дисплея. Внешне, неттоп представляет из себя маленькую коробку размером с обычный домашний роутер, которую предполагается вешать за монитор и таким образом наслаждаться работой за моноблоком. Я решил использовать данный девайс немного по-другому...
Быстрая заметка, для тех, кто столкнулся с проблемой, когда Cacti вдруг перестает рисовать новые значения графиков, а в логах появляется строка
Случилось это после рестарта системы, т.е. вручную, конечно же, никто не запускал poller.php. Лечится это установкой $force = TRUE; в poller.php. После очередного, на сей раз успешного срабатывания, меняем значение обратно на FALSE.
Если же этот фокус не помог, а в логах теперь ругательства rrdtool
В этой статье хотел бы немного рассказать о такой замечательной возможности SSH как Port Forwarding (или SSH Tunneling). Начну с того, что ssh - это вообще сам по себе отличный инструмент администрирования, который несомненно придет на помощь, когда нужно удаленно зайти на сервер, поуправлять различными сервисами, передать или загрузить файлы и т.д. Собственно, знают это и пользуются этим все, но немногие помнят про то, что ssh еще может "пробрасывать" порты.
Лучше всего сразу продемонстрировать все на примерах. Представим, что у вас дома работает некий сервер homeserver, находящийся в локальной сети и на нем запущен допустим VNC server на порту 5900, принимающий соединения только из этой самой локальной сети. Усложним задачу тем, что на homeserver нету SSH-сервера, но в локалке есть другая машина, принимающая внешние соединения по SSH (назовем ее homegateway).
Озаботился на днях установки почтового сервера с поддержкой протокола TLS (Transport Layer Security) и SMTP-аутентификации. Ставил на CentOS 5. Итак, начал естественно с
Теперь пойдем по шагам:
Для того, чтобы получить доступ к удаленной машине по протоколу SSH необходимо знать, как минимум логин и пароль. Не всегда удобно вводить их каждый раз, особенно если используемых удаленных сервером слишком много. Для упрощения жизни, можно использовать доступ по общему ключу.
Процедура довольно простая.
1. На локальной машине необходимо сгенерировать публичный и приватный ключи без passphrase:
Обратите внимание, блог переехал на новый адрес: initialize.ru
Последние комментарии
5 дней 6 часов назад
6 дней 1 час назад
6 дней 10 часов назад
1 неделя 3 часа назад
1 неделя 3 часа назад
1 неделя 3 часа назад
1 неделя 3 часа назад
1 неделя 3 часа назад
1 неделя 3 часа назад
2 недели 1 день назад