Dear Kyle,
Thank you for your response.
What I was attempting actually led to a security hole for clients.
I am implementing your method instead as it appears to be a solution which
would work well.
Thanks so much for such a detailed response.
Best regards,
Mustafa.
----- Original Message -----
From: "Kyle Hayes" <[EMAIL PROTECTED]>
To: "Mustafa Hashmi" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, August 31, 2001 9:08 AM
Subject: Re: Virtualizing MySQL
> On Thursday 30 August 2001 14:09, Mustafa Hashmi wrote:
> > Thanks for the response Joshua,
> >
> > That is an option - however not one I would be very comfortable with. I
> > have a similar setup for virtual hosts generally - wanted something more
> > flexible and powerful for a virtual server implementation without taxing
> > the actual server too much.
> >
> > For example, the mail server (qmail) is not chrooted as such - however
pop
> > is chrooted via tcpserver, delivering messages to users in a virtual
env.
> > SMTP works the same way, chrooting to say "/home/user/etc/tcp.cdb" to
check
> > relay.
> >
> > Unfortunately, I know little about the actual "how-does-it-work" part of
> > MySQL and need some direction :)
> >
> > I am going to try something in the next 3-4 days and hopefully I'll post
a
> > positive outcome.
> >
> > If this works, I'll write a HowTo :)
> >
>
> anti-Spam: database, query, SQL, MySQL
>
> We run multiple instances of MySQL on the same machine. We use the
ability
> of the MySQL server to get its configuration from a file.
>
> For instance, we have three instances on one machine that all run from
> different directories.
>
> We organize the directories like this:
>
> instance1:
>
> /...blah blah.../instance1/bin/ <--- special scripts for this instance
> /...blah blah.../instance1/etc/ <--- config for this instance
> /...blah blah.../instance1/log/ <--- logs for this instance
> /...blah blah.../instance1/data/ <--- database data for this instance
> /...blah blah.../instance1/run/ <-- PID file + socket for this instance
>
> instance2:
>
> /...blah blah.../instance2/bin/ <--- special scripts for this instance
> /...blah blah.../instance2/etc/ <--- config for this instance
> /...blah blah.../instance2/log/ <--- logs for this instance
> /...blah blah.../instance2/data/ <--- database data for this instance
> /...blah blah.../instance2/run/ <-- PID file + socket for this instance
>
> etc....
>
> In each etc/ directory for each instance, we have a my.cnf file that
defines
> all the data directories, socket files, log file paths etc. We also make
> sure that each instance runs on a different port. This allows us to
connect
> to each instance remotely as well as locally. We use a base port address
> (say 5000) and add the instance number. Thus instance one runs at port
5001,
> instance two at 5002 etc.
>
> Each instance is started by a special version of safe_mysqld (only very
> mildly changed) that takes an extra argument. That argument is the
instance
> to run. It then adds the following to the command line for the mysqld
binary:
>
> /.../bin/mysqld --defaults-file=/...blah blah.../instanceX/etc/my.cnf
>
> where X is the instance number and my.cnf is the specific config file for
> that instance. We'd run it like this:
>
> /...bin/mysql_ctrl instance1 start
>
> We have also run MySQL in a completely chroot-ed environment where each
> instance has its own copy of the MySQL binaries, libraries etc. This is
> rather a pain to set up. MySQL does have some chroot capabilities of its
> own, but we haven't tried them yet. There is some information in the
online
> manual if you look for it. The "native" MySQL chroot capabilities plus
the
> different config files sound more like what you want.
>
> The fully chroot-ed environment lets us run different versions of MySQL
> simultaneously. The different instances above require the same binary for
> all instances. However, each instance can be controlled entirely
separately
> with different configurations, stopping and starting them independently
etc.
>
> One of the things that makes the instances very useful for us is that the
> special scripts in the instance bin directories are hardcoded to use that
> instance. Thus, we can just cd to the instance1/bin directory and use
> scripts to bring up and down that instance without having to know what
> instance it is. We were having problems with people forgetting which
> instance they wanted to bring up or down and taking the wrong one down
> The hardcoded scripts stopped that error.
>
> Best,
> Kyle
>
> ---------------------------------------------------------------------
> Before posting, please check:
> http://www.mysql.com/manual.php (the manual)
> http://lists.mysql.com/ (the list archive)
>
> To request this thread, e-mail <[EMAIL PROTECTED]>
> To unsubscribe, e-mail
<[EMAIL PROTECTED]>
> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
>
>
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
