Hide Forgot
Description of problem: Going over the procedure to backup and restore the Undercloud machine, during the step that restore the old SQL data on a new machine, mariadb will not handle a large stream of data and will fail, causing the DB to be only partially restored. The documentation here points to install mariadb but do no other configurations are made for it. The default values prove to be too weak to handle too much data. Version-Release number of selected component (if applicable): RHOS 10 How reproducible: 50% Steps to Reproduce: 1. Follow the official guide to backup and restore the undercloud machine 2. Perform step "cat undercloud-backup$date.sql | mysql" Actual results: ERROR 2006 (HY000): MySQL server has gone away And the SQL data is only partially uploaded Expected results: All SQL data was uploaded successfully. Additional info: Personally I added these parameters which but worked for me: key_buffer=64M max_allowed_packet=64M thread_stack=192K thread_cache_size=2 query_cache_limit=1M query_cache_size=64M
Assigning to Mikey for review. Mikey, see Martin's recommended course of action in comment 1. This bug might need to spend some time with QE before it can come back to us, but see what you think as well.
Reaching out to QE to coordinate the next steps in addressing this issue. Might need further testing, will update here when news arrives.
Hi, I have added the above parameters just to make things work. In my experience those should work fine while trying to upload big chunks of data, but from a pure QA point of view those parameters are needed to be tested on a large scale deployment and for a while to make sure there are no resources and performance issues.
Thanks for the clarification Amit. Can/should we reassign this to QE for further testing? cc Lucy Martin..
switching to DF:DFG . I think it's either DOCs to make sure the values are according the recommendation : key_buffer=64M max_allowed_packet=64M thread_stack=192K thread_cache_size=2 query_cache_limit=1M query_cache_size=64M
(In reply to Omri Hochman from comment #6) > switching to DF:DFG . > > I think it's either DOCs to make sure the values are according the > recommendation : > > > key_buffer=64M > max_allowed_packet=64M > thread_stack=192K > thread_cache_size=2 > query_cache_limit=1M > query_cache_size=64M After discussion - since this bug has not been reported as reproducible from the field ,but still it might be relevant in specific cases, instead of adding to documentation this bz OSP10 Release-Notes
Hi again Omri, I see that no action was taken on this bug since my last comment (see comment 10). Is there anything I can help with to move this along?
Reassigning to Omri Hochman since more information is required on this BZ before it can be reassigned to the docs team. Please tag here for questions, but see comment 10 for instructions on how to prepare an issue for release notes.
The needinfo in this BZ has been unanswered for six months. Since the requirement for progressing this bug is not clear to me, I am moving this to CLOSED and clearing the needinfo. If you can provide the requested information to complete this request, please reopen the BZ.