У меня есть настройка главного/подчиненного серверов MySQL. Я беспокоюсь, что если главная база данных будет взломана и хакеры удалят таблицы или полностью удалят базы данных, все изменения будут распространены на подчиненную базу данных, удалив их и там.
Какой хороший способ не допустить уничтожения хакером моей подчиненной базы данных без использования задержек?
решение1
Настройка MySQL Master/Slave хорошо подходит, когда вы хотите создать отказоустойчивую внутреннюю базу данных для вашего веб-приложения или веб-сайта.
Если главная база данных выходит из строя, вы можете переключить приложение на использование подчиненной. Таким образом, такой подход может работать только как решение для аварийного восстановления в случае аппаратного или программного сбоя на сервере, на котором размещена главная база данных.
Однако, как вы упомянули, если хакер удалит данные из главной базы данных, изменения быстро будут подхвачены подчиненной базой данных.
Для безопасности я бы посоветовал вам создать автоматизированный бэкап базы данных на слейве. Вы можете использовать такой инструмент, какautomysqlbackup.
Имея резервную копию, вы можете восстановить базу данных в исходное состояние с помощью журналов подчиненных серверов.
Если вы хотите разработать собственный инструмент резервного копирования, обязательно укажите временную метку резервной копии базы данных, чтобы вы могли идентифицировать самую последнюю резервную копию.
Кроме того, если вы чувствуете, что у вас нет времени на создание безопасного и отказоустойчивого кластера базы данных для вашего приложения, я бы посоветовал вам использовать самостоятельные решения MySQL, такие как ApsaraDB. С таким решением ваша база данных защищена от DDoS, SQL-инъекций и атак методом подбора.
Надеюсь, это поможет.
решение2
Удалите излишние разрешения из ваших приложений. Это, вероятно, не защитит от 'DELETE FROM table', если вы не можете удалить это разрешение безопасно;
Итак, сделайте резервные копии в виде моментального снимка (mysqldump --single-transaction / lvm / xtrabackup) и сохраните позицию бинарного журнала. Сохраните файлы бинарного журнала (сопоставляя записи, отмечая, что журналы master/relay отличаются) и убедитесь, что бинарный журнал не очищен.
Протестируйте процедуру восстановления, применив двоичный журнал к указанной точке, чтобы убедиться, что у вас есть правильная информация и процедура для случая, когда вам нужно ее использовать.