Bug 498495 - Mysql ndbd Init Script
Mysql ndbd Init Script
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: mysql (Show other bugs)
10
All Linux
low Severity high
: ---
: ---
Assigned To: Tom Lane
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-30 14:31 EDT by Luke Gopher
Modified: 2013-07-02 23:22 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 04:23:09 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
ndbd init script patched (3.78 KB, patch)
2009-04-30 14:33 EDT, Luke Gopher
no flags Details | Diff

  None (edit)
Description Luke Gopher 2009-04-30 14:31:53 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):

mysql-cluster-5.0.77-1.fc10.x86_64

How reproducible:

Configure two datanodes on local FC10 and one only launched

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info: Proposing this start script
Comment 1 Luke Gopher 2009-04-30 14:33:56 EDT
Created attachment 341977 [details]
ndbd init script patched

This script can launch many datanodes on the same FC10
Comment 2 Luke Gopher 2009-05-04 08:01:03 EDT
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 ? ) 

Thanks
Comment 3 Tom Lane 2009-05-04 08:49:30 EDT
mysql is waiting for the fedora release freeze to lift.  Please do not tinker.
Comment 4 Tom Lane 2009-05-04 12:50:30 EDT
IOW, have some patience.
Comment 5 Tom Lane 2009-05-15 20:58:11 EDT
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?
Comment 6 Luke Gopher 2009-05-18 11:59:48 EDT
Hi,

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 :

--extra-file=/var/lib/mysql-cluster/config.ini

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 ?
Comment 7 Bug Zapper 2009-11-18 05:00:54 EST
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 8 Bug Zapper 2009-12-18 04:23:09 EST
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.

Note You need to log in before you can comment on or make changes to this bug.