#php #mysql #replication #restore
#php #mysql #репликация #восстановить
Вопрос:
Итак, я рассматриваю настройку репликации MySQL в очень простой настройке master / slave. Мы рассматриваем это в основном из-за сбоя сервера, а не аварийного восстановления, поэтому меня больше всего интересует отказоустойчивость. Все наши приложения написаны на PHP, поэтому я полагаю, что было бы довольно просто просто установить что-то в MySQL connect, чтобы, если не удается подключиться к основной базе данных, мы записали файл, выполнили сбой на подчиненном устройстве и использовали это.
Моя проблема заключается в том, какой наилучшей практикой для повторной синхронизации этих данных после отработки отказа была бы, или если есть лучшее решение.
Сам переход на другой ресурс должен быть автоматизирован, но процесс восстановления может быть ручным, и мы хотим сделать это через глобальную сеть. Заранее спасибо за помощь
Редактировать
После прочтения об архитектурах Master / Master и Master / Slave мне на самом деле не совсем ясно, какая настройка лучше всего подходит для моего сценария. Сами базы данных довольно большие (в настоящее время у меня нет точного размера) и представляют в основном данные транзакций / журналов (с некоторой незначительной аутентификацией и проверкой дубликатов). По большей части строки не будут изменены, только добавлены в базу данных.
Моя основная задача / использование реплицируемого сервера — это отказоустойчивость, поэтому, хотя репликация Master-Master кажется идеальной для этих целей, при чтении о них создается впечатление, что как только этот отказоустойчивость действительно произойдет, и записи будут добавлены в базу данных B, восстановить базу данных A будет сложнее, чем в отношениях Master-Slave.
Элементы не удаляются ни из одной базы данных, кроме как во время свертки / архивирования, и мы можем просто добавить функциональность для проверки доступности обоих серверов в течение этого времени для настройки Master / Slave. 15-20 минут времени восстановления может быть достаточно в ситуации аварийного восстановления, когда произошел переход на другой ресурс, но не на постоянной основе каждую ночь. Надеюсь, это поможет внести ясность в ситуацию.
Комментарии:
1. Это больше похоже на то, что вам нужна репликация типа Master-Master.
2. После дальнейшего рассмотрения это больше похоже на Master-Master… Я не знал, что это возможно. Я продолжу исследование и отредактирую по мере необходимости. Спасибо Ed
Ответ №1:
Здесь играет роль множество факторов. В зависимости от размера базы данных, вы можете создать алгоритм для захвата того, что изменилось (т. Е. сохранить дату / время при переходе на отказоустойчивость или МАКСИМАЛЬНЫЕ идентификаторы) и просто использовать эти данные для заполнения новой базы данных. Это вызвало бы проблему с удаленными элементами. Если элементы действительно удалены, а не просто имеют дату, установленную для момента удаления.
В зависимости от размера, вы можете закрыть сайт для обслуживания на 15-30 минут, выполнить дамп SQL и просто обрезать таблицы и повторно импортировать данные через интерфейс MySQL CLI, это может занять некоторое время, в зависимости от данных.
Что лучше, все зависит от ваших потребностей. Последний, потенциально может быть написан сценарием, в котором он может отключить сайт для обслуживания, затем извлечь данные с FailOverServer на RegServer, а затем реализовать серию команд MySQL для усечения RegServer и импорта данных с FailServer после завершения включения сайта обратно.
Я никогда этого не делал, поэтому не могу сказать, подходит ли это. Но до тех пор, пока на сервере FailOverServer не будут изменены таблицы, он должен работать нормально.
Комментарии:
1. Спасибо, Брэд, я обновил исходный вопрос для некоторых ответов здесь. Не могли бы вы пояснить, что за обслуживание, о котором вы упомянули, это было бы неправильно по ночам? Просто по мере необходимости, если мы запустили переход на другой ресурс? (Я не настраивал репликацию раньше)
2. Да, это было бы основой по мере необходимости. Но вам нужно будет постоянно обновлять отказоустойчивый сервер, чтобы он мог выполнять отказоустойчивость. Я не уверен, каким был бы наилучший способ сделать это, поскольку я не делал этого раньше. Когда у меня будет возможность, я посмотрю, нельзя ли еще немного покопаться в синхронизации.