Мне нужно настроить экземпляр базы данных MySQL в DMZ, который является доступной только для чтения копией действующего мастера внутри защищенной сети.
Репликация MySQL кажется идеальной для этого, за исключением того, что она работает за счет того, что ведомое устройство «вытягивает» изменения от ведущего. Это означает, что подчиненное устройство в демилитаризованной зоне должно иметь возможность открыть соединение с мастером, что не разрешено специалистами по безопасности.
Я играл с настройкой туннелей ssh от ведущего устройства, но ведомый, кажется, держит соединение открытым (даже после вызова «SLAVE STOP»), что означает, что туннель всегда открыт (в некоторой степени нарушая ограничение безопасности).
Есть ли способ заставить mysql разорвать соединение, кроме остановки mysqld?
Есть ли другой способ достичь той же цели, о которой я не думал?
Обновления от ведущего к ведомому должны происходить в режиме, близком к реальному (т.е. допустима задержка в пару минут, но не более).
Подчиненное устройство поддерживает постоянное соединение с главным, но закрывает его, когда вы выдаете команду «STOP SLAVE».
Если ваши данные очень малы и вы можете выдержать задержку в несколько минут, вы потенциально можете написать сценарий с помощью инструмента mk-table-sync от Maatkit, который выполняет эту работу. Он рассчитает контрольную сумму ваших таблиц и выяснит, что изменилось для их применения. Вы можете запускать это с ведущего устройства и периодически подключаться к ведомому устройству в DMZ, что будет намного безопаснее с точки зрения безопасности - даже если злоумышленник скомпрометирует компьютер DMZ и полностью заменит его своим собственным программным обеспечением, он все равно получить не больше доступа, чем снимок базы данных.
Еще одна идея, небольшое изменение того, что вы описали:
Ключевым моментом здесь является то, что туннель создается и уничтожается мастером, обновления запускаются периодически.
Здесь много отличных закусок. Однако все слишком усложняют разные части головоломки.
Мро сказал:
... подчиненный, кажется, держит соединение открытым (даже после вызова "SLAVE STOP"), что означает, что туннель всегда открыт ...
1. Это не роль подчиненного mysqld - завершать входящий сеанс SSH. (Это ближе к тому, как работает туннелирование с помощью netcat, но здесь не место для этого, поэтому давайте не будем путать проблему.) Мастер должен разорвать соединение, потому что [a] оно было инициировано [b] оно было внутри сети вы хотите защитить. Если вы хотите прервать соединение для вызова ведомой стороны "kill -s HUP $pid_of_the_sshd_owned_by_mysqlmaster". Повторюсь, не вижу смысла.
2. Зачем тебе звонить "SLAVE STOP"? Подчиненное устройство является подчиненным. Раз уж мы обсуждаем эту тему ... Подчиненное устройство никогда не должно останавливаться. Если подчиненное устройство будет остановлено, главный сервер (см. Пункт 4.) или это должен сделать администратор.
Мро сказал: Обновления от главного устройства к подчиненному должны происходить в режиме, близком к реальному (т.е. допустима задержка в пару минут, но не более).
Вы не можете получить и то, и другое. У вас либо запущен подчиненный поток ввода-вывода, либо он устарел.
3. Не беспокойтесь о «позиции ведущего в бинарном журнале», это то, что делает встроенная репликация.
4. Если вы действительно настроены на отключение и повторное подключение каждую минуту, напишите cron-скрипт на мастере. Он должен сделать следующее:
ssh -N -R 3333:127.0.0.1:3306 mysqlmaster@slave.server &mysql -hslave.server -e 'SLAVE START'mysql -hslave.server -e 'show slave status\G'|awk '/Seconds_Behind_Master/{print $2}' sleep для этого. Изучите свою систему, чтобы убедиться, что она не потребляет процессор.mysql -hslave.server -e 'SLAVE STOP' (на самом деле, SLAVE START не является обязательным, если вы используете MASTER_CONNECT_RETRY)kill pid клиента ssh из 2-й пули.Это должно сработать. Теперь имейте в виду, что вы должны подготовить ведомое устройство к репликации, прежде чем это сработает. Поскольку вы упомянули о выпуске SLAVE STOP, Я буду понимать, что это означает, что вы смогли получить согласованную резервную копию от главного устройства к подчиненному и получить позицию журнала для CHANGE MASTER команда. Я просто добавлю, что вам нужно указать MASTER_HOST='127.0.0.1, MASTER_PORT=3333
Очевидно, у меня нет проблем с поиском времени и подробными объяснениями. Я также стараюсь никого не оскорблять, слишком много объясняя. Если хотите подробностей, просто спросите меня.
Мне приходилось иметь дело с чем-то похожим в прошлом. У вас есть несколько вариантов.
репликация mysql с использованием ssl, сертификатов и ограничений IP. Его легко настроить, и вы можете довольно хорошо его заблокировать. Вы по-прежнему открываете соединение с сервером, но строго контролируете доступ. Может быть недостаточно для людей из службы безопасности.
Как уже упоминал кто-то другой, скопируйте файлы log-bin на ведомое устройство, а затем используйте mysqlbinlog для их приема. В конечном итоге я использовал это, чтобы переместить несколько новых приобретений в корпоративную сеть. Однако это была временная мера, и мы использовали ее только в течение месяца и запускали ее нечасто. Также у вас будет задержка относительно того, как скоро данные попадут на сервер DMZ.
Используйте прокси-сервер Mysql для одновременной записи на оба сервера Mysql. http://dev.mysql.com/downloads/mysql-proxy/index.html Это может иметь некоторые интересные побочные проблемы, если в вашей схеме есть причуды. Обратной стороной является новый инструмент для установки и изучения, а также довольно бета-версия. С другой стороны, решает большинство ваших проблем.
это некрасиво, но все же - если на мастере ничего не происходит, вы можете запускать на мастере периодически (даже раз в минуту):
так что вам не нужно полагаться на механизм репликации mysql.
вам необходимо принять во внимание тот факт, что сервер может создавать более одного файла журнала за минуту.