Сегодня хочу рассказать о появившейся возможности практически неограниченно увеличить "мощность" базы данных интернет-проекта - путем ее кластеризации.
Все лучшее ... Базе!
Обычно для высоконагруженного сайта, особенно со сложной бизнес-логикой, покупают/арендуют отдельный сервер. Мы же не хотим заставить Клиента ждать 10 минут, пока пройдет его платежная транзакция или выгрузится отчет?
Сервер базы данных, так сказать "сердце" сайта, выбирают и покупают, можно сказать, "с трепетом" - еще бы, тут будут хранится оформленные и оплаченные заказы, лицевые счета, персональные данные Клиентов и прочая критичная для бизнеса информация.
Да, мы выбираем конфигурацию для сервера базы данных с резервным блоком питания, подключенным к отдельной шине питания в датацентре, с задублированными вентиляторами.
Иногда, зная что пролет элементарной частицы через микросхему оперативной памяти может инвертировать бит информации, мы устанавливаем более дорогую память типа (я не шучу, такие технологии нередко востребованы, например в системах управления полетами, медицине и др.).
Для быстрой работы дисковой подсистемы, если позволяет бюджет, мы конечно используем эффективный и надежный . Ну или хотя бы, как минимум, - для надежного зеркалирования информации.
Для быстрой работы базы данных нам все чаще требуется распространенная сейчас (write back disk cache). Разумеется, зная, что при экстренном выключении питания рейд-контроллер или жесткий диск может потерять закэшированную им информацию (несколько заказов, финансовых транзакций) - мы обязательно покупаем .
Ну и конечно мы устанавливаем на наш сервер побольше оперативной памяти. Идеальная ситуация, это когда база данных полностью помещается в оперативную память. Например у магазина база занимает 10 Гигабайт - вот если установить на сервер 15 Гигабайт - приложение будет нам благодарно
(иначе будет происходить периодическая загрузка данных базы с диска, что конечно медленнее).Если мы работаем на MySQL - то, как известно, самый производительный (данные размещаются в оперативной памяти) и устойчивый к конкурентной нагрузке формат базы данных - Innodb.
И еще раз внимательно просмотрев мы наконец запускаем быстрый, надежный и крутой сервер базы данных!
Да, да. Мы еще настроили резервное копирование информации из базы данных. Оно делается раз в сутки и архив переносится на отдельный сервер бэкапов ( расположенный в отдельном охраняемом помещении ).
Можем ли мы быть теперь уверенными в быстрой и надежной работе базы данных интернет-проекта?
К сожалению, нет. Мы упустили два ключевых риска...
Проблема 1 - Дорогое масштабирование вверх
В наш век информации, когда объемы данных экспоненциально увеличиваются каждый год, мы достаточно быстро (кто через полгода, кто через 1-2 года) упремся в производительность сервера базы данных.
Почему? Ведь мы все тщательно будем кэшировать, мы собрали крутой сервер базы данных, быстрый и с большим объемом оперативной памяти...
Дело в том, что интересной и ценной для принятия бизнес-решений информации - много и ее будет все больше и больше. Вы захотите, к примеру, сохранять пути клиентов по сайту и их хиты на ... полгода для детального анализа отделом маркетинга.
Или вам потребуется открыть и подключить к интернет-сайту десяток-другой филиалов с каталогами и ценами и отдельными остатками. И очень захочется (именно захочется) синхронизировать информацию в каталогах с 1С каждые, к примеру, 5 минут.
И наш крутой и мощный сервер базы данных через определенное время начнет уже неуспевать и спотыкаться за полетом фантазии и креативных идей руководителя интернет-проекта.
Вы достаточно быстро выпустите "последнюю пулю" - купите самый самый быстрый процессор и самую большую планку памяти (причем топовые, самые быстрые комплектующие стоят значительно дороже - зависимость нелинейная), которые еще можно установить в сервер базы данных и ... и всё.
Я нередко вижу проекты, которым для базы данных уже не хватает 8 ядер и 32G оперативной памяти.
Придется снова покупать и настраивать мощный сервер. Или может купить для сервера базы данных
Решение проблемы 1 - "Master-Slave репликация"
Master-Slave репликация, доступная в модуле платформы "1C-Битрикс: Управление сайтом", позволяет эффективно решить описанную выше проблему вертикального масштабирования сервера базы данных.
Технология репликации базы данных существует довольно давно и она успешно используется для решения задач повышения производительности. Однако мы понимаем, что в данном случае приложение работает не с одной, а несколькими базами данных:
- в одну базу данных приложение пишет (есть еще более сложные варианты, но опускаем их)
- из остальных читает
Сложность в том, что если сразу при разработке приложения не учитывать что оно в будущем должно работать с несколькими базами данных, переделать его когда это потребуется может оказаться сложной и трудоемкой, а иногда и практически невыполнимой задачей ( ради эксперимента, спросите у разработчиков проекта - сможет приложение работать с двумя базами данных? и вы будете удивлены ответом ).
Благодаря тому, что возможность работы с несколькими базами данных была изначально заложена в архитектуру платформы 1С-Битрикс и реализована в кластерных редакциях, вашему проекту открываются новые вершины производительности.
И, на что хочется обратить особое внимание, В КОД РАБОТАЮЩЕГО ПРОЕКТА ПРИ КЛАСТЕРИЗАЦИИ БАЗЫ ДАННЫХ НЕ НУЖНО ВНОСИТЬ ИЗМЕНЕНИЯ! Технологию распределения запросов на серверы базы данных мы взяли на себя, предоставим вам возможность эффективно "дирижировать" нагрузкой через определение весов для каждого дополнительного сервера.
Вам достаточно лишь настроить и подключить к платформе один или несколько стандартных недорогих серверов базы данных, с помощью удобного мастера в течении нескольких минут перенести туда данные и ... наслаждаться увеличенной в N-раз производительностью базы данных!
Если нагрузка через полгода-год на базу данных снова возрастет (вы подключите к проекту еще 5-10 филиалов и откроете 2 языковых зеркала) или планируется увеличение нагрузки в ближайшие выходные в связи с рекламной акцией - вы снова просто можете добавить к платформе стандартный сервер базы данных (операция подключения и миграции данных занимает несколько минут).
Отключается сервер базы данных также легко и интуитивно через админку.
Подключение дополнительного сервера базы данных к сайту занимает несколько минут.
Наслаждаемся эффективной и производительной работой кластеризованной базы данных. Добавляем серверы к кластеру при необходимости - за несколько минут.
Проблема 2 - "Непрерывное" резервное копирование
Итак. Нагрузку на базу данных мы победили и в случае чего - добавим в кластер сервер в течение минут. А как обстоят дела с резервным копированием данных?
Оно выполняется раз в сутки. Иногда этого недостаточно.
Допустим, наш прекрасный мощный сервер базы данных ломается - сгорает процессор или материнская плата или ее элемент. Текущие заказы и транзакции где - на дисках этого сгоревшего сервера. Нужно ехать, вынимать их оттуда, подключать к другому и т.п. - в это время вам будут беспрерывно звонить клиенты.
Есть достаточно сложные решения, как "пережить" выход из строя сервера базы данных, типа DRBD репликации, кластерных файловых систем OCFS2, GFS2... но мы рассмотрим наиболее простое, распространенное и надежное решение - да, да, снова репликацию.
Решение проблемы 2 - "Master-Slave репликация"
Master-Slave репликация, доступная в модуле платформы "1C-Битрикс: Управление сайтом", позволяет эффективно решить задачу "непрерывного" резервного копирования и высокой доступности базы данных.
При репликации, данные с главного сервера базы данных в онлайне передаются на дополнительные (SLAVE) сервера - т.е. вы имеете копию данных = онлайн бэкап в нескольких экземплярах.
Более того, чтобы не замедлять основной и дополнительные сервера при создании логического бэкапа (который также необходимо делать периодически - иначе после случайного удаления, например, таблицы заказов, у вас не будет шансов ее вернуть, т.к. изменения реплицируются на все сервера базы данных) - мы можете выделить для этого отдельный сервер базы данных, на котором и выполнять процедуру создания логического бэкапа:
А для решения задачи быстрого переключения интернет-сайта на работающую базу данных (простой проекта составит пару минут или даже меньше) - вы скриптом или вручную переключаете систему на использование дополнительного сервера базы данных, на котором, благодаря репликации, имеется самая свежая копия бизнес-данных.
Выводы
Мы рассмотрели основные задачи, которые необходимо решить для организации высокопроизводительной и отказоустойчивой конфигурации базы данных, и увидели, как они просто решаются модулем "Веб-кластер" в 10 версии платформы "1C-Битрикс: Управление сайтом" (редакции "Веб-кластер", "Бизнес веб-кластер" ).
В следующей статье поговорим о создании высокопроизводительного кластера серверов приложений - такая задача нередко возникает при создании высоконагруженных интернет-проектов на платформе 1С-Битрикс.
Если же речь идёт об асинхронной репликации, то как решается проблема чтения данных, которые ещё не успели "прососаться" с master'a на slave? Рассмотрим, к примеру, этот блог. Набрав это сообщение, я нажму кнопку "Отправить". Произойдет вызов скрипта, который сохранит мой камент в БД (все insert'ы / update'ы / delete'ы идут на master). После этого, скрипт сделает выборку каментов к текущему посту (все select'ы распределяются между slave'ами). Однако, при асинхронной репликации формально нет никакой гарантии, что только что сохранённое сообщение успеет реплицироваться с master'a на все slave'ы.
Я не силён в MySQL, но если отбросить синхронную репликацию, то в случае с тем же postgresql, эту проблему можно решить через утилиту типа pgPool-II (отсылая insert'ы / update'ы / delete'ы на все сервера кластера).
Или же решение на уровне компонентов: код сам знает, когда важна актуальность данных, а когда можно почитать и со slave'ов?
Речь идет именно об асинхронной репликации, т.к. (Semisynchronous Replication) появилась в MySQL 5.5, т.е. относительно недавно, а кластер должен эффективно работать и на более ранних версиях СУБД.
Задачу выбора откуда читать данные, со слейва или мастера - решает встроенный в платформу балансировщик SQL. Критичные данные читаются всегда с мастера, терпящие отставание - со слейвов.
Для решения этой задачи используется внутренний конвейер - я постараюсь в деталях описать логику его работы в ближайших постах.
Т.е. если приложение работает через API платформы - API само позаботится о адекватности получаемой информации.
Спасибо за ответ! Было бы действительно очень интересно услышать об устройстве этого встроенного балансировщика SQL / внутреннего конвеера!
Проблема 1: если у нас большое количество запросов модификации(insert/update/delete), то нужно понимать, что на каждом слэйве будет выполнено такое же число этих запросов. Как пример - интенсивная запись статистики. К этому стоит добавить, что в mysql в версиях 5.0 и 5.1 (дай Бог памяти) под реплику отводится один тред (с учетом того, что у мастера может быть несколько активных тредов), как следствие, при интенсивной записи может заметно увеличиваться отставание реплик.
Проблема 2: много данных. На каждом слэйве будет копия данных с мастера. Если в таблице 100М записей, попробуйте сделать select...order by...limit по такой таблице
Вывод: если "узким" местом в производительности является запись, обновление или большие объемы данных, репликация не сильно поможет. Вернее она поможет так: будем читать со слэйвов, чтобы снизить нагрузку на чтение с мастера.
Это можно сделать из коробки простой настройкой или нужно повозиться?
Если будет и этот предел достигнут, можно переходить на мастер-мастер. Но мне кажется, что в реальном объеме операций на запись в сотни раз меньше чем на чтение и они эффективны. Т.е. предел очень далекий.
Тут ниже Александр уже заговорил про шардинг
Также, чтобы получить на нем адекватную одному серверу СУБД MySQL производительность, нужно запускать несколько серверов.
Классическая Master-Slave репликация MySQL из-за простоты и надежности очень широко распространена в высоконагруженных проектах, активно развивается и при необходимости эффективно дополняется вертикальным и горизонтальным шардингом (о шардинге в следующих постах).
при подключении выдает ошибку:
Указанная в качестве главной база данных не является таковой.
проблема более подробно описана на
А как тогда быть, если был разработан новый модуль/модернизировался существующий и нужно установить его?
-------------------------------------------------------
Что делать, если нужно настроить репликацию в корп.портале? Как доставить веб-кластер на корп.портал?
Для корппортала тоже есть веб-кластерные редакции - топовые.
Т.е. настроить веб-кластер можно только после апгрейда в редакцию "Холдинг"? Дополнительно доставить веб-кластер на установленную редакцию корп.портала никак нельзя?