Seperate MySQL Server

[wrotruck]

Hi there:

I'm not sure where to post this so, I'll try posting the question here.  I have started working through my first installation and it seems that no matter how well I think I have have it planned it always seems like there is some new wrinkle that I think of.

In that vein, I have a MySQL server that handles my CMS (drupal), Gallery2 and team speak servers.  Is it possible to have Linux MCE use the MySQL Server that already exists on my network and shut down the MYSQL server that would run on the core?  My assertion is that this would free up some processor & RAM overhead on the core and help the network as a whole run a bit more effeciently.

This question was discussed about a year ago here:
http://forum.linuxmce.org/index.php?topic=1610.0

but there was really not published resolution.  Does anyone know if this is possible and what the process would be?

Thanks...

-Wil

[tschak909]

No. It is currently not possible, and would be very difficult to implement, as not only the database abstraction libraries, but also the various scripts underneath make the assumption that the database is running on localhost.

If you would like this functionality, we do accept patches.

-Thom

[wrotruck]

Thom:

Thanks for the quick reply.  If that's the case would it be easier to backup the other databases and move them to the Linux MCE Core?

I wouldn't mind helping out with a patch if there is interest in it beyond my own.  Beyond picking through all the past work done, is there a place to find out what scripts, abstration libs, etc. would need to be altered?

Thanks...

-Wil

[tschak909]

1. Yes.

2. Yes. grep is your friend. look for RunSQL declarations in the shell and awk scripts, look for DBI calls in PERL scripts.

now, beware, there be dragons everywhere. I mean it. So you'll probably need to just do a lot of sifting with grep.

-Thom

[colinjones]

1. Yes.

2. Yes. grep is your friend. look for RunSQL declarations in the shell and awk scripts, look for DBI calls in PERL scripts.

now, beware, there be dragons everywhere. I mean it. So you'll probably need to just do a lot of sifting with grep.

-Thom

This may be a silly point, Thom, but shouldn't the SQL database also be implemented as a DCE device, and queries wrapped and passed through that? Or is that going too far?

[tschak909]

No.

-Thom

[bulek]

1. Yes.

2. Yes. grep is your friend. look for RunSQL declarations in the shell and awk scripts, look for DBI calls in PERL scripts.

now, beware, there be dragons everywhere. I mean it. So you'll probably need to just do a lot of sifting with grep.

-Thom

This may be a silly point, Thom, but shouldn't the SQL database also be implemented as a DCE device, and queries wrapped and passed through that? Or is that going too far?

Hi,

AFAIK General Info plugin is slowly progressing toward your description. It's getting intermediate info server for user queries. Haven't tried yet, but I think that this will be the right answer in the future. But it will probably never give you all information from database...

Regards,

Bulek.

[tschak909]

Basically,

Any house-wide logic and query should be handled by their respective plugins.

Plugins have access to not only their own internal states, but also the internal states of all of the other plugins.

It would be a tragic mistake to do a thin wrapper as a database plugin, and instead the relevant commands should be added to the appropriate plugins to do the work.

The exception to this, is for data provider plugins which expressly provide stuff like data grids etc in other forms (XML, etc.) THESE SHOULD ONLY BE CREATED AND USED TO BRIDGE TO EXISTING INFRASTRUCTURES, AND SHOULD NOT BE USED AS A CRUTCH FOR NEW DEVELOPMENT.

-Thom

[Zaerc]

I recently got around to cleaning up the scripts (as you can see here) might not be all but it's a good start I reckon.

[hari]

cool zaerc, nice work!

br, Hari

[wrotruck]

UGH!  Dragons is a bit of an understatement!  This is sort of like a very dangerous mine field!

With the holidays over, I spent the last week using about a 1/2 hour a day to try and run the database calls back to their base applications and pick though the respective scripts.  To do this, I put tracked where the database queries were coming from.  The first thing I noticed was that each individual application was making its own queries.  This made sense as, fundamentally, LMCE is a collection of applications bolted together.

As I was blowing up a few installs trying to make the setting changes, I started to consider middleware.  If there was a small application to proxy, prioritize and redirect the querys as well as put schema into the database at creation/install that should solve the problem without requiring a hunt ans rewrite.

Thoughts?

-Wil

[hari]

like... a local database? :-p

[Zaerc]

You're welcome.

[wrotruck]

Lol.. guess I deserved that! 

As I am still a bit new to Linux MCE, I'm wondering how large the installations are and if it makes sense to worry about application priority in database queries.  That would be the big advantage to a proxy.  The nice side effect is that the application could direct the queries to either a localhost database or another database server.

I'll ask the question again, is this a community need or just something that only a few people are interested in?  I'm willing to try and do this but, I am not a great coder and this would be some work.

Thoughts?

-Wil

[colinjones]

Very much a "nice to have" not a "need to have". Any work that takes the modularity and actually allows you to distribute the computing can't hurt and in some cases would be useful. However, in terms of load it really doesn't seem to be that necessary, and it doesn't resolve any single points of failure because the core is both the gateway and the DCE Router still.