1DRBDSETUP(8) System Administration DRBDSETUP(8)
2
6 drbdsetup - Configure the DRBD kernel module
7
9 drbdsetup command {argument...} [option...]
10
12 The drbdsetup utility serves to configure the DRBD kernel module and to
13 show its current configuration. Users usually interact with the drbdadm
14 utility, which provides a more high-level interface to DRBD than
15 drbdsetup. (See drbdadm's --dry-run option to see how drbdadm uses
16 drbdsetup.)
17 Some option arguments have a default scale which applies when a plain
19 number is specified (for example Kilo, or 1024 times the numeric
20 value). Such default scales can be overridden by using a suffix (for
21 example, M for Mega). The common suffixes K = 2^10 = 1024, M = 1024 K,
22 and G = 1024 M are supported.
23
25 drbdsetup attach minor lower_dev meta_data_dev meta_data_index,
26 drbdsetup disk-options minor
27 The attach command attaches a lower-level device to an existing
28 replicated device. The disk-options command changes the disk
29 options of an attached lower-level device. In either case, the
30 replicated device must have been created with drbdsetup new-minor.
31 Both commands refer to the replicated device by its minor number.
33 lower_dev is the name of the lower-level device. meta_data_dev is
34 the name of the device containing the metadata, and may be the same
35 as lower_dev. meta_data_index is either a numeric metadata index,
36 or the keyword internal for internal metadata, or the keyword
37 flexible for variable-size external metadata. Available options:
38 --al-extents extents
40 DRBD automatically maintains a "hot" or "active" disk area
41 likely to be written to again soon based on the recent write
42 activity. The "active" disk area can be written to immediately,
43 while "inactive" disk areas must be "activated" first, which
44 requires a meta-data write. We also refer to this active disk
45 area as the "activity log".
46 The activity log saves meta-data writes, but the whole log must
48 be resynced upon recovery of a failed node. The size of the
49 activity log is a major factor of how long a resync will take
50 and how fast a replicated disk will become consistent after a
51 crash.
52 The activity log consists of a number of 4-Megabyte segments;
54 the al-extents parameter determines how many of those segments
55 can be active at the same time. The default value for
56 al-extents is 1237, with a minimum of 7 and a maximum of 65536.
57 Note that the effective maximum may be smaller, depending on
59 how you created the device meta data, see also drbdmeta(8) The
60 effective maximum is 919 * (available on-disk activity-log
61 ring-buffer area/4kB -1), the default 32kB ring-buffer effects
62 a maximum of 6433 (covers more than 25 GiB of data) We
63 recommend to keep this well within the amount your backend
64 storage and replication link are able to resync inside of about
65 5 minutes.
66 --al-updates {yes | no}
68 With this parameter, the activity log can be turned off
69 entirely (see the al-extents parameter). This will speed up
70 writes because fewer meta-data writes will be necessary, but
71 the entire device needs to be resynchronized opon recovery of a
72 failed primary node. The default value for al-updates is yes.
73 --disk-barrier,
75 --disk-flushes,
76 --disk-drain
77 DRBD has three methods of handling the ordering of dependent
78 write requests:
79 disk-barrier
81 Use disk barriers to make sure that requests are written to
82 disk in the right order. Barriers ensure that all requests
83 submitted before a barrier make it to the disk before any
84 requests submitted after the barrier. This is implemented
85 using 'tagged command queuing' on SCSI devices and 'native
86 command queuing' on SATA devices. Only some devices and
87 device stacks support this method. The device mapper (LVM)
88 only supports barriers in some configurations.
89 Note that on systems which do not support disk barriers,
91 enabling this option can lead to data loss or corruption.
92 Until DRBD 8.4.1, disk-barrier was turned on if the I/O
93 stack below DRBD did support barriers. Kernels since
94 linux-2.6.36 (or 2.6.32 RHEL6) no longer allow to detect if
95 barriers are supported. Since drbd-8.4.2, this option is
96 off by default and needs to be enabled explicitly.
97 disk-flushes
99 Use disk flushes between dependent write requests, also
100 referred to as 'force unit access' by drive vendors. This
101 forces all data to disk. This option is enabled by default.
102 disk-drain
104 Wait for the request queue to "drain" (that is, wait for
105 the requests to finish) before submitting a dependent write
106 request. This method requires that requests are stable on
107 disk when they finish. Before DRBD 8.0.9, this was the only
108 method implemented. This option is enabled by default. Do
109 not disable in production environments.
110 From these three methods, drbd will use the first that is
112 enabled and supported by the backing storage device. If all
113 three of these options are turned off, DRBD will submit write
114 requests without bothering about dependencies. Depending on the
115 I/O stack, write requests can be reordered, and they can be
116 submitted in a different order on different cluster nodes. This
117 can result in data loss or corruption. Therefore, turning off
118 all three methods of controlling write ordering is strongly
119 discouraged.
120 A general guideline for configuring write ordering is to use
122 disk barriers or disk flushes when using ordinary disks (or an
123 ordinary disk array) with a volatile write cache. On storage
124 without cache or with a battery backed write cache, disk
125 draining can be a reasonable choice.
126 --disk-timeout
128 If the lower-level device on which a DRBD device stores its
129 data does not finish an I/O request within the defined
130 disk-timeout, DRBD treats this as a failure. The lower-level
131 device is detached, and the device's disk state advances to
132 Diskless. If DRBD is connected to one or more peers, the failed
133 request is passed on to one of them.
134 This option is dangerous and may lead to kernel panic!
136 "Aborting" requests, or force-detaching the disk, is intended
138 for completely blocked/hung local backing devices which do no
139 longer complete requests at all, not even do error completions.
140 In this situation, usually a hard-reset and failover is the
141 only way out.
142 By "aborting", basically faking a local error-completion, we
144 allow for a more graceful swichover by cleanly migrating
145 services. Still the affected node has to be rebooted "soon".
146 By completing these requests, we allow the upper layers to
148 re-use the associated data pages.
149 If later the local backing device "recovers", and now DMAs some
151 data from disk into the original request pages, in the best
152 case it will just put random data into unused pages; but
153 typically it will corrupt meanwhile completely unrelated data,
154 causing all sorts of damage.
155 Which means delayed successful completion, especially for READ
157 requests, is a reason to panic(). We assume that a delayed
158 *error* completion is OK, though we still will complain noisily
159 about it.
160 The default value of disk-timeout is 0, which stands for an
162 infinite timeout. Timeouts are specified in units of 0.1
163 seconds. This option is available since DRBD 8.3.12.
164 --md-flushes
166 Enable disk flushes and disk barriers on the meta-data device.
167 This option is enabled by default. See the disk-flushes
168 parameter.
169 --on-io-error handler
171 Configure how DRBD reacts to I/O errors on a lower-level
172 device. The following policies are defined:
173 pass_on
175 Change the disk status to Inconsistent, mark the failed
176 block as inconsistent in the bitmap, and retry the I/O
177 operation on a remote cluster node.
178 call-local-io-error
180 Call the local-io-error handler (see the handlers section).
181 detach
183 Detach the lower-level device and continue in diskless
184 mode.
185 --read-balancing policy
188 Distribute read requests among cluster nodes as defined by
189 policy. The supported policies are prefer-local (the default),
190 prefer-remote, round-robin, least-pending,
191 when-congested-remote, 32K-striping, 64K-striping,
192 128K-striping, 256K-striping, 512K-striping and 1M-striping.
193 This option is available since DRBD 8.4.1.
195 resync-after minor
197 Define that a device should only resynchronize after the
198 specified other device. By default, no order between devices is
199 defined, and all devices will resynchronize in parallel.
200 Depending on the configuration of the lower-level devices, and
201 the available network and disk bandwidth, this can slow down
202 the overall resync process. This option can be used to form a
203 chain or tree of dependencies among devices.
204 --size size
206 Specify the size of the lower-level device explicitly instead
207 of determining it automatically. The device size must be
208 determined once and is remembered for the lifetime of the
209 device. In order to determine it automatically, all the
210 lower-level devices on all nodes must be attached, and all
211 nodes must be connected. If the size is specified explicitly,
212 this is not necessary. The size value is assumed to be in units
213 of sectors (512 bytes) by default.
214 --discard-zeroes-if-aligned {yes | no}
216 There are several aspects to discard/trim/unmap support on
217 linux block devices. Even if discard is supported in general,
218 it may fail silently, or may partially ignore discard requests.
219 Devices also announce whether reading from unmapped blocks
220 returns defined data (usually zeroes), or undefined data
221 (possibly old data, possibly garbage).
222 If on different nodes, DRBD is backed by devices with differing
224 discard characteristics, discards may lead to data divergence
225 (old data or garbage left over on one backend, zeroes due to
226 unmapped areas on the other backend). Online verify would now
227 potentially report tons of spurious differences. While probably
228 harmless for most use cases (fstrim on a file system), DRBD
229 cannot have that.
230 To play safe, we have to disable discard support, if our local
232 backend (on a Primary) does not support
233 "discard_zeroes_data=true". We also have to translate discards
234 to explicit zero-out on the receiving side, unless the
235 receiving side (Secondary) supports "discard_zeroes_data=true",
236 thereby allocating areas what were supposed to be unmapped.
237 There are some devices (notably the LVM/DM thin provisioning)
239 that are capable of discard, but announce
240 discard_zeroes_data=false. In the case of DM-thin, discards
241 aligned to the chunk size will be unmapped, and reading from
242 unmapped sectors will return zeroes. However, unaligned partial
243 head or tail areas of discard requests will be silently
244 ignored.
245 If we now add a helper to explicitly zero-out these unaligned
247 partial areas, while passing on the discard of the aligned full
248 chunks, we effectively achieve discard_zeroes_data=true on such
249 devices.
250 Setting discard-zeroes-if-aligned to yes will allow DRBD to use
252 discards, and to announce discard_zeroes_data=true, even on
253 backends that announce discard_zeroes_data=false.
254 Setting discard-zeroes-if-aligned to no will cause DRBD to
256 always fall-back to zero-out on the receiving side, and to not
257 even announce discard capabilities on the Primary, if the
258 respective backend announces discard_zeroes_data=false.
259 We used to ignore the discard_zeroes_data setting completely.
261 To not break established and expected behaviour, and suddenly
262 cause fstrim on thin-provisioned LVs to run out-of-space
263 instead of freeing up space, the default value is yes.
264 This option is available since 8.4.7.
266 --rs-discard-granularity byte
268 When rs-discard-granularity is set to a non zero, positive
269 value then DRBD tries to do a resync operation in requests of
270 this size. In case such a block contains only zero bytes on the
271 sync source node, the sync target node will issue a
272 discard/trim/unmap command for the area.
273 The value is constrained by the discard granularity of the
275 backing block device. In case rs-discard-granularity is not a
276 multiplier of the discard granularity of the backing block
277 device DRBD rounds it up. The feature only gets active if the
278 backing block device reads back zeroes after a discard command.
279 The default value of is 0. This option is available since
281 8.4.7.
282 drbdsetup peer-device-options resource peer_node_id volume
284 These are options that affect the peer's device.
285 --c-delay-target delay_target,
287 --c-fill-target fill_target,
288 --c-max-rate max_rate,
289 --c-plan-ahead plan_time
290 Dynamically control the resync speed. This mechanism is enabled
291 by setting the c-plan-ahead parameter to a positive value. The
292 goal is to either fill the buffers along the data path with a
293 defined amount of data if c-fill-target is defined, or to have
294 a defined delay along the path if c-delay-target is defined.
295 The maximum bandwidth is limited by the c-max-rate parameter.
296 The c-plan-ahead parameter defines how fast drbd adapts to
298 changes in the resync speed. It should be set to five times the
299 network round-trip time or more. Common values for
300 c-fill-target for "normal" data paths range from 4K to 100K. If
301 drbd-proxy is used, it is advised to use c-delay-target instead
302 of c-fill-target. The c-delay-target parameter is used if the
303 c-fill-target parameter is undefined or set to 0. The
304 c-delay-target parameter should be set to five times the
305 network round-trip time or more. The c-max-rate option should
306 be set to either the bandwidth available between the DRBD-hosts
307 and the machines hosting DRBD-proxy, or to the available disk
308 bandwidth.
309 The default values of these parameters are: c-plan-ahead = 20
311 (in units of 0.1 seconds), c-fill-target = 0 (in units of
312 sectors), c-delay-target = 1 (in units of 0.1 seconds), and
313 c-max-rate = 102400 (in units of KiB/s).
314 Dynamic resync speed control is available since DRBD 8.3.9.
316 --c-min-rate min_rate
318 A node which is primary and sync-source has to schedule
319 application I/O requests and resync I/O requests. The
320 c-min-rate parameter limits how much bandwidth is available for
321 resync I/O; the remaining bandwidth is used for application
322 I/O.
323 A c-min-rate value of 0 means that there is no limit on the
325 resync I/O bandwidth. This can slow down application I/O
326 significantly. Use a value of 1 (1 KiB/s) for the lowest
327 possible resync rate.
328 The default value of c-min-rate is 4096, in units of KiB/s.
330 --resync-rate rate
332 Define how much bandwidth DRBD may use for resynchronizing.
333 DRBD allows "normal" application I/O even during a resync. If
334 the resync takes up too much bandwidth, application I/O can
335 become very slow. This parameter allows to avoid that. Please
336 note this is option only works when the dynamic resync
337 controller is disabled.
338 drbdsetup check-resize minor
340 Remember the current size of the lower-level device of the
341 specified replicated device. Used by drbdadm. The size information
342 is stored in file /var/lib/drbd/drbd-minor-minor.lkbd.
343 drbdsetup new-peer resource peer_node_id,
345 drbdsetup net-options resource peer_node_id
346 The new-peer command creates a connection within a resource. The
347 resource must have been created with drbdsetup new-resource. The
348 net-options command changes the network options of an existing
349 connection. Before a connection can be activated with the connect
350 command, at least one path need to added with the new-path command.
351 Available options:
352 --after-sb-0pri policy
354 Define how to react if a split-brain scenario is detected and
355 none of the two nodes is in primary role. (We detect
356 split-brain scenarios when two nodes connect; split-brain
357 decisions are always between two nodes.) The defined policies
358 are:
359 disconnect
361 No automatic resynchronization; simply disconnect.
362 discard-younger-primary,
364 discard-older-primary
365 Resynchronize from the node which became primary first
366 (discard-younger-primary) or last (discard-older-primary).
367 If both nodes became primary independently, the
368 discard-least-changes policy is used.
369 discard-zero-changes
371 If only one of the nodes wrote data since the split brain
372 situation was detected, resynchronize from this node to the
373 other. If both nodes wrote data, disconnect.
374 discard-least-changes
376 Resynchronize from the node with more modified blocks.
377 discard-node-nodename
379 Always resynchronize to the named node.
380 --after-sb-1pri policy
382 Define how to react if a split-brain scenario is detected, with
383 one node in primary role and one node in secondary role. (We
384 detect split-brain scenarios when two nodes connect, so
385 split-brain decisions are always among two nodes.) The defined
386 policies are:
387 disconnect
389 No automatic resynchronization, simply disconnect.
390 consensus
392 Discard the data on the secondary node if the after-sb-0pri
393 algorithm would also discard the data on the secondary
394 node. Otherwise, disconnect.
395 violently-as0p
397 Always take the decision of the after-sb-0pri algorithm,
398 even if it causes an erratic change of the primary's view
399 of the data. This is only useful if a single-node file
400 system (i.e., not OCFS2 or GFS) with the
401 allow-two-primaries flag is used. This option can cause the
402 primary node to crash, and should not be used.
403 discard-secondary
405 Discard the data on the secondary node.
406 call-pri-lost-after-sb
408 Always take the decision of the after-sb-0pri algorithm. If
409 the decision is to discard the data on the primary node,
410 call the pri-lost-after-sb handler on the primary node.
411 --after-sb-2pri policy
413 Define how to react if a split-brain scenario is detected and
414 both nodes are in primary role. (We detect split-brain
415 scenarios when two nodes connect, so split-brain decisions are
416 always among two nodes.) The defined policies are:
417 disconnect
419 No automatic resynchronization, simply disconnect.
420 violently-as0p
422 See the violently-as0p policy for after-sb-1pri.
423 call-pri-lost-after-sb
425 Call the pri-lost-after-sb helper program on one of the
426 machines unless that machine can demote to secondary. The
427 helper program is expected to reboot the machine, which
428 brings the node into a secondary role. Which machine runs
429 the helper program is determined by the after-sb-0pri
430 strategy.
431 --allow-two-primaries
433 The most common way to configure DRBD devices is to allow only
434 one node to be primary (and thus writable) at a time.
435 In some scenarios it is preferable to allow two nodes to be
437 primary at once; a mechanism outside of DRBD then must make
438 sure that writes to the shared, replicated device happen in a
439 coordinated way. This can be done with a shared-storage cluster
440 file system like OCFS2 and GFS, or with virtual machine images
441 and a virtual machine manager that can migrate virtual machines
442 between physical machines.
443 The allow-two-primaries parameter tells DRBD to allow two nodes
445 to be primary at the same time. Never enable this option when
446 using a non-distributed file system; otherwise, data corruption
447 and node crashes will result!
448 --always-asbp
450 Normally the automatic after-split-brain policies are only used
451 if current states of the UUIDs do not indicate the presence of
452 a third node.
453 With this option you request that the automatic
455 after-split-brain policies are used as long as the data sets of
456 the nodes are somehow related. This might cause a full sync, if
457 the UUIDs indicate the presence of a third node. (Or double
458 faults led to strange UUID sets.)
459 --connect-int time
461 As soon as a connection between two nodes is configured with
462 drbdsetup connect, DRBD immediately tries to establish the
463 connection. If this fails, DRBD waits for connect-int seconds
464 and then repeats. The default value of connect-int is 10
465 seconds.
466 --cram-hmac-alg hash-algorithm
468 Configure the hash-based message authentication code (HMAC) or
469 secure hash algorithm to use for peer authentication. The
470 kernel supports a number of different algorithms, some of which
471 may be loadable as kernel modules. See the shash algorithms
472 listed in /proc/crypto. By default, cram-hmac-alg is unset.
473 Peer authentication also requires a shared-secret to be
474 configured.
475 --csums-alg hash-algorithm
477 Normally, when two nodes resynchronize, the sync target
478 requests a piece of out-of-sync data from the sync source, and
479 the sync source sends the data. With many usage patterns, a
480 significant number of those blocks will actually be identical.
481 When a csums-alg algorithm is specified, when requesting a
483 piece of out-of-sync data, the sync target also sends along a
484 hash of the data it currently has. The sync source compares
485 this hash with its own version of the data. It sends the sync
486 target the new data if the hashes differ, and tells it that the
487 data are the same otherwise. This reduces the network bandwidth
488 required, at the cost of higher cpu utilization and possibly
489 increased I/O on the sync target.
490 The csums-alg can be set to one of the secure hash algorithms
492 supported by the kernel; see the shash algorithms listed in
493 /proc/crypto. By default, csums-alg is unset.
494 --csums-after-crash-only
496 Enabling this option (and csums-alg, above) makes it possible
497 to use the checksum based resync only for the first resync
498 after primary crash, but not for later "network hickups".
499 In most cases, block that are marked as need-to-be-resynced are
501 in fact changed, so calculating checksums, and both reading and
502 writing the blocks on the resync target is all effective
503 overhead.
504 The advantage of checksum based resync is mostly after primary
506 crash recovery, where the recovery marked larger areas (those
507 covered by the activity log) as need-to-be-resynced, just in
508 case. Introduced in 8.4.5.
509 --data-integrity-alg alg
511 DRBD normally relies on the data integrity checks built into
512 the TCP/IP protocol, but if a data integrity algorithm is
513 configured, it will additionally use this algorithm to make
514 sure that the data received over the network match what the
515 sender has sent. If a data integrity error is detected, DRBD
516 will close the network connection and reconnect, which will
517 trigger a resync.
518 The data-integrity-alg can be set to one of the secure hash
520 algorithms supported by the kernel; see the shash algorithms
521 listed in /proc/crypto. By default, this mechanism is turned
522 off.
523 Because of the CPU overhead involved, we recommend not to use
525 this option in production environments. Also see the notes on
526 data integrity below.
527 --fencing fencing_policy
529 Fencing is a preventive measure to avoid situations where both
530 nodes are primary and disconnected. This is also known as a
531 split-brain situation. DRBD supports the following fencing
532 policies:
533 dont-care
535 No fencing actions are taken. This is the default policy.
536 resource-only
538 If a node becomes a disconnected primary, it tries to fence
539 the peer. This is done by calling the fence-peer handler.
540 The handler is supposed to reach the peer over an
541 alternative communication path and call 'drbdadm outdate
542 minor' there.
543 resource-and-stonith
545 If a node becomes a disconnected primary, it freezes all
546 its IO operations and calls its fence-peer handler. The
547 fence-peer handler is supposed to reach the peer over an
548 alternative communication path and call 'drbdadm outdate
549 minor' there. In case it cannot do that, it should stonith
550 the peer. IO is resumed as soon as the situation is
551 resolved. In case the fence-peer handler fails, I/O can be
552 resumed manually with 'drbdadm resume-io'.
553 --ko-count number
555 If a secondary node fails to complete a write request in
556 ko-count times the timeout parameter, it is excluded from the
557 cluster. The primary node then sets the connection to this
558 secondary node to Standalone. To disable this feature, you
559 should explicitly set it to 0; defaults may change between
560 versions.
561 --max-buffers number
563 Limits the memory usage per DRBD minor device on the receiving
564 side, or for internal buffers during resync or online-verify.
565 Unit is PAGE_SIZE, which is 4 KiB on most systems. The minimum
566 possible setting is hard coded to 32 (=128 KiB). These buffers
567 are used to hold data blocks while they are written to/read
568 from disk. To avoid possible distributed deadlocks on
569 congestion, this setting is used as a throttle threshold rather
570 than a hard limit. Once more than max-buffers pages are in use,
571 further allocation from this pool is throttled. You want to
572 increase max-buffers if you cannot saturate the IO backend on
573 the receiving side.
574 --max-epoch-size number
576 Define the maximum number of write requests DRBD may issue
577 before issuing a write barrier. The default value is 2048, with
578 a minimum of 1 and a maximum of 20000. Setting this parameter
579 to a value below 10 is likely to decrease performance.
580 --on-congestion policy,
582 --congestion-fill threshold,
583 --congestion-extents threshold
584 By default, DRBD blocks when the TCP send queue is full. This
585 prevents applications from generating further write requests
586 until more buffer space becomes available again.
587 When DRBD is used together with DRBD-proxy, it can be better to
589 use the pull-ahead on-congestion policy, which can switch DRBD
590 into ahead/behind mode before the send queue is full. DRBD then
591 records the differences between itself and the peer in its
592 bitmap, but it no longer replicates them to the peer. When
593 enough buffer space becomes available again, the node
594 resynchronizes with the peer and switches back to normal
595 replication.
596 This has the advantage of not blocking application I/O even
598 when the queues fill up, and the disadvantage that peer nodes
599 can fall behind much further. Also, while resynchronizing, peer
600 nodes will become inconsistent.
601 The available congestion policies are block (the default) and
603 pull-ahead. The congestion-fill parameter defines how much data
604 is allowed to be "in flight" in this connection. The default
605 value is 0, which disables this mechanism of congestion
606 control, with a maximum of 10 GiBytes. The congestion-extents
607 parameter defines how many bitmap extents may be active before
608 switching into ahead/behind mode, with the same default and
609 limits as the al-extents parameter. The congestion-extents
610 parameter is effective only when set to a value smaller than
611 al-extents.
612 Ahead/behind mode is available since DRBD 8.3.10.
614 --ping-int interval
616 When the TCP/IP connection to a peer is idle for more than
617 ping-int seconds, DRBD will send a keep-alive packet to make
618 sure that a failed peer or network connection is detected
619 reasonably soon. The default value is 10 seconds, with a
620 minimum of 1 and a maximum of 120 seconds. The unit is seconds.
621 --ping-timeout timeout
623 Define the timeout for replies to keep-alive packets. If the
624 peer does not reply within ping-timeout, DRBD will close and
625 try to reestablish the connection. The default value is 0.5
626 seconds, with a minimum of 0.1 seconds and a maximum of 3
627 seconds. The unit is tenths of a second.
628 --socket-check-timeout timeout
630 In setups involving a DRBD-proxy and connections that
631 experience a lot of buffer-bloat it might be necessary to set
632 ping-timeout to an unusual high value. By default DRBD uses the
633 same value to wait if a newly established TCP-connection is
634 stable. Since the DRBD-proxy is usually located in the same
635 data center such a long wait time may hinder DRBD's connect
636 process.
637 In such setups socket-check-timeout should be set to at least
639 to the round trip time between DRBD and DRBD-proxy. I.e. in
640 most cases to 1.
641 The default unit is tenths of a second, the default value is 0
643 (which causes DRBD to use the value of ping-timeout instead).
644 Introduced in 8.4.5.
645 --protocol name
647 Use the specified protocol on this connection. The supported
648 protocols are:
649 A
651 Writes to the DRBD device complete as soon as they have
652 reached the local disk and the TCP/IP send buffer.
653 B
655 Writes to the DRBD device complete as soon as they have
656 reached the local disk, and all peers have acknowledged the
657 receipt of the write requests.
658 C
660 Writes to the DRBD device complete as soon as they have
661 reached the local and all remote disks.
662 --rcvbuf-size size
665 Configure the size of the TCP/IP receive buffer. A value of 0
666 (the default) causes the buffer size to adjust dynamically.
667 This parameter usually does not need to be set, but it can be
668 set to a value up to 10 MiB. The default unit is bytes.
669 --rr-conflict policy
671 This option helps to solve the cases when the outcome of the
672 resync decision is incompatible with the current role
673 assignment in the cluster. The defined policies are:
674 disconnect
676 No automatic resynchronization, simply disconnect.
677 violently
679 Resync to the primary node is allowed, violating the
680 assumption that data on a block device are stable for one
681 of the nodes. Do not use this option, it is dangerous.
682 call-pri-lost
684 Call the pri-lost handler on one of the machines. The
685 handler is expected to reboot the machine, which puts it
686 into secondary role.
687 --shared-secret secret
689 Configure the shared secret used for peer authentication. The
690 secret is a string of up to 64 characters. Peer authentication
691 also requires the cram-hmac-alg parameter to be set.
692 --sndbuf-size size
694 Configure the size of the TCP/IP send buffer. Since DRBD 8.0.13
695 / 8.2.7, a value of 0 (the default) causes the buffer size to
696 adjust dynamically. Values below 32 KiB are harmful to the
697 throughput on this connection. Large buffer sizes can be useful
698 especially when protocol A is used over high-latency networks;
699 the maximum value supported is 10 MiB.
700 --tcp-cork
702 By default, DRBD uses the TCP_CORK socket option to prevent the
703 kernel from sending partial messages; this results in fewer and
704 bigger packets on the network. Some network stacks can perform
705 worse with this optimization. On these, the tcp-cork parameter
706 can be used to turn this optimization off.
707 --timeout time
709 Define the timeout for replies over the network: if a peer node
710 does not send an expected reply within the specified timeout,
711 it is considered dead and the TCP/IP connection is closed. The
712 timeout value must be lower than connect-int and lower than
713 ping-int. The default is 6 seconds; the value is specified in
714 tenths of a second.
715 --use-rle
717 Each replicated device on a cluster node has a separate bitmap
718 for each of its peer devices. The bitmaps are used for tracking
719 the differences between the local and peer device: depending on
720 the cluster state, a disk range can be marked as different from
721 the peer in the device's bitmap, in the peer device's bitmap,
722 or in both bitmaps. When two cluster nodes connect, they
723 exchange each other's bitmaps, and they each compute the union
724 of the local and peer bitmap to determine the overall
725 differences.
726 Bitmaps of very large devices are also relatively large, but
728 they usually compress very well using run-length encoding. This
729 can save time and bandwidth for the bitmap transfers.
730 The use-rle parameter determines if run-length encoding should
732 be used. It is on by default since DRBD 8.4.0.
733 --verify-alg hash-algorithm
735 Online verification (drbdadm verify) computes and compares
736 checksums of disk blocks (i.e., hash values) in order to detect
737 if they differ. The verify-alg parameter determines which
738 algorithm to use for these checksums. It must be set to one of
739 the secure hash algorithms supported by the kernel before
740 online verify can be used; see the shash algorithms listed in
741 /proc/crypto.
742 We recommend to schedule online verifications regularly during
744 low-load periods, for example once a month. Also see the notes
745 on data integrity below.
746 drbdsetup new-path resource peer_node_id local-addr remote-addr
748 The new-path command creates a path within a connection. The
749 connection must have been created with drbdsetup new-peer.
750 Local_addr and remote_addr refer to the local and remote protocol,
751 network address, and port in the format
752 [address-family:]address[:port]. The address families ipv4, ipv6,
753 ssocks (Dolphin Interconnect Solutions' "super sockets"), sdp
754 (Infiniband Sockets Direct Protocol), and sci are supported (sci is
755 an alias for ssocks). If no address family is specified, ipv4 is
756 assumed. For all address families except ipv6, the address uses
757 IPv4 address notation (for example, 1.2.3.4). For ipv6, the address
758 is enclosed in brackets and uses IPv6 address notation (for
759 example, [fd01:2345:6789:abcd::1]). The port defaults to 7788.
760 drbdsetup connect resource peer_node_id
762 The connect command activates a connection. That means that the
763 DRBD driver will bind and listen on all local addresses of the
764 connection-'s paths. It will begin to try to establish one or more
765 paths of the connection. Available options:
766 --tentative
768 Only determine if a connection to the peer can be established
769 and if a resync is necessary (and in which direction) without
770 actually establishing the connection or starting the resync.
771 Check the system log to see what DRBD would do without the
772 --tentative option.
773 --discard-my-data
775 Discard the local data and resynchronize with the peer that has
776 the most up-to-data data. Use this option to manually recover
777 from a split-brain situation.
778 drbdsetup del-peer resource peer_node_id
780 The del-peer command removes a connection from a resource.
781 drbdsetup del-path resource peer_node_id local-addr remote-addr
783 The del-path command removes a path from a connection. Please note
784 that it fails if the path is necessary to keep a connected
785 connection in tact. In order to remove all paths, disconnect the
786 connection first.
787 drbdsetup cstate resource peer_node_id
789 Show the current state of a connection. The connection is
790 identified by the node-id of the peer; see the drbdsetup connect
791 command.
792 drbdsetup del-minor minor
794 Remove a replicated device. No lower-level device may be attached;
795 see drbdsetup detach.
796 drbdsetup del-resource resource
798 Remove a resource. All volumes and connections must be removed
799 first (drbdsetup del-minor, drbdsetup disconnect). Alternatively,
800 drbdsetup down can be used to remove a resource together with all
801 its volumes and connections.
802 drbdsetup detach minor
804 Detach the lower-level device of a replicated device. Available
805 options:
806 --force
808 Force the detach and return immediately. This puts the
809 lower-level device into failed state until all pending I/O has
810 completed, and then detaches the device. Any I/O not yet
811 submitted to the lower-level device (for example, because I/O
812 on the device was suspended) is assumed to have failed.
813 drbdsetup disconnect resource peer_node_id
816 Remove a connection to a peer host. The connection is identified by
817 the node-id of the peer; see the drbdsetup connect command.
818 drbdsetup down {resource | all}
820 Take a resource down by removing all volumes, connections, and the
821 resource itself.
822 drbdsetup dstate minor
824 Show the current disk state of a lower-level device.
825 drbdsetup events2 {resource | all}
827 Show the current state of all configured DRBD objects, followed by
828 all changes to the state.
829 The output format is meant to be human as well as machine readable.
831 The line starts with a word that indicates the kind of event:
832 exists for an existing object; create, destroy, and change if an
833 object is created, destroyed, or changed; or call or response if an
834 event handler is called or it returns. The second word indicates
835 the object the event applies to: resource, device, connection,
836 peer-device, helper, or a dash (-) to indicate that the current
837 state has been dumped completely.
838 The remaining words identify the object and describe the state that
840 he object is in. Available options:
841 --now
843 Terminate after reporting the current state. The default is to
844 continuously listen and report state changes.
845 --statistics
847 Include statistics in the output.
848 drbdsetup get-gi resource peer_node_id volume
851 Show the data generation identifiers for a device on a particular
852 connection. The device is identified by its volume number. The
853 connection is identified by its endpoints; see the drbdsetup
854 connect command.
855 The output consists of the current UUID, bitmap UUID, and the first
857 two history UUIDS, folowed by a set of flags. The current UUID and
858 history UUIDs are device specific; the bitmap UUID and flags are
859 peer device specific. This command only shows the first two history
860 UUIDs. Internally, DRBD maintains one history UUID for each
861 possible peer device.
862 drbdsetup invalidate minor
864 Replace the local data of a device with that of a peer. All the
865 local data will be marked out-of-sync, and a resync with the
866 specified peer device will be initialted.
867 drbdsetup invalidate-remote resource peer_node_id volume
869 Replace a peer device's data of a resource with the local data. The
870 peer device's data will be marked out-of-sync, and a resync from
871 the local node to the specified peer will be initiated.
872 drbdsetup new-current-uuid minor
874 Generate a new current UUID and rotates all other UUID values. This
875 has at least two use cases, namely to skip the initial sync, and to
876 reduce network bandwidth when starting in a single node
877 configuration and then later (re-)integrating a remote site.
878 Available option:
880 --clear-bitmap
882 Clears the sync bitmap in addition to generating a new current
883 UUID.
884 This can be used to skip the initial sync, if you want to start
886 from scratch. This use-case does only work on "Just Created" meta
887 data. Necessary steps:
888 1. On both nodes, initialize meta data and configure the device.
890 drbdadm create-md --force res
892 2. They need to do the initial handshake, so they know their
894 sizes.
895 drbdadm up res
897 3. They are now Connected Secondary/Secondary
899 Inconsistent/Inconsistent. Generate a new current-uuid and
900 clear the dirty bitmap.
901 drbdadm --clear-bitmap new-current-uuid res
903 4. They are now Connected Secondary/Secondary UpToDate/UpToDate.
905 Make one side primary and create a file system.
906 drbdadm primary res
908 mkfs -t fs-type $(drbdadm sh-dev res)
910 One obvious side-effect is that the replica is full of old garbage
912 (unless you made them identical using other means), so any
913 online-verify is expected to find any number of out-of-sync blocks.
914 You must not use this on pre-existing data! Even though it may
916 appear to work at first glance, once you switch to the other node,
917 your data is toast, as it never got replicated. So do not leave out
918 the mkfs (or equivalent).
919 This can also be used to shorten the initial resync of a cluster
921 where the second node is added after the first node is gone into
922 production, by means of disk shipping. This use-case works on
923 disconnected devices only, the device may be in primary or
924 secondary role.
925 The necessary steps on the current active server are:
927 1. drbdsetup new-current-uuid --clear-bitmap minor
929 2. Take the copy of the current active server. E.g. by pulling a
931 disk out of the RAID1 controller, or by copying with dd. You
932 need to copy the actual data, and the meta data.
933 3. drbdsetup new-current-uuid minor
935 Now add the disk to the new secondary node, and join it to the
937 cluster. You will get a resync of that parts that were changed
938 since the first call to drbdsetup in step 1.
939 drbdsetup new-minor resource minor volume
941 Create a new replicated device within a resource. The command
942 creates a block device inode for the replicated device (by default,
943 /dev/drbdminor). The volume number identifies the device within the
944 resource.
945 drbdsetup new-resource resource node_id,
947 drbdsetup resource-options resource
948 The new-resource command creates a new resource. The
949 resource-options command changes the resource options of an
950 existing resource. Available options:
951 --auto-promote bool-value
953 A resource must be promoted to primary role before any of its
954 devices can be mounted or opened for writing.
955 Before DRBD 9, this could only be done explicitly ("drbdadm
957 primary"). Since DRBD 9, the auto-promote parameter allows to
958 automatically promote a resource to primary role when one of
959 its devices is mounted or opened for writing. As soon as all
960 devices are unmounted or closed with no more remaining users,
961 the role of the resource changes back to secondary.
962 Automatic promotion only succeeds if the cluster state allows
964 it (that is, if an explicit drbdadm primary command would
965 succeed). Otherwise, mounting or opening the device fails as it
966 already did before DRBD 9: the mount(2) system call fails with
967 errno set to EROFS (Read-only file system); the open(2) system
968 call fails with errno set to EMEDIUMTYPE (wrong medium type).
969 Irrespective of the auto-promote parameter, if a device is
971 promoted explicitly (drbdadm primary), it also needs to be
972 demoted explicitly (drbdadm secondary).
973 The auto-promote parameter is available since DRBD 9.0.0, and
975 defaults to yes.
976 --cpu-mask cpu-mask
978 Set the cpu affinity mask for DRBD kernel threads. The cpu mask
979 is specified as a hexadecimal number. The default value is 0,
980 which lets the scheduler decide which kernel threads run on
981 which CPUs. CPU numbers in cpu-mask which do not exist in the
982 system are ignored.
983 --on-no-data-accessible policy
985 Determine how to deal with I/O requests when the requested data
986 is not available locally or remotely (for example, when all
987 disks have failed). The defined policies are:
988 io-error
990 System calls fail with errno set to EIO.
991 suspend-io
993 The resource suspends I/O. I/O can be resumed by
994 (re)attaching the lower-level device, by connecting to a
995 peer which has access to the data, or by forcing DRBD to
996 resume I/O with drbdadm resume-io res. When no data is
997 available, forcing I/O to resume will result in the same
998 behavior as the io-error policy.
999 This setting is available since DRBD 8.3.9; the default policy
1001 is io-error.
1002 --peer-ack-window value
1004 On each node and for each device, DRBD maintains a bitmap of
1005 the differences between the local and remote data for each peer
1006 device. For example, in a three-node setup (nodes A, B, C) each
1007 with a single device, every node maintains one bitmap for each
1008 of its peers.
1009 When nodes receive write requests, they know how to update the
1011 bitmaps for the writing node, but not how to update the bitmaps
1012 between themselves. In this example, when a write request
1013 propagates from node A to B and C, nodes B and C know that they
1014 have the same data as node A, but not whether or not they both
1015 have the same data.
1016 As a remedy, the writing node occasionally sends peer-ack
1018 packets to its peers which tell them which state they are in
1019 relative to each other.
1020 The peer-ack-window parameter specifies how much data a primary
1022 node may send before sending a peer-ack packet. A low value
1023 causes increased network traffic; a high value causes less
1024 network traffic but higher memory consumption on secondary
1025 nodes and higher resync times between the secondary nodes after
1026 primary node failures. (Note: peer-ack packets may be sent due
1027 to other reasons as well, e.g. membership changes or expiry of
1028 the peer-ack-delay timer.)
1029 The default value for peer-ack-window is 2 MiB, the default
1031 unit is sectors. This option is available since 9.0.0.
1032 --peer-ack-delay expiry-time
1034 If after the last finished write request no new write request
1035 gets issued for expiry-time, then a peer-ack packet is sent. If
1036 a new write request is issued before the timer expires, the
1037 timer gets reset to expiry-time. (Note: peer-ack packets may be
1038 sent due to other reasons as well, e.g. membership changes or
1039 the peer-ack-window option.)
1040 This parameter may influence resync behavior on remote nodes.
1042 Peer nodes need to wait until they receive an peer-ack for
1043 releasing a lock on an AL-extent. Resync operations between
1044 peers may need to wait for for these locks.
1045 The default value for peer-ack-delay is 100 milliseconds, the
1047 default unit is milliseconds. This option is available since
1048 9.0.0.
1049 --quorum value
1051 When activated, a cluster partition requires quorum in order to
1052 modify the replicated data set. That means a node in the
1053 cluster partition can only be promoted to primary if the
1054 cluster partition has quorum. Every node with a disk directly
1055 connected to the node that should be promoted counts. If a
1056 primary node should execute a write request, but the cluster
1057 partition has lost quorum, it will freeze IO or reject the
1058 write request with an error (depending on the on-no-quorum
1059 setting). Upon loosing quorum a primary always invokes the
1060 quorum-lost handler. The handler is intended for notification
1061 purposes, its return code is ignored.
1062 The option's value might be set to off, majority, all or a
1064 numeric value. If you set it to a numeric value, make sure that
1065 the value is greater than half of your number of nodes. Quorum
1066 is a mechanism to avoid data divergence, it might be used
1067 instead of fencing when there are more than two repicas. It
1068 defaults to off
1069 If all missing nodes are marked as outdated, a partition always
1071 has quorum, no matter how small it is. I.e. If you disconnect
1072 all secondary nodes gracefully a single primary continues to
1073 operate. In the moment a single secondary is lost, it has to be
1074 assumed that it forms a partition with all the missing outdated
1075 nodes. In case my partition might be smaller than the other,
1076 quorum is lost in this moment.
1077 In case you want to allow permanently diskless nodes to gain
1079 quorum it is recommendet to not use majority or all. It is
1080 recommended to specify an absolute number, since DBRD's
1081 heuristic to determine the complete number of diskfull nodes in
1082 the cluster is unreliable.
1083 The quorum implementation is available starting with the DRBD
1085 kernel driver version 9.0.7.
1086 --quorum-minimum-redundancy value
1088 This option sets the minimal required number of nodes with an
1089 UpToDate disk to allow the partition to gain quorum. This is a
1090 different requirement than the plain quorum option expresses.
1091 The option's value might be set to off, majority, all or a
1093 numeric value. If you set it to a numeric value, make sure that
1094 the value is greater than half of your number of nodes.
1095 In case you want to allow permanently diskless nodes to gain
1097 quorum it is recommendet to not use majority or all. It is
1098 recommended to specify an absolute number, since DBRD's
1099 heuristic to determine the complete number of diskfull nodes in
1100 the cluster is unreliable.
1101 This option is available starting with the DRBD kernel driver
1103 version 9.0.10.
1104 --on-no-quorum {io-error | suspend-io}
1106 By default DRBD freezes IO on a device, that lost quorum. By
1107 setting the on-no-quorum to io-error it completes all IO
1108 operations with an error if quorum ist lost.
1109 The on-no-quorum options is available starting with the DRBD
1111 kernel driver version 9.0.8.
1112 drbdsetup outdate minor
1115 Mark the data on a lower-level device as outdated. This is used for
1116 fencing, and prevents the resource the device is part of from
1117 becoming primary in the future. See the --fencing disk option.
1118 drbdsetup pause-sync resource peer_node_id volume
1120 Stop resynchronizing between a local and a peer device by setting
1121 the local pause flag. The resync can only resume if the pause flags
1122 on both sides of a connection are cleared.
1123 drbdsetup primary resource
1125 Change the role of a node in a resource to primary. This allows the
1126 replicated devices in this resource to be mounted or opened for
1127 writing. Available options:
1128 --overwrite-data-of-peer
1130 This option is an alias for the --force option.
1131 --force
1133 Force the resource to become primary even if some devices are
1134 not guaranteed to have up-to-date data. This option is used to
1135 turn one of the nodes in a newly created cluster into the
1136 primary node, or when manually recovering from a disaster.
1137 Note that this can lead to split-brain scenarios. Also, when
1139 forcefully turning an inconsistent device into an up-to-date
1140 device, it is highly recommended to use any integrity checks
1141 available (such as a filesystem check) to make sure that the
1142 device can at least be used without crashing the system.
1143 Note that DRBD usually only allows one node in a cluster to be in
1145 primary role at any time; this allows DRBD to coordinate access to
1146 the devices in a resource across nodes. The --allow-two-primaries
1147 network option changes this; in that case, a mechanism outside of
1148 DRBD needs to coordinate device access.
1149 drbdsetup resize minor
1151 Reexamine the size of the lower-level devices of a replicated
1152 device on all nodes. This command is called after the lower-level
1153 devices on all nodes have been grown to adjust the size of the
1154 replicated device. Available options:
1155 --assume-peer-has-space
1157 Resize the device even if some of the peer devices are not
1158 connected at the moment. DRBD will try to resize the peer
1159 devices when they next connect. It will refuse to connect to a
1160 peer device which is too small.
1161 --assume-clean
1163 Do not resynchronize the added disk space; instead, assume that
1164 it is identical on all nodes. This option can be used when the
1165 disk space is uninitialized and differences do not matter, or
1166 when it is known to be identical on all nodes. See the
1167 drbdsetup verify command.
1168 --size val
1170 This option can be used to online shrink the usable size of a
1171 drbd device. It's the users responsibility to make sure that a
1172 file system on the device is not truncated by that operation.
1173 --al-stripes val --al-stripes val
1175 These options may be used to change the layout of the activity
1176 log online. In case of internal meta data this may invovle
1177 shrinking the user visible size at the same time (unsing the
1178 --size) or increasing the avalable space on the backing
1179 devices.
1180 drbdsetup resume-io minor
1183 Resume I/O on a replicated device. See the --fencing net option.
1184 drbdsetup resume-sync resource peer_node_id volume
1186 Allow resynchronization to resume by clearing the local sync pause
1187 flag.
1188 drbdsetup role resource
1190 Show the current role of a resource.
1191 drbdsetup secondary resource
1193 Change the role of a node in a resource to secondary. This command
1194 fails if the replicated device is in use.
1195 drbdsetup show {resource | all}
1197 Show the current configuration of a resource, or of all resources.
1198 Available options:
1199 --show-defaults
1201 Show all configuration parameters, even the ones with default
1202 values. Normally, parameters with default values are not shown.
1203 drbdsetup show-gi resource peer_node_id volume
1206 Show the data generation identifiers for a device on a particular
1207 connection. In addition, explain the output. The output otherwise
1208 is the same as in the drbdsetup get-gi command.
1209 drbdsetup state
1211 This is an alias for drbdsetup role. Deprecated.
1212 drbdsetup status {resource | all}
1214 Show the status of a resource, or of all resources. The output
1215 consists of one paragraph for each configured resource. Each
1216 paragraph contains one line for each resource, followed by one line
1217 for each device, and one line for each connection. The device and
1218 connection lines are indented. The connection lines are followed by
1219 one line for each peer device; these lines are indented against the
1220 connection line.
1221 Long lines are wrapped around at terminal width, and indented to
1223 indicate how the lines belongs together. Available options:
1224 --verbose
1226 Include more information in the output even when it is likely
1227 redundant or irrelevant.
1228 --statistics
1230 Include data transfer statistics in the output.
1231 --color={always | auto | never}
1233 Colorize the output. With --color=auto, drbdsetup emits color
1234 codes only when standard output is connected to a terminal.
1235 For example, the non-verbose output for a resource with only one
1237 connection and only one volume could look like this:
1238 drbd0 role:Primary
1240 disk:UpToDate
1241 host2.example.com role:Secondary
1242 disk:UpToDate
1243 With the --verbose option, the same resource could be reported as:
1246 drbd0 node-id:1 role:Primary suspended:no
1248 volume:0 minor:1 disk:UpToDate blocked:no
1249 host2.example.com local:ipv4:192.168.123.4:7788
1250 peer:ipv4:192.168.123.2:7788 node-id:0 connection:WFReportParams
1251 role:Secondary congested:no
1252 volume:0 replication:Connected disk:UpToDate resync-suspended:no
1253 drbdsetup suspend-io minor
1257 Suspend I/O on a replicated device. It is not usually necessary to
1258 use this command.
1259 drbdsetup verify resource peer_node_id volume
1261 Start online verification, change which part of the device will be
1262 verified, or stop online verification. The command requires the
1263 specified peer to be connected.
1264 Online verification compares each disk block on the local and peer
1266 node. Blocks which differ between the nodes are marked as
1267 out-of-sync, but they are not automatically brought back into sync.
1268 To bring them into sync, the resource must be disconnected and
1269 reconnected. Progress can be monitored in the output of drbdsetup
1270 status --statistics. Available options:
1271 --start position
1273 Define where online verification should start. This parameter
1274 is ignored if online verification is already in progress. If
1275 the start parameter is not specified, online verification will
1276 continue where it was interrupted (if the connection to the
1277 peer was lost while verifying), after the previous stop sector
1278 (if the previous online verification has finished), or at the
1279 beginning of the device (if the end of the device was reached,
1280 or online verify has not run before).
1281 The position on disk is specified in disk sectors (512 bytes)
1283 by default.
1284 --stop position
1286 Define where online verification should stop. If online
1287 verification is already in progress, the stop position of the
1288 active online verification process is changed. Use this to stop
1289 online verification.
1290 The position on disk is specified in disk sectors (512 bytes)
1292 by default.
1293 Also see the notes on data integrity in the drbd.conf(5) manual
1295 page.
1296 drbdsetup wait-connect-volume resource peer_node_id volume,
1298 drbdsetup wait-connect-connection resource peer_node_id,
1299 drbdsetup wait-connect-resource resource,
1300 drbdsetup wait-sync-volume resource peer_node_id volume,
1301 drbdsetup wait-sync-connection resource peer_node_id,
1302 drbdsetup wait-sync-resource resource
1303 The wait-connect-* commands waits until a device on a peer is
1304 visible. The wait-sync-* commands waits until a device on a peer is
1305 up to date. Available options for both commands:
1306 --degr-wfc-timeout timeout
1308 Define how long to wait until all peers are connected in case
1309 the cluster consisted of a single node only when the system
1310 went down. This parameter is usually set to a value smaller
1311 than wfc-timeout. The assumption here is that peers which were
1312 unreachable before a reboot are less likely to be reachable
1313 after the reboot, so waiting is less likely to help.
1314 The timeout is specified in seconds. The default value is 0,
1316 which stands for an infinite timeout. Also see the wfc-timeout
1317 parameter.
1318 --outdated-wfc-timeout timeout
1320 Define how long to wait until all peers are connected if all
1321 peers were outdated when the system went down. This parameter
1322 is usually set to a value smaller than wfc-timeout. The
1323 assumption here is that an outdated peer cannot have become
1324 primary in the meantime, so we don't need to wait for it as
1325 long as for a node which was alive before.
1326 The timeout is specified in seconds. The default value is 0,
1328 which stands for an infinite timeout. Also see the wfc-timeout
1329 parameter.
1330 --wait-after-sb
1332 This parameter causes DRBD to continue waiting in the init
1333 script even when a split-brain situation has been detected, and
1334 the nodes therefore refuse to connect to each other.
1335 --wfc-timeout timeout
1337 Define how long the init script waits until all peers are
1338 connected. This can be useful in combination with a cluster
1339 manager which cannot manage DRBD resources: when the cluster
1340 manager starts, the DRBD resources will already be up and
1341 running. With a more capable cluster manager such as Pacemaker,
1342 it makes more sense to let the cluster manager control DRBD
1343 resources. The timeout is specified in seconds. The default
1344 value is 0, which stands for an infinite timeout. Also see the
1345 degr-wfc-timeout parameter.
1346 drbdsetup forget-peer resource peer_node_id
1349 The forget-peer command removes all traces of a peer node from the
1350 meta-data. It frees a bitmap slot in the meta-data and make it
1351 avalable for futher bitmap slot allocation in case a so-far never
1352 seen node connects.
1353 The connection must be taken down before this command may be used.
1355 In case the peer re-connects at a later point a bit-map based
1356 resync will be turned into a full-sync.
1357
1359 Please see the DRBD User's Guide[1] for examples.
1360
1362 This document was revised for version 9.0.0 of the DRBD distribution.
1363
1365 Written by Philipp Reisner <philipp.reisner@linbit.com> and Lars
1366 Ellenberg <lars.ellenberg@linbit.com>.
1367
1369 Report bugs to <drbd-user@lists.linbit.com>.
1370
1372 Copyright 2001-2018 LINBIT Information Technologies, Philipp Reisner,
1373 Lars Ellenberg. This is free software; see the source for copying
1374 conditions. There is NO warranty; not even for MERCHANTABILITY or
1375 FITNESS FOR A PARTICULAR PURPOSE.
1376
1378 drbd.conf(5), drbd(8), drbdadm(8), DRBD User's Guide[1], DRBD Web
1379 Site[2]
1380
1382 1. DRBD User's Guide
1383 http://www.drbd.org/users-guide/
1384 2. DRBD Web Site
1386 http://www.drbd.org/
1387DRBD 9.0.x 17 January 2018 DRBDSETUP(8)