Hozzászólások
-
SzerzőBejegyzés
-
Javaslom nézd meg a Zentyal-t. Tökélestes megoldás egy ilyen helyzetre.
Nem kell.
Nekem ez van a Server konfig-ban (Brige miatt van tap0 interface):"port 1194proto tcpdev tap0up up.shca ca.crtcert server.crtkey server.keydh dh1024.pemscript-security 2server-bridgeclient-to-clientkeepalive 10 120comp-lzopersist-keypersist-tunstatus /var/log/openvpn/openvpn-status.logverb 3"Neked a "script-security 2up up.sh"nem kell.
En altalaban a TCP keresztul hasznalom a VPN-t. Megneztem UDP esten kb ugyan azt mutatja mint neked. 🙂Latom probaltad TCP-n is
„Reply from **.**.**.**: bytes=16 rtt=3ms seq=1 tSent=0msPing statistics for **.**.**.**:Packets: Sent = 262, Received = 1, Lost = 261 ( 99.62 %loss),"Ez alapján el sem jut a csomag a serverig vagy a
Openvpn kliens es szever konfig sokat segit a problema megoldasaban.
Az első hsz-ben ez volt :”valósidejű mentést” Számomra nem arra utalt amit utolsó hsz-ben írtál: "olyamatot 5 percenként ismételgessem"Így tényleg a master-slave megoldás járható.
Mentés folyamat:- flush tables with read lock- snapshot készítés- unlock tables;- snapshot muont - mysql dump- snapshot deletHol lesz itt nem konzisztens adatbázis? ( Lehet neked van igazad .. 🙂 )
Szerintem meg nem.Csak a mostaniból kell LVM-et csinálni, persze lesz állás idő.Nem azt írtam, hogy a file szinten mentsd, hanem azt hogy csinálsz egy snapshot-ot és azon indítod el a mysql-t és onnan dump-olod ki az adatbázist.
Rakd a rendszert LVM-re es a menteskor csinalsz egy lvm snapshot-ot es arrol csinalsz mentes/dumpot.
-
SzerzőBejegyzés
legutóbbi hsz