Назад | Перейти на главную страницу

Поддержание синхронизации двух серверов - вторичный сервер загружается только для резервного копирования или находится в отключении

Я только что начал новую работу по разработке программного обеспечения, но в основном мне было поручено множество задач системного администратора, потому что команда разработчиков состоит всего из 2 человек + технический директор. У меня практически нулевой опыт работы с разными вещами, и я сосредоточился в основном на программировании настольных компьютеров в университете. Надеюсь, вы, ребята, поможете мне с тем, что я здесь пытаюсь сделать ...

Итак, у нас будет два инстанса Amazon EC2, которые будут запускаться точно так же (но установлены в разных местах, поскольку в последнее время Amazon был довольно нестабильным), один из которых действует как главный, а другой как резервный. Оба они работают под управлением Windows Server 2008, но настроены с использованием XAMPP для обслуживания веб-службы mySQL / PHP. Идея состоит в том, что в случае сбоя и т.п. мы можем изменить наши настройки DNS, чтобы они указывали на резервный экземпляр, просто чтобы минимизировать время простоя. Поскольку есть транзакционная база данных и загрузка файлов, мне нужно все синхронизировать. Проблема в том, что резервный экземпляр не будет работать все время. Мне сказали, что нам нужно держать его в выключенном состоянии все время (кроме случаев, когда мы «синхронизируем» серверы), чтобы сократить расходы.

Из того, что я могу сказать, репликация master-to-master между базами данных будет работать нормально, поскольку она по существу «синхронизируется», когда экземпляр подключается к сети. Прав ли я, думая, что это сработает? И как лучше всего синхронизировать каталоги? Еще одна проблема, о которой я думал, заключается в том, что я просто выполняю «резервное копирование» основного сервера на резервный сервер, когда резервный сервер фактически используется (в случае простоя), как можно автоматически отменить процесс?

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

Быстрый и простой подход - резервное копирование базы данных каждый час /, затем rsync (для Windows попробуйте Deltacopy rsync) файлы резервных копий и другие каталоги на сервере резервного копирования. Затем на сервере резервного копирования напишите сценарий для восстановления файла резервной копии базы данных, который запускается каждый час.

rsync будет передавать только дельты файлов и сжимать их при передаче.

Идея состоит в том, что в случае сбоя и т.п. мы можем изменить наши настройки DNS, чтобы они указывали на резервный экземпляр, просто чтобы минимизировать время простоя.

FFS, я бы не стал называть минимальное время простоя в 3 часа минимальным временем простоя.

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

Не пытайтесь перенастроить архитектуру на лету с помощью DNS - это занимает слишком много времени.

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