Red Hat Bugzilla – Bug 498495
Mysql ndbd Init Script
Last modified: 2013-07-02 23:22:06 EDT
Description of problem:
Launch Script is not compatible with many datanodes on the same mysql server
Version-Release number of selected component (if applicable):
Configure two datanodes on local FC10 and one only launched
Steps to Reproduce:
Additional info: Proposing this start script
Created attachment 341977 [details]
ndbd init script patched
This script can launch many datanodes on the same FC10
Can I commit this new ndbd init script on Fedora CVS ?
Do do this , can I have the CVS commit right ( getting approuved to do this ? )
mysql is waiting for the fedora release freeze to lift. Please do not tinker.
IOW, have some patience.
I looked at this script a bit. Most of the individual changes look like bad ideas to me:
* forcing my_print_defaults to read defaults files other than what it would normally read seems inappropriate here. It's important that it pick up the same values that the actual daemon would see.
* the changes to get_mysql_option break it for pre-existing usages. If there's a need for something that operates in the new fashion then it probably has to be a separate subroutine. Oh, and you didn't bother to update the comment explaining what it does.
* adding echo commands to the script might be good for debugging it, but they shouldn't be in a production version.
* you can not seriously expect that it's okay to not have a "stop" command. What happens at system shutdown?
I'm not really convinced that there's an important use-case for more than one data node on a single machine, but am willing to consider adjustments to the script to support the case so long as they don't break things.
One thought is that it would probably fit better with the initscript model if each data node were treated as a separate service --- then, for example, you could stop or restart just one of them if you wanted. Perhaps this could be handled by symlinking the one ndbd init shellscript multiple times as "ndbd-1", "ndbd-2", etc, and then have the script detect its own name as a hint to which node it should control. But offhand I don't see how that would get installed except by the sysadmin manually creating those symlinks, so maybe there's a better way.
Do you want to take these ideas and have another go at it?
I am agree with you with this four points. My init script is not enough solid.
It is true that the use case of many datanodes on the same host looks like strange for an HA system , but many Fedora users works on a standalone PC. In my case , I prepare mysql Certification so i want to test everything in datanode management.
The Mysql Cluster doesn't want to start with only one datanode in configuration ( 2 is the minimum ).
So I found that it is not clean to start one standalone datanode then we have configured twice in config.ini ( default config file for NDB Manager isn't it ? )
Also, on one hand you read default file for /etc/init.d/ndb_mgmd init script in :
But in the other hand you read /etc/my.cnf into ndbd init script.
I think that these two scripts and the entire configuration of the cluster would be consistent.
NDBD configuration can be into config.ini too. So ndbd init script could use --extra-file option too in my_print_default ?
What do you think of these ideas ?
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '10'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 10's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 10 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.