Тут вопросы скорее теоретические, допустим есть highload проект - мастер сервер mysql, бд его весит 350 гигабайт 1. Как организовать 100% отказоустойчивость? 2. правильно понимаю что надо сделать второй резервный мастер в случае сметри мастера, быстро переключаем все слейвы на второй резервный мастер, так? 3. использовать RAID 6? 4. как сделать второй резеврный мастер? 5. чем резервный мастер отличается от одного из слейвов? 6. резервный мастер нужно ставить в тот же дц что и первый, чтобы пакеты быстрее доходили? возможно ли теоретически потеря пакетов т.е. данных на втором мастере? 7. если ставить в тот же дц - как застраховаться от пожара? скорее всего надо сделать два резервных мастера? один в том же дц - застрахованный от потери пакетов, второй в другом дц - застрахован от случая пожара в первом дц? 8. как организована бд например сбербанка?
У меня тоже сложилось впечатление что все все знают, а нет , так и приходится создавать темы с просьбой помочь, а в итоге получается два чела что-то посоветовали и все затихло.И остальные сообщения остаются все твои (сам с собой пишешся и все). Посто словл себя на мысли)
Во-первых, true master-master, это миф для mysql. Т.е. если мы говорим о синхронном master-master (ведь речь о отказоустойчивости). Во-вторых, нужно определить суть проблемы, чего вы хотите добиться. Говоря о «отказоустойчивости», надо понимать, что при нормальной конфигурации сервера, он проживёт вечно или условно вечно, а если вы уже реализовали master-slave реплику, то падение мастера хоть и приостановит работу проекта, но не на долго. На моей практике (более 10-ти лет), у меня лишь дважды выходили из строя винты, оба раза без остановки проектов. Первый проект соцсеть уровня вконтакте 4-х летней давности, отдавал из базы картинки, масштабируя их на лету. Загнулся винт IBM, винты были в зеркале (raid0), поменяли быстро без проблем, решили не сохранять картинки в базу ))) второй проект —*файлообменник, аля рапидшара, депозитфайл итп. Платформа статики была построена на самых дешёвых компах. 2u сервер с 8 терабайтами на борту выходил в 75к рублей 3 года назад, что было очень дёшево для таких конфигураций. Соответственно, все ЗЧ собирал руками с самых дешёвых поставщиков. Опять же, raid5 спас ситуацию. Но там такая ситуация была чуть не рядовой. Каждый 2u сервер имел по 4 сетевых и отдавал по всем интерфейсам 12 мегабайт в секунду почти 21 час, т.е. почти все сутки на пролёт все 4 сетевый были забиты трафиком, считай 48 мегабайт в секунду читались постоянно с винтов. Винты были гражданскими, самыми дешёвыми. Вышли из строя через 2 года. Я всё это к чему? К тому, что если вы переживаете за то, что у вас накроется дисковая система и для этого хотите master-master, то забудте. master-master в тех реализациях, что существует сегодня, требует серьезного изменения кода софта + даже при идеальном коде не гарантирует подводных камней при сбоях. Если вы боитесь за винты —*юзайте обычную master-slave реплику, обычную пирамиду. Т.е. условно у master есть 2 slave + сделайте ещё один слейв, который отличается от других лишь тем, что к нему софт вообще не обращается. Он не readonly, он полноценная база, но софт его не юзает. Такой горячий бэкап. Если вдруг master выходит из строя, этот сервер в течении 10 минут можно сделать боевым мастером и продолжить работу. Если 10 минут критичны, можно написать скрипт, который автоматом перекинет мастера на этот сервер, если вдруг основной недоступен. Это не true master-master, но решит вашу проблему. Если вы боитесь за свой ДЦ, логично реализовать master-master (active-passive), имея сервера в разных ДЦ. Это прям тру отказоустойчивость. В случае, если один ДЦ накрывается (свет, наводнение, ддос или ещё чего), проект без секунды паузы продолжает работать. Для реализации подобного метода, вам нужно примерно одинаковые массивы серверов в ДЦ1 и ДЦ2. Соответственно, фронт+бэк проблем особых не вызывает, проблемы появляются при реплике базы. active-passive предполагает смесь master-master и master-slave. Точнее это классический master-slave, разве что slave является мастером для первого мастера. Т.е. базы друг друга обновляют. В этом случае можно реализовать, как я уже говорил, не плохую отказоустойчивость даже в случае, если один из ДЦ мёртв. Лично я сейчас занимаюсь разработкой SaaS продуктов и юзаю именно эту схему, ибо в случае с SaaS я не могу упасть не на секунду, иначе клиенту уйдут. True master-master делает сейчас перкона, galera. Но все они имеют кучу ограничений и подходят лишь для узкого круга проектов. В общем случае, как я уже говорил, либо master-slave классический с горчей базой, либо active-passive, но его смысл отказоустойчивости при падении ДЦ, этот способ избыточен, т.к. предполагает наличие 2x серверов от нужной мощности. Скажем, FB или ВК не юзают такие технологии, они слишком накладны ) много проще построить свой ДЦ и обеспечить его качественным каналом, надёжными упсами итп. Сбербанк сидит на оракле (грины поправьте, если ошибаюсь), там master-master реализован нормально ) как и в постгрисе, если не ошиюаюсь. В любом случае, если вы задумались о master-master в любом виде, убедитесь, что ваш софт не использует запросы типа: 1) INSERT INTO table SET time=NOW() 2) INSERT INTO table SET int=RAND() 3) UPDATE table SET int=int+1 итп. Подобные структуры рушат любые попытки синхронной репликации. Если расскажете подробней о вашем проекте, могу помочь с реализацией полной отказоустойчивостью. Опыта, благо, хватает. Можно в личку.
Trinux, спасибо за большой ответ быстро развернуть новый мастер из горячего слейва не проблема, мне интересно было чтобы не один байт информации пользователя не потерялся, вообще 100% сохранность т.е. если пользователь изменил email и через секунду мастер умер, у меня была актуальная база с измененным email как сбербанк страхуется от пожара? у них ведь все в одном ДЦ, мастер-мастер может не помочь
Если мы говорим о одном ДЦ, т.е. если нет задачи разнести master сервера по разные ДЦ, то active-passive более чем подходит и будет работать очень быстро. К сожалению, стандартный master-slave в мускуле тоже не очень то стабилен. Мы сейчас переводим все массивы на percona server, он выглядит стабильнее и пока вроде багов не было. Поживём увидим. Сбербанк, как и фейсбук, как и вконтакте — им проще построить свой ДЦ с супер надёжными системами пожаротушения итп, нежели чем разносить master-master по разным ДЦ. Хотя, я уверен, такие структуры как сбербанк, делают бэкапы своих данных на сторонние сервера, однозначно. Раньше была единая система для банков страны на основе x25 сетей, что сейчас я не знаю, да и не очень то интересно ) В моём случае, проект ещё не настолько велик, чтобы строить свой ДЦ (да и никогда не вырастит до таких объёмов), поэтому нам проще раскидать master сервера по разным ДЦ. Это накладывает тормоза + всё равно мы не можем быть до конца уверены, что все данные 100% будут синхронны всегда. Но это защитит нас от простоя одного из ДЦ.
Поговорил со своими ребзями, мы прикинули и решили, что в вашем случае есть резон делать не зеркало в разных ДЦ, а взять качественный ДЦ. tier-4 в европе, поставить туда своё оборудование. Чтобы было прям надёжно, прикинули, что лучше не master-slave реализовать, а percona cluster, решение показывает себя как более надёжное, чем стандартный master-slave. Для пущей надёжность можно развернуть в облаке амазона мощные сервера, грубо полный аналог основного ДЦ, за исключением того, что под базу один сервер. Он будет пассивным мастером к активному мастеру percona cluster, т.е. реплика будет проходить асинхронно. В случае жестица в tier-4 (простой которого не более 30 минут в год), сервис за пару секунд переключится в амазаон. Амазон тем временем, пока будет стоять, не будет жрать денег вообще. Только за траффик реплики, копейки. Получается, что даже если отказывает ДЦ или перкона-кластер, ваши клиенты этого не заметят. Тут один подводный камень — в случае падения основного дц, переключение на амазон произойдёт автоматически. А вот обратно —*хрен. Прийдётся останавливать сервис на пару минут, пока не перекинешь с амазона базу на основной ДЦ и не вернёшь основному приоритет.
