Предлагаю Вашему вниманию статью одного моего друга и читателя этого сайта, в которой раскрывается настройка репликации MySQL серверов. Репликация служит для создания резервных копий баз данных в режиме реального времени. Ну, а для чего создаются резервные копии, думаю, рассказывать не стоит. Все возникшие вопросы направляем автору в комментарии.
Daemony
Автор:
Цели которые ставились:
Есть два сервера MySQL работающих на разных хостах соединенных между собой VPN каналом. Два сервера независимы и работают со своими базами данных. Есть задача настроить репликацию с первого на второй и со второго на первый серверы.
Далее привожу пример готового решения.
На обеих хостах версии MySQL 5.0.51. Сразу оговорюсь, “счастливым обладателям” MySQL 3.x.x версий все-таки обновиться до последних, ну или хотя бы до 4.1.
Важный момент:Сервера должны работать с одинаковыми кодировками.
Итак поехали. Для начала необходимо сделать копию директорий для нашего первого SLAVE сервера. Предварительно необходимо остановить процесс на сервере с которого мы копируем данные:
Встретился сегодня с довольно интересной особенностью веб-сервера Apache (ветка 1.3), которую раньше не встречал никогда. И пусть, возможно, она “стара как мир” хотел бы о ней рассказать. Может кому-то в будущем пригодится.
Началось с того, что я решил слегка разобрать и привести в более удобоваримый вид файл конфигурации httpd.conf на этом сервере. Ранее все виртуальные хосты были описаны непосредственно в нем, но со временем их стало многовато и перемещаться по конфигу стало не очень удобно. Я решил избавиться от этого, путем выноса конфигураций виртуалхостов в отдельные (для каждого хоста) текстовые файлы, а в httpd.conf воспользоваться директивой Include для подключения скопом всех VirtualHost. Кстати, кто еще не знает такого приема - возьмите на заметку. Очень удобно добавлять/редактировать/удалять виртуальные хосты поскольку при этом нет необходимости лазить в httpd.conf Собственно, как это выглядит на деле, покажу на примере ниже.
Файерволл ipfw во FreeBSD, как известно, можно использовать для подсчета пакетов, проходящих через правила. Выглядит это, например, так:
# ipfw show 20 21
00020 325 179449 count tcp from any 80 to any out via tun0
00021 361 57409 count tcp from any to any dst-port 80 in via tun0
Здесь во второй колонке отображается количество полученных байт, в третьей - отправленных. Для того, чтобы обнулить значение счетчика можно применить команду:
# ipfw zero 20 21
При выполнении вышеуказанной команды в логи /var/log/security и /var/log/messages выпадут уведомления:
Aug 29 00:05:03 servername kernel: ipfw: Entry 20 cleared.
Aug 29 00:05:03 servername kernel: ipfw: Entry 21 cleared.
Вопрос коллегам-знатокам: как избавиться от этих entry cleared?
От этих сообщений в логах нужно избавиться потому, что выпадает их десять строк раз в минуту - логи засираются прилично. ipfw zero используется в сборе статистики для построения графиков RRD.
Вариант с ipfw -q не помогает - сообщения все-равно вываливаются. Ковырять исходники ipfw и перекомпиливать заново - желания мало, да и неправильно это… В Сети по этому вопросу мало чего нашел. В основном народ (и в Рунете и в Буржунете) спрашивает, наталкиваясь на подобное, другие советуют подставлять -q, что тоже ни к чему не приводит.
Daemony’s Live Blog в ночь с 6-го на 7-е августа вернулся домой на родной сервер где он когда-то родился и вырос. Случилось это благодаря тому, что с 5-го августа этот самый сервер имеет безлимитное подключение к Интернет с шириной исходящего канала 1 Mbps. До этого за трафик оплата была помегабайтная, что выходило довольно накладно для бюджета. Но все течет и все меняется, безлимитки дешевеют…
Перенос не отнял много времени. Бекапы базы и файлов были перенесены на жестком диске. Когда все было готово, поменял записи в DNS. Еще какое-то время, пока не обновились кеши DNS серверов и часть трафика направлялась на прежний хост сайт по старому адресу оставался доступен. Однако роботы Google почти сразу пошли по новому адресу. Через сутки доступ к сайту по старому адресу был закрыт, хотя сам сайт удалять я не стал. Приберегу как резервную копию, если вдруг снова, не дай Бог, случится какая-то неприятность вроде этой.
Сразу после переноса сервера раскоментил в crontab’е скрипты для генерации графиков загрузки канала на основе RRD. Заодно кое-что выбросил, кое-что добавил. Вобщем привел немного в порядок. Результаты этого всего можно наблюдать на странице мониторинга. Графики на этой странице показывают статистику загрузки канала к/от сервера по отдельным протоколам (у меня это http - порты 80 и 443 - и dns), а также общую загрузку канала сумарно для шлюза в целом и отдельно для локальной сети. Статистика раз в минуту снимается со счетчиков файерволла ipfw.
Если кому-то из читателей будут интересны подробности как все сделано, позднее распишу весь процесс с примерами скриптов.
Jul 10 09:09:52 daemony savecore: reboot after panic: page fault
Jul 10 09:09:52 daemony savecore: writing core to vmcore.0
Вот такая засада… И уже третий раз за два дня.
Очень похоже на то, что на новом месте (дома) серверу сильно жарко. Его клинит. Раз уходит в ребут, раз просто зависает. Проблема не софтовая. Нужно искать способ понизить температуру… Самое главное неудобство в том, что помещение где стоит машинка абсолютно не проветривается. И нет (пока) никакой возможности организовать какой-либо вентканал.
Говорю сразу, что в PHP я не шибко силен. Так, по мелочам что-либо (для себя) могу подправить, синтаксис языка знаком. Однако, творить какие-то более или менее сложные вещи это не для меня. Потому, знающих этот язык на хорошем уровне, просьба меня не пинать, а лучше поправить или дополнить, если есть что сказать.
Так же следует отметить, что я никогда не использовал и наверное не буду использовать плагины WP для вставки кода Google Adsense в публикации. Гораздо удобнее и быстрее (как по мне) делать это руками, вставляя блоки непосредственно в шаблон темы оформления.
Значит сегодня заинтересовался блогом товарища . Просмотрел практически все публикации в нем, обнаружив интересные для меня заметки. Среди прочего встретились рекомендации, как в полосе комментариев пронумеровать список оставленных комментариев, а так же как выделить те комменты, которые оставил автор обсуждаемого материала. Это мне напомнило то, что я хотел давно сделать у себя…
Собственно, ничего сложного и нет. Использование PHP цикла дает возможность нумеровать комментарии. Условие, которое проверяет соответствие e-mail адреса комментатора адресу автора публикации, вставляет в код необходимый стиль css, если эти параметры равны.
Windows пользователи могут не читать все нижеследущее. Неинтересно будет…
Короче, жил и работал себе один хороший сервер. Видел он многое и работал уже давно. За два года своего существования перегружали его всего несколько раз и то только когда обновляли операционную систему до нового релиза FreeBSD, либо переносили на новое “железо”. А последний раз его перезагружали 90 дней 1 час и 13 минут назад. И тут… Трямц, ни с того ни с сего! Машинка перестала отвечать на все запросы (даже из локалки), и, самое обидное, перестала что-либо показывать на экране монитора. При этом, она вполне адекватно отреагировала на нажатие убийственной комбинации на клавиатуре: Ctrl-Alt-Del (reset хоть не пригодился и то слава Богу), уйдя в перезагрузку. К сожалению, что-либо еще предпринять было невозможно.
И вот сидит теперь две головы, впялившись четырьмя глазами в логи и не может вкурить, а чего же все таки произошло. Ведь буквально за несколько секунд до глюка машина не подавала каких-либо признаков беспокойства. Хотя, конечно есть некоторые предположения…
Uptime жалко. Хоть три месяца и не так много, но все же некоторые и столько не работают.
Фрагмент вчерашнего письма, которое прислал скрипт daily run output:
...
Received: (from root@localhost)
by somefinehost.net (........../Submit) id m4703lm4066686
for root; Wed, 7 May 2008 03:03:47 +0300 (EEST)
(envelope-from root)
Date: Wed, 7 May 2008 03:03:47 +0300 (EEST)
From: "root" <root@somefinehost.net>
Message-Id: <200805070003.m4703lm4066686@somefinehost.net>
To: root@somefinehost.net
Subject: somefinehost.net daily run output
...
Local system status:
3:01AM up 89 days, 12:31, 2 users, load averages: 0.73, 0.56, 0.44
...