This object is in archive!
MySQL Upgrade Should Comment Out Conflicting Directives that Prevent MySQL from Starting
Completed
When I have an old MySQL installation with deprecated directives like record_buffer, cpanel should be smart enough to simply comment these out when I go into WHM and upgrade all the way to 5.5. Instead, it simply fails to start and requires logging in as root over ssh or sftp to adjust the configuration file and then restarting MySQL successfully.
140408 15:19:04 [ERROR] /usr/sbin/mysqld: unknown variable 'record_buffer=1M'
140408 15:19:04 [ERROR] Aborting
I like this idea 
cPanel, WebHost Manager and WHM are registered trademarks of cPanel, L.L.C. for providing its computer software that facilitates the management and configuration of Internet web servers.
In the last many years we have added a bunch of warnings in this process, and aren't likely to add anything that would automatically adjust the configuration file in the future. For that reason, I'm going to mark this one as complete with the additional checking that we added in version 76. If you have any questions, feel free to reach out to me!
In the last many years we have added a bunch of warnings in this process, and aren't likely to add anything that would automatically adjust the configuration file in the future. For that reason, I'm going to mark this one as complete with the additional checking that we added in version 76. If you have any questions, feel free to reach out to me!
This seems like dangerous and undesired behavior to just assume the server owner is okay without having knowledge of configuration options they've explicitly set being invalidated/deprecated. As a server owner, if I set an option and it deprecates, I would like to know so that I can make a conscious decision on what to do and if the deprecation of the option affects how my server is used. I would not want it silently commented out. Of course, I also do not want my MySQL daemon to be offline.
Therefore, I think the desired behavior here would be to refuse to even start a MySQL upgrade at all if known deprecated options are in use. In this way, MySQL is never placed into a "can't startup" state and the server owner is made aware that they must adjust their configuration to be compliant before starting the upgrade. This way they can assess, while MySQL is still in a valid state, if "losing" the deprecated features is acceptable or if they need to hold back on a particular version until they determine their action steps for moving forward.
Do you agree? I'd also like to hear further feedback from other server owners to see their preferred handling of this.
This seems like dangerous and undesired behavior to just assume the server owner is okay without having knowledge of configuration options they've explicitly set being invalidated/deprecated. As a server owner, if I set an option and it deprecates, I would like to know so that I can make a conscious decision on what to do and if the deprecation of the option affects how my server is used. I would not want it silently commented out. Of course, I also do not want my MySQL daemon to be offline.
Therefore, I think the desired behavior here would be to refuse to even start a MySQL upgrade at all if known deprecated options are in use. In this way, MySQL is never placed into a "can't startup" state and the server owner is made aware that they must adjust their configuration to be compliant before starting the upgrade. This way they can assess, while MySQL is still in a valid state, if "losing" the deprecated features is acceptable or if they need to hold back on a particular version until they determine their action steps for moving forward.
Do you agree? I'd also like to hear further feedback from other server owners to see their preferred handling of this.
I like warning on updates to make sure MYSQL will start.
Putting the options into the GUI to say "go ahead with the upgrade I am fine losing the settings" sounds good.
I like warning on updates to make sure MYSQL will start.
Putting the options into the GUI to say "go ahead with the upgrade I am fine losing the settings" sounds good.
Thanks for your insightful response, Brian. I think that is an entirely valid point and I agree that it would be desirable to notify the user of the conflict before the upgrade process even starts. I also like Mark's suggestion of implementing something in the GUI that would allow the user to address this issue without forcing them to log in over SSH/SFTP. This could be as simple as "comment out conflicting directives" or, to go further, it could display what the current values are and prompt to set them to the defaults (comment them out) or to adjust the values to the updated syntax
Thanks for your insightful response, Brian. I think that is an entirely valid point and I agree that it would be desirable to notify the user of the conflict before the upgrade process even starts. I also like Mark's suggestion of implementing something in the GUI that would allow the user to address this issue without forcing them to log in over SSH/SFTP. This could be as simple as "comment out conflicting directives" or, to go further, it could display what the current values are and prompt to set them to the defaults (comment them out) or to adjust the values to the updated syntax
In the last many years we have added a bunch of warnings in this process, and aren't likely to add anything that would automatically adjust the configuration file in the future. For that reason, I'm going to mark this one as complete with the additional checking that we added in version 76. If you have any questions, feel free to reach out to me!
In the last many years we have added a bunch of warnings in this process, and aren't likely to add anything that would automatically adjust the configuration file in the future. For that reason, I'm going to mark this one as complete with the additional checking that we added in version 76. If you have any questions, feel free to reach out to me!
Replies have been locked on this page!