11-14-2014 04:53 AM
Following grid upgrade to 6.12 today, the grid manager is now warning of 118% database capacity usage on one of the members. The member is a Trinsic 820 located in Malaysia (the rest of our grid is in the UK). I have done a capacity report on the box, which is indicating that over 50% of that database is now being consumed by an IPv4 DHCP filter that isn't used by any of the networks/ranges assigned to that member. This was not happening prior to the software change.
Have I stumbled across a bug in 6.12?
If not, is there a way of stopping that IPv4 filter using the database resources of a member that does not even need to reference the filter?
12-04-2014 10:10 AM
Appreciate you posting your question. I'm the new community manager, and noticed your question and wanted to ensure you found an answer. Were you able to resolve the issue? Please let me know and I'm happy to reach out to the team for help.
09-21-2015 02:02 AM
Apologies for my very slow response to this. Unfortunately this has not been resolved, the feedback received from Infoblox at the time indicated this was expected behaviour introduced in later versions of 6. See below. Apparently database utilisation of the nature we are seeing is not a cause for concern.
"According to the product requirements from NIOS 6.10.x this problem should also have been visible in that NIOS release but because of a bug in the database partitioning it was not visible.
Our database scheme has changed since 6.10 and higher , so from a product point of view NIOS 6.12.2 is working as expected and these objects should have replicated to the members.
We do of course understand that after an upgrade you should not see a database object increase of a 100%. There is already a project going on within our engineering team to review the database partitioning of what objects should be send to which members , this is still an ongoing project and as part of this project , we will have an optimized partitioning in future releases.
As for the customers current situation , our Engineering and QA management have assured me that we have done QA testing which oversized that database capacity 5 times and which still has not affected the services running on those appliances having a database capacity of 500%."