Problem with database replication

Jeremy Hunt jeremyh at optimation.com.au
Wed Sep 25 21:16:17 EDT 2013


Hi Jurgen,

This could be anything, but I am guessing it is a corruption of your 
dump file.

You don't really give a lot of detail on this.We don't know what version 
of kerberos you are running, if you have different versions of kerberos 
on the master and the slave. We don't know if you are using kprop, but I 
presume your are. We don't know anything about the arguments to kdb_util 
and the load.

We don't know if you have recently changed the configuration files on 
each server. I am not asking you to post these, but if you do post these 
to us, please at least change the server and domain names.

I presume you are doing your own full propagation with kprop and kpropd 
and not incremental propagation. Though as you say you disabled a cron 
job and you tried to manually do the load and a couple of entries 
loaded, then this is not your problem.

So assuming it is a database corruption and you see that some entries 
have been loaded, you may suppose that it is the last entry or next one 
or two entries not reported that is the cause of the problem.

The dump file is a flat clear text file, and you can inspect these 
entries and see if there is a difference.

Please do not post the dump file or any of its principal entries to this 
list.

But the first line tells you what format the dump file is. Have a look 
at the first line and see if your load arguments are incompatible with 
the dump format in the dump file. This is one reason why I asked about 
versions of kerberos on the master and the slave.

In summary I suggest:
'head -1' of the dump file to see what dump format is in use.
Try to set that format as an argument to the load option of kdb_util and 
see if that works.

If that is successful then it is up to you to see what caused the change 
on the master to change the format of the dump, or what change occurred 
on the slave to change the format of the load.

If it is not succesful, see if you can inspect the the next couple of 
entries in the dump file and see if there is something wrong with them.

You can dump individual principals to a dump file and try to load them 
on the slave to see if they are the cause of the problem. Remember to 
include the '-update' option to load in this case, else you will remove 
all other entries in the database. You can also inspect the 'princ' 
entry in the single entry files and the dump file you have.

Good Luck,

Jeremy

Jürgen Obermeyer wrote:
> Good evening from Germany,
>
> I spend days in reading tons of Kerberos-docs, but I didn't find a
> solution to the following problem – maybe somebody can help me here?
> The database replication between my Kerberos master and slave doesn't
> work any more. The database dump is generated and transfered to the
> slave, but the update process hangs after the processing of some entries
> and the CPU load is nearly at 100% - „top“ lists the kdb5_util tool as
> originator.
>
> I tried also to import the database dump manually with the verbose
> option – so I can see that some entries are imported and than the
> process hangs.
>
> So I stopped my cron job doing the replication (first problem), but now
> I can see that the CPU usage of the krb5kdc process is nearly at 100%
> (second process).
>
> I have really no idea what to do none and I need some help!
> Thanks a lot in advance!
>
> Jürgen
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos



More information about the Kerberos mailing list