С репликацией серверов MySQL я познакомился относительно недавно, и по мере проведения разных опытов с настройкой, записывал, что у меня получалось. Когда материала набралось достаточно много, появилась идея написать эту статью. Я постарался собрать советы и решения по некоторым самым основным вопросам, с которыми я столкнулся. По ходу дела я буду давать ссылки на документацию и другие источники. Не могу претендовать на полноту описания, но надеюсь, что статья будет полезной.

Постепенный перевод предприятия на GNU/Linux порождает необходимость соответствующих изменений в инфраструктуре. Сегодня мы решаем проблему глобального обновления клиентских машин путем создания локального репозитория. Процесс изначально документировался как памятка на будущее, потому заранее прошу прощенья за возможные несуразности в тексте. Итак.
Для начала следует определиться, посредством чего лучше сделать это. Интернеты выделяют двух фаворитов rsync и debmirror. Выбрал последний, ввиду его большей гибкости.

1. Получение ключей

Для создания зеркала репозитория необходимо получить ключ «Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>». Для этого в терминале от суперюзера вводим:
gpg --no-default-keyring --keyring trustedkeys.gpg --recv-keys 437D05B5

Привет! Бывает, хочется забыть о «скучной» консоли, разбавить ее хоть капелькой интерактива, особенно если часто приходиться делать одни и теже операции и тем более если вы пишите для облегчения своей участи скрипты. Итак, псевдографика. За мной читатель, я покажу тебе такую консоль!

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

HA-Apache2 Web-Site and HA-MySQL

Цель: обеспечить высокую доступность web-приложения и минимальное время простоя при отказе одного как web-сервера, так и сервера баз данных.
Замечание! Схема предполагает, что web-приложение и база данных находится на разных серверах.
Для примера будем устанавливать wordpress.

Вариант решения:
Поскольку web-приложение должно быть постоянно доступно, то необходимо минимум два сервера с установленным приложением. Серверы будут отслеживать состояние друг друга, при этом в каждый момент времени ведущим будет только один из них. В случае отказа ведущего сервера его роль принимает второй. Когда первый сервер будет вновь доступен, к нему опять вернется роль ведущего.

Задача

Установить Debian Lenny на сервер, который находится на удалённой площадке.
На площадке уже есть один Linux-based сервер, и есть инженер, который может подключить новый сервер к сети и включить.

Решение

Загрузить образ netinstall по PXE и воспользоваться пакетом network-console для установки, используя ssh.

Узнать, как отмасштабировать Ваше приложение, не имея при этом никакого опыта, — это очень нелегко. Сейчас есть много сайтов, посвященных этим вопросам, но, к сожалению, не существует решения, которое подходит для всех случаев. Вам по-прежнему необходимо самому находить решения, которые подойдут под Ваши требования. Так же, как и мне.

Несколько лет назад ко мне пришел мой босс и сказал: «У нас есть новый проект для тебя. Это перенос сайта, который уже имеет 1 миллион посетителей в месяц. Тебенеобходимо его перенести и убедиться, что посещаемость может вырасти в будущем без всяких проблем.» Я уже был опытным программистом, но не имел никакого опыта в области масштабируемости. И мне пришлось познавать масштабируемость трудным путем.

Существует множество фичей упрощающих жизнь системному администратору. Различные системы удаленного управления позволяют установить ОС на девственно-чистый сервер и сегодня это совсем не проблема. Даже наличие второго винчестера превращает проблему переустановки операционки в банальность. Поэтому в этой статье рассмотрим самый суровый из случаев: пусть на сервере имеется только один полностью разбитый винчестер, а наша задача — удалённо переустановить ОС.

Удивлённо поднимем брови, умиляясь тому, как гибка наша любимая операционка, засучим рукава и приступим к делу.

Иногда необходимо прописать DNS для компьютера с динамическим IP адресом. Простым путем для этого являются сервисы по типу dyndns, описанные в недавнем топике Связываем домен и динамический IP. Иногда такой подход работает достаточно плохо.

