|
|
|
|
|
|
Запланированный downtime ~ 1 час
В ночь с 27-го на 28-го октября предстоит плановый апгрейд программного обеспечения на этом сервере. В связи с чем, приблизительно один час сайт может быть недоступен. Апгрейду подлежат как сам скрипт блога, так и софт, поддерживающий хостинг: apache, php, mysql…
Даунтайм настанет примерно в 01.00 по киевскому времени 28.10.2008.
UPD 2008-10-28 07:38
Обновления успешно завершены. Простоя практически не было.
Настройка репликации MySQLПредлагаю Вашему вниманию статью одного моего друга и читателя этого сайта, в которой раскрывается настройка репликации 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 Собственно, как это выглядит на деле, покажу на примере ниже.
Изначально httpd.conf выглядел традиционно вот так:
########## Виртуальные хосты ############ NameVirtualHost *:80 <VirtualHost> ServerName localhost AddType application/x-httpd-php .php .php3 .php4 .phtml AddType application/x-httpd-php-source .phps </VirtualHost> <VirtualHost> ServerName server.com ServerAdmin bla_-_bla_-_bla@server.com DocumentRoot /path/to/htdocs ... CustomLog /path/to/custom/log.log combined ErrorLog /path/to/error/log.log ServerName site1.server.com ...
И так далее перечисляются все остальные виртуальные хосты. Уходя от такого метода, поступаем так:
Возвращение блудного сына
Daemony’s Live Blog в ночь с 6-го на 7-е августа вернулся домой на родной сервер где он когда-то родился и вырос. Случилось это благодаря тому, что с 5-го августа этот самый сервер имеет безлимитное подключение к Интернет с шириной исходящего канала 1 Mbps. До этого за трафик оплата была помегабайтная, что выходило довольно накладно для бюджета. Но все течет и все меняется, безлимитки дешевеют…
Перенос не отнял много времени. Бекапы базы и файлов были перенесены на жестком диске. Когда все было готово, поменял записи в DNS. Еще какое-то время, пока не обновились кеши DNS серверов и часть трафика направлялась на прежний хост сайт по старому адресу оставался доступен. Однако роботы Google почти сразу пошли по новому адресу. Через сутки доступ к сайту по старому адресу был закрыт, хотя сам сайт удалять я не стал. Приберегу как резервную копию, если вдруг снова, не дай Бог, случится какая-то неприятность вроде этой.
Сразу после переноса сервера раскоментил в crontab’е скрипты для генерации графиков загрузки канала на основе RRD. Заодно кое-что выбросил, кое-что добавил. Вобщем привел немного в порядок. Результаты этого всего можно наблюдать на странице мониторинга. Графики на этой странице показывают статистику загрузки канала к/от сервера по отдельным протоколам (у меня это http - порты 80 и 443 - и dns), а также общую загрузку канала сумарно для шлюза в целом и отдельно для локальной сети. Статистика раз в минуту снимается со счетчиков файерволла ipfw.
Если кому-то из читателей будут интересны подробности как все сделано, позднее распишу весь процесс с примерами скриптов.
savecore: reboot after panic: page fault
Jul 10 09:09:52 daemony savecore: reboot after panic: page fault Jul 10 09:09:52 daemony savecore: writing core to vmcore.0
Вот такая засада…
И уже третий раз за два дня.
Очень похоже на то, что на новом месте (дома) серверу сильно жарко. Его клинит. Раз уходит в ребут, раз просто зависает. Проблема не софтовая. Нужно искать способ понизить температуру… Самое главное неудобство в том, что помещение где стоит машинка абсолютно не проветривается. И нет (пока) никакой возможности организовать какой-либо вентканал.
Своя квартира, своя жизнь.
Переезд - это маленькая катастрофа. Честно говоря, я слабо себе представлял, как это будет происходить в нашем случае, но во вторник, 1 июля 2008 года это все таки произошло. Мы переехали на новую квартиру, где теперь будем жить.
Хотелось бы выразить благодарность Косте, Димону и Сереге за то, что помогли перевезти все то барахло, что нажили мы с женой за два года. Вещей хоть и было сравнительно не много, но тем не менее, в шестнадцатикубовой “Газели” места после погрузки практически не осталось. Да и занести на этаж помогли ребята не слабо.
В новой квартире ремонт до конца еще не закончен. Вещи немного разложили, расставили по местам предметы интерьера, но пока что большая часть шмоток все еще хранится в мешках и сумках. Ждем, что к концу этой недели “приедет” шкаф-купе, который мы заказали у знакомого умельца. С появлением шкафа можно будет разложить практически все вещи. Места в нем будет предостаточно.
Кухня пока с недоклеенными обоями. Но в ней уже лежит на полу кафель, а потолок зашит пластиком. В принципе, кухня останется последней головной болью. Сейчас там не особо уютно. Саму кухню (мебель) еще предстоит купить, но это будет несколько позднее.
Вообще, переехав в свою квартиру мы оба как-то почувствовали себя иначе. Ощущается, что это свое! Сколько души было вложено в ремонт… Здесь стало гораздо уютнее, чем раньше в старой съемной квартире.
За довольно короткий срок (спасибо добрым коллегам) провели в новую квартиру и DSL линию. Ну, а как же? Интернет в доме - это святое!
В съемной квартире старая линия пойдет на снятие. А сервер теперь переедет с пыльного балкона в маленькую уютную кладовку, где для него (и для свитча) уже приготовлена силовая розетка 220 V и ethernet разводка.
В комнате компьютерный стол поместился в уютной нише. Настолько он там органично смотрится, что теперь и работать за ним, я уверен, будет гораздо приятней, чем ранее. Не помешают над ним книжные полки, которые, надеюсь, в ближайшее время там появятся.
Хорошо дома. В прежней квартире я чувствовал себя как-то по другому. Энергетика там была какая-то неприятная, что-ли. А здесь просто отдыхаешь. И кошки как-то по другому ведут себя. Видимо, и им на новом месте лучше.
* * *
Как в старом советском мультфильме про домовенка: ” - Какое счастье!!!“. ” - Где? Где счастье?“. “- Счастье - это когда все дома.” Можно к этому добавить только одно: “…у себя дома“.
~/.forward - почему может не работать пользовательская переадресация почты
Обычно, если почтовый smtp сервер на FreeBSD настроен с использованием аккаунтов системных пользователей (из /etc/passwd) и не используется какая-либо специфическая конфигурация вроде “почтовых каталогов” (maildir), то вся входящая почта отдельного пользователя складывается в “почтовый ящик” формата mbox, представляющий собой обычный текстовый файл. Письма в нем, вместе с RFC заголовками будут записываться последовательно один за одним. Располагается этот файл в каталоге /var/mail/. mbox файлы называются обычно так же, как и имя пользователя. Для каждого пользовательского mbox выставляются права “user:user -rw——-”, чтобы обычные пользователи могли получать доступ только к своему файлу почты.
Для того, чтобы почта не складывалась в mbox пользователя, а перенаправлялась на сторонний почтовый сервер, можно настроить переадресацию. Для sendmail (а на тестовом сервере у меня работает именно он) это делается через указание алиаса в файле /etc/mail/aliases. Но изменить в нем что-либо может только root. Обычный пользователь может сам изменить адрес перенаправления, создав в своем домашнем каталоге файл .forward и указав в нем всего лишь адрес электронной почты, куда нужно передать всю почту для этого пользователя. Можно указать несколько адресов, каждый из которых (если я не ошибаюсь) должен начинаться с новой строки.
|
|
|
|
|
|