Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi Digimer, On 2014-Apr-25 10:22, Digimer wrote: > >I'm planing to use DRBD for DR and since I've never used it, I have a > >few questions. > > > >1. Have anyone used it for replication to different data center (both > >east coast of USA)? I was thinking of using protocol A without DRBD > >proxy (maybe protocol B). How does it work in real life? > > You would want Protocol A, or else your storage performance would > effectively drop to the same speed as the network. Of course, the > trade-off is that the remote side will often be a little behind > production (or a lot behind, depending of how much data is being > written compared to the network speed). That is something I will have to live with. > >2. Since there is a lot of 2-3 MB files in size of 1GB daily that are > >not that important in case I need to switch to secondary site, would it > >be possible to put those files on separate partition (DRBD device) and > >configure it to have lower priority? Maybe only periodically > >resynchronization? I understood that it is much more efficient. > >Partition with less changing files and InnoDB tables would have high > >priority. > > Not easily. I suppose you could create a separate resource which > would use a different port and then try QoS, but that could get > tricky (in general, not DRBD specific, QoS can be a pita). In that case, I'll just use rsync and cron for those files. > >3. Would having separate NIC for replications improve performances in > >this case? > > Depends entirely on where your bottle-neck is. I suspect that will > be your WAN connection, which you didn't talk about. ;) I just thought that main problem will be latency, not bandwidth. 100Mb can't be saturated in my usecase, but that's just theory and practice can be different. > >4. Is it possible to configure DRBD to automatically demote in case of > >loosing internet connection? > > Not safely, no. There is now reliable way to use fencing, and > without reliable fencing, only a human can ensure the state of the > lost node. To try and automate it would very likely lead to > split-brains. You're talking about hardware fencing? That's possible only when servers are in the same DC. I'd like to automate demoting on primary server to avoid split-brains. Promoting secondary to primary would be done manually. Imagine this situation: DC where primary server is looses network only partially. Because of it, I'm unable to access the server (and it can't see peer either) and I think that that server is offline although that server is still visible from some other locations. I promote secondary server to primary, change DNS records and now, until DNS servers are propagated to the whole world there will be two primary servers. That's why I thought that it would be good to make primary server demote itself in cases like this.