Hello all,
I am using BDB 4.7.25 on a Linux 2.6.x environment.
Now I try to use 'Master Lease', the following settings were added to DB_CONFIG.

DB_CONFIG
rep_set_config db_rep_conf_lease
rep_set_timeout db_rep_lease_timeout 5000000
rep_set_clockskew 102 100

And execute example rep_mgr, error occurred.
(1 Master 2 Client, nsites set 3)

ex_rep: DB_ENV->rep_elect: nsites must be zero if leases configured
ex_rep: unexpected election failure: Invalid argument
ex_rep: election thread failed: Invalid argument
ex_rep: PANIC: Invalid argument

Besides, are some settings necessary?

I also meet this problem. After browsing the source code, I find this problem is in function __rep_elect. __rep_elect will be called with parameter "given_nsites" greater than 0(it is always true). However in __rep_elect, there are some checking code:
/* Error checking. */
if (IS_USING_LEASES(env) && given_nsites != 0) {
__db_errx(env,
"DB_ENV->rep_elect: nsites must be zero if leases configured");
return (EINVAL);
}

Thus election thread will fail, and a panic will happen.

I'm curious about the checking above. It is a little strange.

Here is an experimental patch which should fix this problem.

diff -r 2089d019de8b repmgr/repmgr_elect.c
--- a/repmgr/repmgr_elect.c	Mon Sep 08 16:07:04 2008 +0000
+++ b/repmgr/repmgr_elect.c	Sun Sep 28 17:09:57 2008 -0700
@@ -188,7 +188,8 @@ __repmgr_elect_main(env)
 		    (env, "elect thread to do: %d", to_do));
 		switch (to_do) {
 		case ELECT_ELECTION:
-			nsites = __repmgr_get_nsites(db_rep);
+			nsites = IS_USING_LEASES(env) ?
+			    0 : __repmgr_get_nsites(db_rep);
 			/*
 			 * With only 2 sites in the group, even a single failure
 			 * could make it impossible to get a majority.  So,

You're right; that previous patch is defective. However, I think it still makes sense to use a non-zero nvotes.

I've worked up a new version of the fix. But now in testing it some other issues have cropped up. I'll continue working on those, and post the new patch as soon as possible.

Alan Bram
Oracle