Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
/ 2004-08-16 15:38:31 +0200 \ Joerg Paysen: > hello, > > we run drbd-0.7.2 on a kernel 2.6.7 with one "master" server M ans two > "client" server, A and B. server A ist primary and syncs to master M. > when server A stops server B should do the jobs from server A so it has > to sync its data partition from master M. it should never never never > happen that master M becomes SyncTarget on connect of server B. how can > i avoid master M from becoming a SyncTarget? > > the idea is that we have a master server (M) which has four drbd > partitions, four client server which sync data with one of the masters > drbd partitions and one spare server which is able to do the jobs of the > other servers. in case of a failure of one of the clients the spare > server should sync its data partitions with the partition of the master > server. > > thanks :) this setup is not intended, and you most likely will screw it up badly. also your "master server" is a spof now. if you really insist on doing it that way, you have to make sure that on every startup, you sync the _whole device_. you have to override drbd-internal meta data (generation counters). to do so, you can use the script write_gc.pl. you have to do the logic, scripting and testing and whatnot yourself. I strongly advice not to do so. some future version of drbd will support "spare servers" or even replication to more than one peer, as well as most cluster file systems, (i.e. concurrent access of the peers). if you want to have an influence on priority and timelines of certain features in drbd, contact office at linbit.com. Lars Ellenberg -- please use the "List-Reply" function of your email client.