@Tom-Elliott Thanks for your patience and this great piece of software. I understood that by changing, deleting , … an object in fog causes deleting and re-entering the database entries (a still existing fog 0.32 server also has relatively high IDs there - but these are still much lower -> a few thousand compared to a few 100k on the test-server for current svn).
I just wondered about the loop of deleting and re-entering, even with the computers turned off the whole time (so no AD join or other fog-client actions could be there - and me is the only one on this fog server for testing)
But the good new is that I found out what was causing the loop. The mysql services was running several processes (mysqld_safe, mysqld with some parameters, mysqld without parameters).
Running dpkg-reconfigure for the mysql server solved this and now just one mysqld process without parameters is running.
It seems to run stable now - for testing i:
- removed a snapin from a group of 19 -> The IDs/auto_increment of groupMembers get up by 19, the IDs of snapinAssoc get up by 18
- added the same snapin again -> The IDs/auto_increment of groupMembers get up by 19, the IDs of snapinAssoc get up by 37
(a second snapin is associated to only 18 of the 19 group members, so the 18 and 37 from the snapinAssoc should be correct)
The reason why I didn’t check the mysqld service directly was that everything seemed to run correctly - imaging was working, the web interface was ok, the database-update when updating the svn version was returning a OK message, … . Even when installing a new svn over a existing svn version there was no errors on the mysql actions displayed.
Think I really have to check every time after each Ubuntu update/restart and fog svn update, if the myqld service is running just one process and check the database more often. (mysqld and other services are already delayed at startup)