Eu preciso configurar uma instância de banco de dados MySQL em uma DMZ que é uma cópia somente leitura do mestre ao vivo dentro de uma rede segura.
A replicação do MySQL parece ideal para isso, exceto pelo fato de que ele funciona pelo escravo "puxando" as mudanças do mestre. Isso implica que o escravo, na DMZ, tem que ser capaz de abrir uma conexão com o mestre, o que a equipe de segurança não permitirá.
Eu joguei com a configuração de túneis ssh do mestre, mas o escravo parece manter a conexão aberta (mesmo depois de chamar "SLAVE STOP"), significando que o túnel está sempre aberto (um pouco derrotando a restrição de segurança). p>
Existe alguma maneira de forçar o mysql a abandonar a conexão, a não ser parar o mysqld?
Existe outra maneira de alcançar o mesmo objetivo que não pensei?
As atualizações do mestre para o escravo precisam estar em tempo quase real (ou seja, alguns minutos de latência é aceitável, mas não mais).
Outra ideia, uma pequena variação no que você descreveu:
A chave aqui é que o túnel é criado e destruído pelo mestre, as atualizações são executadas periodicamente.
O escravo mantém uma conexão permanente aberta ao mestre, mas fecha quando você emite um "STOP SLAVE".
Se os seus dados são muito pequenos e você pode tolerar a latência de alguns minutos, você poderia potencialmente escrever algo usando a ferramenta mk-table-sync do Maatkit que faz o trabalho. Ele irá verificar suas tabelas e descobrir o que mudou para aplicá-las. Você poderia executar isso a partir do mestre e conectar-se, periodicamente, ao escravo na DMZ, o que seria muito mais seguro do ponto de vista da segurança - mesmo que um invasor comprometesse a máquina DMZ e a substituísse por seu próprio software, eles ainda não consiga mais acesso do que um instantâneo do banco de dados.
é feio, mas ainda assim - se não houver muita coisa acontecendo no mestre, você pode executar o master periodicamente [até mesmo uma vez por minuto]:
para que você não precise depender do mecanismo de replicação do mysql.
você precisa levar em conta o fato de que pode haver mais de um arquivo de log criado pelo servidor em um minuto.
Eu tenho que lidar com algo semelhante a isso no passado. Você tem algumas opções.
Replicação do mysql usando restrições SSL, certs e IP. É fácil de configurar e você pode bloqueá-lo muito bem. Você ainda abre uma conexão com o servidor, mas controla o acesso com firmeza. Pode não ser bom o suficiente para as pessoas de segurança.
Como alguém mencionou, copie os arquivos log-bin para o escravo e use mysqlbinlog para ingeri-los. Acabei usando isso para transferir algumas novas aquisições para a rede corporativa. No entanto, esta foi uma medida temporária e só usamos por um mês e correu com pouca freqüência. Além disso, você terá latência em relação à rapidez com que os dados chegam ao servidor DMZ.
Use o Mysql Proxy para gravar nos dois servidores Mysql ao mesmo tempo. link Isso pode ter alguns problemas secundários interessantes se seu esquema tiver peculiaridades. Desvantagem, nova ferramenta para instalar e aprender, além de ser bastante beta. De cabeça para baixo, resolve a maioria dos seus problemas.
Há muitos ótimos pedaços aqui. No entanto, todo mundo está complicando demais as diferentes peças do quebra-cabeça.
mroe said:
...the slave seems to hold the connection open (even after calling "SLAVE STOP"), meaning the tunnel is always open...
1. Não é a função do mysqld slave terminar uma sessão SSH de entrada. (Isso é mais parecido com o funcionamento do tunelamento com o netcat, mas este não é o lugar para isso, então não vamos confundir o problema.) O mestre deve terminar a conexão porque [a] o originou [b] é o único dentro da rede você deseja proteger. Se você quiser encerrar a conexão para a chamada secundária " kill -s HUP $pid_of_the_sshd_owned_by_mysqlmaster ". Eu direi novamente, eu não vejo o uso.
2. Por que você chamaria " SLAVE STOP "? O escravo é um escravo. Já que estamos no assunto ... O escravo nunca deve se parar. Se o escravo for parado, o servidor mestre (veja o ponto 4. ) ou o administrador deve fazê-lo.
mroe said: Updates from master to slave need to be near-real time (i.e. a couple of minutes latency is acceptable, but not more).
Você não pode ter as duas coisas. Você quer ter o escravo IO thread em execução ou está desatualizado.
3. Não se preocupe com a 'posição do log binário do mestre' que é o que faz a replicação.
4. Se você realmente se empenha em desconectar e reconectar a cada minuto, escreva um script cron no master. Deve fazer o seguinte:
ssh -N -R 3333:127.0.0.1:3306 [email protected] &
mysql -hslave.server -e 'SLAVE START' mysql -hslave.server -e 'show slave status\G'|awk '/Seconds_Behind_Master/{print $2}' sleep para isso. Pesquise sobre o seu sistema para garantir que ele não consuma nenhuma CPU. mysql -hslave.server -e 'SLAVE STOP' (infact, o SLAVE START é opcional se você usar MASTER_CONNECT_RETRY ) kill o pid do cliente ssh da segunda bala. Isso deve ser feito. Agora lembre-se de que você precisa preparar o escravo para replicar antes que isso funcione. Como você mencionou a emissão de um SLAVE STOP , considero que foi possível obter um backup consistente do mestre para o escravo e obter a posição do log para o comando CHANGE MASTER . Vou apenas adicionar que você precisa especificar MASTER_HOST='127.0.0.1, MASTER_PORT=3333
Obviamente, não tenho problema algum em pesquisar e explicar em detalhes. Eu também estou tentando não insultar ninguém, explicando muito. Se você quiser mais detalhes, é só me perguntar.