Mailinglist Archive: opensuse-bugs (7182 mails)

[bugzilla_noreply@xxxxxxxxxx]

https://bugzilla.novell.com/show_bug.cgi?id=353120

User richard.bos@xxxxxxxxx added comment
https://bugzilla.novell.com/show_bug.cgi?id=353120#c14


Richard Bos <richard.bos@xxxxxxxxx> changed:

           What    |Removed                                         |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                                        |NEEDINFO
      Info Provider|                                                
|richard.bos@xxxxxxxxx




--- Comment #14 from Richard Bos <richard.bos@xxxxxxxxx>  2008-01-22 15:25:16 
MST ---
> (In reply to comment #12 from Richard Bos)
> > > I think your latest proposal still has the problem that all the mysqld
> > > instances will look into the '[mysqld]' section for options not passed
> > > on the command-line. This means that only those options handled by
> > > parse_arguments can be set per-server afaics. Correct me if I'm wrong.
> >
> > I think I have to correct you here.  If the output of my_print_defaults can 
> > be
> > trusted than each database section is a section on its own.  For example:
>
> That's unfortunately not sufficient. Consider this setting:
>
> [mysqld2]
> skip-networking
> datadir = /var/lib/mysql2
> socket = /var/lib/mysql2/mysql.sock
> pid-file = /var/lib/mysql2/mysqld.pid
> log = /var/lib/mysql2/mysqld.log
>
> Then:
>
> # ./rcmysql2 start
> Starting mysql server: mysqld                                        done
> Starting mysql server: mysqld                                        done
> Starting mysql server: mysqld2 warning: /var/lib/mysql2/mysql.sock didn't
> appear within 30 seconds
>                                                                      done
>
> That's because --skip-networking isn't propagated down to mysqld itself,
> which reads the default [mysqld] section and tries to bind to the
> already occupied tcp port 3306. IOW only arguments that are handled
> specially in parse_arguments can be set per-server. That's why I think
> using mysql_multi or mysqlmanager would be a solution. rcmysql would
> then only need to handle arguments it needs to know about (datadir,
> pid-file and socket).

Okay, so than we need to decide on which one to use.  Browsing there respective
manual pages:
http://dev.mysql.com/doc/refman/5.1/en/mysqld-multi.html
http://dev.mysql.com/doc/refman/5.1/en/instance-manager-configuration-files.html

I seem to prefer the mysqld-multi.html.  It feels somehow more familair, than
the manager one.  Is it okay to choose / use mysqld-multi?

> BTW, ./rcmysql2 stop seems to only shutdown the first instance.

That's correct and on purpose.  I don't want to waste writing the stop (and
the status) part of the code without knowing whether the start is okay or
not.  Which was a good decision, as you actually prefer to have another 
start part....

> > > BTW, if you want, I can give you access to the server:database:mysql51
> > > project to try out this feature. If it turns out to be working, I can
> > > merge it to the Factory mysql package.
> >
> > How would you track what changes I make to the script?  The BS does not have
> > a commit notification AFAIK.
>
> An email when you make important changes will suffice (sure, commit
> notification in the bs would be cool). But what I wanted to say is that
> it would be better to first try this out in the buildservice and merge
> it to the distro after it has got some testing. The :mysql51 project is
> still rather experimental, so it's not such a big issue if something
> breaks there :) Factory mysql 5.0 is linked to server:database which is
> used more people, who don't expect it to break too often.

Is it possible to revert to a certain revision in the buildserver?  I don't
remember if something like "osc co -r rXX" is possible.  But than again how
would one know the what has changed, without real log messages...

For archiving purposes:
packages/osc/server:database:mysql51/mysql> osc up
osc At revision 24.

Would be nice (and very handy) if you would let me know for the weekend what
your thought are!


-- 
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.