У нас есть несколько серверов, на которых работает приложение tomcat с базой данных MySQL. Эти серверы находятся в разных городах, и наши клиенты используют веб-приложение локально.
На этих серверах дважды в день запускается задание crontab, которое создает полную резервную копию баз данных и отправляет (SCP) этот дамп на сервер нашего центрального офиса. Затем мы берем эти дампы и применяем их к локальным базам данных, чтобы в случае возникновения чрезвычайной ситуации наши клиенты могли продолжать использовать приложение через Интернет.
Проблема в том, что с каждым днем дампы становятся все больше, и передать такой объем данных непросто, поэтому мы ищем решение для инкрементного резервного копирования и метод репликации с этим инкрементным.
Не могли бы вы подсказать, как это сделать? Есть другое решение лучше, чем то, что мы хотим сделать?
Спасибо.
Другой вариант помимо использования rsync - настроить репликацию mysql с каждой из обычных баз данных в качестве главных, а базы данных в вашем офисе - в качестве подчиненных для каждого мастера. Вы можете прочитать документацию по mysql здесь.. Если вы хотите сохранить резервную копию в стиле scp / rsync, вы можете добавить сжатие к резервной копии с помощью bzip или каким-либо другим способом. А также есть Zmanda что позволит создавать резервные копии без необходимости запускать ведомое устройство для каждой системы, которую вы хотите создать.
Сохраните предыдущий дамп и используйте rsync или даже лучше, rdiff-backup ( http://www.nongnu.org/rdiff-backup/ ) через ssh вместо простого scp.
Другой потенциальный вариант - использовать двоичный журнал, но не фактическую репликацию, по причинам, указанным syneticon-dj. Сохраните пару дней двоичных журналов (они могут быть большими) и используйте mysqlbinlog инструмент для получения конкретных периодов времени и воспроизведения изменений на центральном сервере в течение дня.
Есть некоторые ограничения производительности и другие ограничения, такие как транзакции, но это может сработать для вашей настройки. У вас также будет хороший контрольный журнал, чтобы точно узнать, когда произошло «УДАЛИТЬ ОТ», например, упоминание syneticon-dj, и вы сможете удалить его из воспроизведения, найти ответственного и т. Д.
Вы, очевидно, захотите сохранить полные резервные копии, но если вы хотите поддерживать центральное обновление в актуальном состоянии, ночная синхронизация полного резервного копирования с промежуточным двоичным кодом, вероятно, будет наименее интенсивной, и вы все равно можете использовать рекомендацию S19N rdiff-backup для каждую ночь.