Skip Menu |

Date: Tue, 25 Sep 2012 16:18:14 -0500
Subject: kadmind per-slave ipropd dumps are wasteful
From: Nico Williams <>
When iprop falls back on full resyncs kadmind uses a per-slave
dump. This is woefully inefficient and puts unnecessary strain
on the master. Moreover, since the dump will have iprop info in
the header we can tell if an existing dump is good enough to
send to any slave: if the sno/timestamp from the header is in
the ulog then we should send the dump without dumping at all,
thereby significantly cutting down the time needed for a full
resync from dump + xfer + load to xfer + load + iprop.
Subject: SVN Commit
Download (untitled) / with headers
text/plain 1.5KiB

Use a single global dump for iprop full syncs

Use a global dump (the default dump file) for full syncs for iprop.
When a slave asks for a fullsync we kprop the existing global dump to it
if that is good enough, else we dump the DB and send the new global

Before this change kadmind would run kdb5_util dump -i... each time a
slave asked for a full dump. This was done in a sub-process,
thankfully, but it was still a waste of time and storage (e.g., if one
has a huge KDB).

Also, long dump times might cause a slave to give up (the timeout for
this is now configurable). But since iprop dumps bear a serial number
and timestamp and since slaves will resync from that point forward, it
doesn't matter if the dump we send a slave is fresh as long as it is
fresh enough (i.e., that its sno and timestamp are in the ulog).


- Rename dumps into place instead of unlink, create, write (but we
still keep the dump ok files as lock files and as a method of
signaling to kprop that the dump is complete).
Author: Nicolas Williams <>
Committer: Greg Hudson <>
Commit: 4fd4144b3222b060f3e9928a9cb4587df9979539
Branch: master
src/include/kdb_log.h | 2 +
src/kadmin/dbutil/dump.c | 231 ++++++++++++++++++++++++++++++---------
src/kadmin/server/ipropd_svc.c | 68 ++++++------
src/lib/kdb/kdb_log.c | 2 +-
src/lib/kdb/libkdb5.exports | 1 +
5 files changed, 215 insertions(+), 89 deletions(-)