RDot

RDot (https://rdot.org/forum/index.php)
-   Web-среда/Web-applications (https://rdot.org/forum/forumdisplay.php?f=9)
-   -   Горизонтальное масшатибрование, а так же шардинг MySQL (https://rdot.org/forum/showthread.php?t=3189)

byabuzyak 11.07.2014 20:50

Горизонтальное масшатибрование, а так же шардинг MySQL
 
Доброго времени суток, уважаемые товарищи. У меня такой интересный вопрос.

Есть один большой и интересный проект, с высокой посещаемостью.
Сейчас, каждый раз при обновлении продакшен сервера приходится вешать для пользователей заглушку, обновлять сервак, быстренько тестить и снимать заглушку.
Этот вариант вообще не приемлем.

Я вижу вариант примерно таким:

Горизонтально масштабируем наш сервер, тем самым распределяя нагрузку с одного на два. Когда наступает время апдейта, мы переключаем весь трафик на сервер #1 и в то же время апдейтим сервер #2, а затем то же самое, только наоборот. При этом пользователи ничего не замечают и счастливо продолжают пользоваться сайтом.

Но вот возникает вопрос, как быть с MySQL ? В случае если есть миграции, сайт может валиться из-за ошибок недостающих полей, таблиц либо данных.

Что предложите ?
Спасибо за внимание.

HeartLESS 11.07.2014 20:57

сервер в мулскулом держать отдельно, если боитесь уронить целиком машину, нет?

byabuzyak 12.07.2014 01:41

Нет. Дело не том, что боимся уронить целиком.
Смотрите, например у нас есть таблица - table__a, со следующей структурой: col_1, col_2, col_3. И в нее делаются запросы типа: INSERT INTO `table__a` (`col_1`, `col_2`, `col_3`) VALUES (q1,q2,q3);

Мы обновили сервер #1, (в это время клон нашего сервера - cервер #2 продолжает работать с текущей базой) накатилась миграция, которая удаляет из данной таблицы поле col_3. И при попытке такого запроса с сервера #2, на котором еще нет нового кода - будет валиться ошибка.

Надеюсь примерно смог объяснить что я имею в виду..

NameSpace 12.07.2014 07:18

А где здесь проблема? Вы можете сначала обновить сервер #1 (не удаляя колонки, но добавляя, если то требуется), затем обновить сервер #2, а уже потом удалять лишние колонки.

Сработает только тогда, когда в каждом запросе строго прописаны имена колонок и отсутствуют обращения к ним по их номеру.

SynQ 12.07.2014 11:07

Цитата:

Сообщение от byabuzyak (Сообщение 36460)
быстренько тестить

Обычно не так делается. Ставят staging сервер, на котором все и тестируется прежде, чем выкатывать изменения на production.

byabuzyak 12.07.2014 12:57

Конечно же, у нас есть несколько тестовых серверов, на которых тестеры все тщательно проверяют перед заливкой в продакшен. Однако, мало ли что может быть. Поэтому вот так.

m0Hze 13.07.2014 02:57

Ну самое простейшее что приходит в голову, это использовать систему с двумя БД/ерверамиБД.
Имеем конфиг, в котром прописывается production_db_name="master_db" && backend_db_name="sclave_db".
Далее, при переключении сервака для апдейта, мы просто проверяем, if(IS_TIME_TO_UPDATE) .. выбор БД/сервера.
Такой вариант не пройдет? Его можно упростить как угодно.


Часовой пояс GMT +3, время: 22:14.

Powered by vBulletin® Version 3.8.5
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd. Перевод: zCarot