The right thing to do is something like
mdadm --add /dev/md0 /dev/sdb1. Use the correct array in place of
md0 and the correct partition in place of
The key thing is the array is running. Its completely unambiguous which data to copy: the data that is currently running. If you have bitmaps enabled, the resync will be fairly fast as it'll only copy what has changed. Otherwise, it'll copy everything.
If you are extremely paranoid—or you're worried that your disk system may have lost writes, and the bitmap may not be correct—and don't mind forcing a full copy, you can wipe the superblock on the disk you're about to add using
mdadm --zero-superblock /dev/sdb1 (once again, use the correct partition).
If the array wasn't currently running (e.g., if this were a rebuild on assemble from an unclean shutdown), then the decision on what to copy is made using the update count fields stored in the superblock. Its possible that it may refuse to re-add a disk with a too-high update count (forcing you to zero the superblock), but it won't overwrite the active data.
If you were to use the
dd approach, then: (a) You'd wind up copying the superblock, and you'd wind up with two disk 1s (the superblock stores the position of the disk in the array); (b) you'd have an inconsistent copy, unless you had the array stopped (or maybe in read-only mode) during the copy. (And then, to fix a and b, you'd wipe the superblock and let mdraid copy the data, as above).
In short, when you decide to use mdraid (or any other RAID), you give management of redundancy to it. You almost never want to go around it. Same with LVM: if you want to move data around, you use
pvmove, etc. You don't use
PS: "one drive somehow left the mirror" is not something you should accept. There are logs; figure out why it left the mirror. With even a half-recent kernel, bad blocks don't drop drives out anymore, so random drive drops should not happen. Check smart status, etc.