From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Changlong Xie <xiecl.fnst@cn.fujitsu.com>,
zhanghailiang <zhang.zhanghailiang@huawei.com>,
Wen Congyang <wency@cn.fujitsu.com>
Cc: Simon Kollberg <dv11skg@cs.umu.se>, Luis Tomas <luis@cs.umu.se>,
qemu devel <qemu-devel@nongnu.org>,
qemu block <qemu-block@nongnu.org>, Abel Souza <abel@cs.umu.se>
Subject: [Qemu-devel] COLO: how to flip a secondary to a primary?
Date: Fri, 22 Jan 2016 19:35:35 +0000 [thread overview]
Message-ID: <20160122193534.GF2482@work-vm> (raw)
Hi,
I've been looking at what's needed to add a new secondary after
a primary failed; from the block side it doesn't look as hard
as I'd expected, perhaps you can tell me if I'm missing something!
The normal primary setup is:
quorum
Real disk
nbd client
The normal secondary setup is:
replication
active-disk
hidden-disk
Real-disk
With a couple of minor code hacks; I changed the secondary to be:
quorum
replication
active-disk
hidden-disk
Real-disk
dummy-disk
and then after the primary fails, I start a new secondary
on another host and then on the old secondary do:
nbd_server_stop
stop
x_block_change top-quorum -d children.0 # deletes use of real disk, leaves dummy
drive_del active-disk0
x_block_change top-quorum -a node-real-disk
x_block_change top-quorum -d children.1 # Seems to have deleted the dummy?!, the disk is now child 0
drive_add buddy driver=replication,mode=primary,file.driver=nbd,file.host=ibpair,file.port=8889,file.export=colo-disk0,node-name=nbd-client,if=none,cache=none
x_block_change top-quorum -a nbd-client
c
migrate_set_capability x-colo on
migrate -d -b tcp:ibpair:8888
and I think that means what was the secondary, has the same disk
structure as a normal primary.
That's not quite happy yet, and I've not figured out why - but the
order/structure of the block devices looks right?
Notes:
a) The dummy serves two purposes, 1) it works around the segfault
I reported in the other mail, 2) when I delete the real disk in the
first x_block_change it means the quorum still has 1 disk so doesn't
get upset.
b) I had to remove the restriction in quorum_start_replication
on which mode it would run in.
c) I'm not really sure everything knows it's in secondary mode yet, and
I'm not convinced whether the replication is doing the right thing.
d) The migrate -d -b eventually fails on the destination, not worked out why
yet.
e) Adding/deleting children on quorum is hard having to use the children.0/1
notation when you've added children using node names - it's worrying
which number is which; is there a way to give them a name?
f) I've not thought about the colo-proxy that much yet - I guess that
existing connections need to keep their sequence number offset but
new connections made by what is now the primary dont need to do anything
special.
Dave
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next reply other threads:[~2016-01-22 19:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-22 19:35 Dr. David Alan Gilbert [this message]
2016-01-25 1:32 ` [Qemu-devel] COLO: how to flip a secondary to a primary? Wen Congyang
2016-01-25 2:11 ` Li Zhijian
2016-01-25 20:20 ` Dr. David Alan Gilbert
2016-01-26 1:16 ` Li Zhijian
2016-01-25 18:59 ` Dr. David Alan Gilbert
2016-01-26 1:06 ` Wen Congyang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160122193534.GF2482@work-vm \
--to=dgilbert@redhat.com \
--cc=abel@cs.umu.se \
--cc=dv11skg@cs.umu.se \
--cc=luis@cs.umu.se \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=wency@cn.fujitsu.com \
--cc=xiecl.fnst@cn.fujitsu.com \
--cc=zhang.zhanghailiang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).