Напрмер в моей ситуации, провайдер иногда меняет мой публичный IP адрес. Это иногда случается обычно раз в несколько месяцев. Кроме того, мой домашний компьютер перезагружается крайне редко. За это время сервис dyndns, которым я пользовался ранее успевал пару раз прислать мне оповещения о неактивности с целью отключить «неиспользуемый» аккаунт. Перейти на вручную прописываемую DNS зону также не получается, потому что иногда адрес все же меняется. Причем обычно об этом узнаешь когда нужен доступ к домашнему компьютеру здесь и сейчас.

Для реализации описываемого метода понадобится сервер в интернете с DNS сервером bind на нем. А так же доменная зона, субдомен которой мы будем выделять для нашего компьютера. Описывается вариант с подключением Linux-компьютера к Linux-серверу. Для использования других операционных систем понадобится почитать мануалы и модифицировать некоторые шаги.

Большинство разработчиков на MySQL знакомы с командой EXPLAIN, однако значительно меньше людей знают о команде EXPLAIN EXTENDED, появившуюся ещё в MySQL 4.1, и ещё меньше умеют ею пользоваться.

EXPLAIN EXTENDED умеет показывать, что же конкретно делает с Вашим запросом оптимизатор MySQL. Для разработчика может быть совсем не очевидно, насколько сильно может отличаться написанный им запрос от того, который в действительности будет выполнен сервером. Этот процесс называется механизмом перезаписи запросов (query-rewrite), и он является частью любого хорошего SQL-оптимизатора. Команда EXPLAIN EXTENDED добавляет дополнительные предупреждения (warnings) к выводу команды EXPLAIN, в том числе и переписанный SQL-запрос.

Пару дней назад обратился ко мне человек с достаточно рутинной просьбой: подкрутить настройки VPS для его ускорения — за последнее время на сайте был резкий рост посещаемости, и сервер в часы-пик стал совсем загибаться.

Это была бы рядовая и унылая статья про nginx и opcode-кеширование, если бы сервер не был до этого «прооптимизирован» техподдержкой хостера :-)

О том, что я обнаружил в процессе оптимизации, я и пишу эту небольшую заметку, дабы уберечь других от подобных фокусов хостеров. :-)

Внимание! Данная статья для web-программистов — содержит исходники и техн. подробности.

У Вас было такое – что простой вопрос повергал Вас в ступор и глубокие раздумья? У меня такое случается каждый раз, когда клиенты или друзья спрашивают меня:

— Андрей, какой хостинг порекомендуешь для нашего сайта?

И ответить нечего, потому что все (все!) наши замеры не в пользу хостинговых компаний, даже никого конкретно приводить не буду — сами сможете проверить, выполнив рекомендации в этой статье.

Казалось бы, где зарыта собака? Ведь для нас хостинг – это одна из любимейших мозолей, на которую часто наступают, потому что мы – SEOнизаторы. Мы трудимся – чтобы выводить свои сайты и клиентов в топы, а плохой и нестабильный хостинг распугивает сканирующих роботов Яндекса, Гугла и иже с ними. Впрочем, часто хостинг валится и днём, особенно во время пиковых нагрузок около 18:00 из-за наплыва в Интернете зевак под вечер.

Вот самое простое, что бывает – сайт исправно работает днём, пока бдит саппорт хостера. А ночью иногда исправно «лежит» в нокдауне. Например, скрипты хостера делают бекапы и все перегружено. Клиенты спят, покупатели спят, сайт спит. Все довольны, кроме поисковых пауков.

Первое, что мы сделали – купили свой дорогой сервер и отвезли его к Каравану (спасибо ребятам за отличное качество колокейшн). Но сервер у нас не резиновый, и как услугу хостинг мы не предоставляем. Поэтому пустить всех наших и не можем.

Чтобы как-то контролировать ситуацию – я написал пару лет назад монитор стабильности хостинга. Сейчас, когда у нас уже много других конкурентных преимуществ – мы готовы выложить исходники и алгоритм работы для Хабраобщественности, чему и посвящен этот пост.