Thanks, kefu. I have another question, as we have limit the max ops in on transaction during ceph-objectstore-tool update_osdmap() to avoid the rebuild process consuming lots memory and killed by oom. Should we add the same operation in ceph-monstore-tool::update_paxos()? kefu chai <tchaikov@gmail.com> 于2019年6月21日周五 下午10:30写道：
On Thu, Jun 13, 2019 at 10:06 AM huang jun <hjwsm1989@gmail.com> wrote:
Hi,all
Jun, sorry for the latency. got stuck by something else. =(
I recently read the ceph-monstore-tool code, and have a question about rebuild operations. In update_paxos() we read osdmap, pgmap, auth and pgmap_pg records to pending_proposal(a bufferlist) as the value of the key paxos_1, and set paxos_pending_v=1, and set the paxos_last_committed=0 and paxos_first_committed=0;
My question is if we start the mon after rebuild, let's say there is only one mon now, the mon will not commit the paxos_pending_v=1, and if we change the osdmap by 'ceph osd set noout' the new pending_v=1 will overwrite the former one in rebuild, so i think we don't need to
agreed, unless the initial monmap requires more monitors. it will prevent the monitor from forming a quorum to write to the store. yeah, the paxos/1 will be overwritten by the first proposal at rebuilding the mondb. but i think we still need to store the "rebuild" transaction as a paxos proposal, as we need to apply the transaction on the sync client side, after the it syncs the chunks with the sync provider.
probably we should just bump up the last_committed to a non-zero number, to preserve the rebuild transaction. actually, i was testing the fix of the issue you are talking about using the PR of https://github.com/ceph/ceph/pull/27465. but i didn't get a chance to look into the reason why it still failed..
set paxos_1=pending_proposal, paxos_pending_v=1 in 'ceph-monstore-tool rebuild'.
Thanks! _______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io
-- Regards Kefu Chai