LinuxMCE Forums

General => Feature requests & roadmap => Topic started by: jondecker76 on February 06, 2008, 06:56:12 pm

Title: Feature Request - Database relocation
Post by: jondecker76 on February 06, 2008, 06:56:12 pm
As I am building my core, I have been thinking about data integrity. Media is the first thing that comes to mind. But what about the countless hours that go into filling in metadata etc....
In my core, I have one system drive, and 3 drives in raid 5 for my media, I figured this would make it easy to do a complete reinstall on the system drive if I ever had to, without risking losing all of my media. Then I thought it would be nice if I could have RAID protection for the database itsself. Its easy to see how someone could have literally thousands of hours into tweaking their database. Doesn't that deserve to be protected as much as the media?

What does everyone think?
Title: Re: Feature Request - Database relocation
Post by: jondecker76 on February 06, 2008, 10:53:50 pm
Just to sum up what I'm proposing -
Just a setting in the admin page that lets you relocate the database to another directory/disk/partition (so you can put it on your raid array, etc...)
Title: Re: Feature Request - Database relocation
Post by: colinjones on February 06, 2008, 11:36:27 pm
I really wouldn't rely on RAID as your only form of protection. Frankly, from my experience of hardware RAID, it fails much more than you would expect it to, and data recovery from a RAID'd drive is much more difficult than a simple drive. Software RAID is often worse!

Check out another thread I am running at the moment on the subject of metadata for media. Under 0710b3 and up it seems that the metadata is much more transportable and less reliant on the database, which could address your concerns. Unless you are concerned about all the other stuff in the database, like your device configuration.

In which case, I would say look for a MySQL backup tool and back the DB up yourself, to your RAID drive. I am hoping also to then back up my media drives incrementally to DVDs ( which in your case would include your DB) - yet to track down a reasonable backup tool to do it...
Title: Re: Feature Request - Database relocation
Post by: PowrrrPlay on February 07, 2008, 03:44:35 am
jondecker;

I totally agree with your statement.   I would even go as far to say that since mysql is nolonger open source that the linuxmce project follow what all serious "open" source projects are doing and plan to migrate/fork to postgresql.

BTW, I have been running hot swap raid 5 for more than 4 years.   have rebuilt my array on the fly on two different occations because of a HDD failure.  Love it.   I still back up my array because if there is a "B and E" or other major hardware failure you always need to go to your backup.   In any case I like your proposal.

Frow what I am reading and witnessing the project is more concerned about simplicity rather than technical excellence.  Going to be tough competing with bill's deep pockets.  Cheers.
Title: Re: Feature Request - Database relocation
Post by: 1audio on February 07, 2008, 03:48:02 am
I would also like a backup system that goes to DVD. I could then get real use from my Powerfile.
Title: Re: Feature Request - Database relocation
Post by: RichardP on February 07, 2008, 06:57:11 am
In which case, I would say look for a MySQL backup tool and back the DB up yourself, to your RAID drive. I am hoping also to then back up my media drives incrementally to DVDs ( which in your case would include your DB) - yet to track down a reasonable backup tool to do it...

I use WebMin for a quick and easy solution to ad-hoc backups. I've heard of people using it as part of a structured backup plan, though.

Title: Re: Feature Request - Database relocation
Post by: RichardP on February 07, 2008, 07:34:25 am
jondecker;

I totally agree with your statement.   I would even go as far to say that since mysql is nolonger open source that the linuxmce project follow what all serious "open" source projects are doing and plan to migrate/fork to postgresql.


Why do you say mysql is no longer open source? There have been no changes, AFAIK.

Best Regards,
Richard.
Title: Re: Feature Request - Database relocation
Post by: rrambo on February 07, 2008, 03:05:04 pm
jondecker;

I totally agree with your statement.   I would even go as far to say that since mysql is nolonger open source that the linuxmce project follow what all serious "open" source projects are doing and plan to migrate/fork to postgresql.


Why do you say mysql is no longer open source? There have been no changes, AFAIK.

Best Regards,
Richard.

http://www.reuters.com/article/mergersNews/idUSWNAS661820080116

Sun bought mysql...  but I haven't found anything saying that mysql will not remain open source.
Title: Re: Feature Request - Database relocation
Post by: PowrrrPlay on February 07, 2008, 03:12:26 pm
RichardP;

The full function mysql database is not free to the public.   

As well, SUN recently announced their acquisition of the company that owns mysql.  SUN is profit driven.  Expect more changes in the future while SUN squeezes every penny out of that puppy.

There are many companies like mysql that have an entry level product like mysql.   This is how they get you hooked on their crack.   Free to start, then as you require better crack, i mean features you have to pay up.  mysql does not fall under a true "open source" license.   Postgresql does.   It is also fact that; for enterprise computing postgresql is often compared with Oracle, DB2 and SQL Server.
Title: Re: Feature Request - Database relocation
Post by: tschak909 on February 07, 2008, 03:37:08 pm
Powerrrplay: it would be a wonderful exercise to port sql2cpp, mysql_wrapper, and the various shell scripts, perl scripts, and ruby scripts to use another database, such as PostgreSQL. Would you like to try your hand at it?

-Thom
Title: Re: Feature Request - Database relocation
Post by: PowrrrPlay on February 07, 2008, 04:00:47 pm
LOL;    Thom

I will leave that one up to the project manager.   But it is good food for thought.  Replication and a pile of other features you need in a commercial DBMS are free/open source in Postgresql.   What is your favourite flavour of crack?

http://en.wikipedia.org/wiki/PostgreSQL - FOR THOSE WONDERING - http://www.posgresql.org

as well: PostgreSQL 8.3 Released 3 days ago
Posted on 2008-02-04
Posted by josh@postgresql.org

Today the PostgreSQL Global Development Group releases the long-awaited version 8.3 of the most advanced open source database, which cements our place as the best performing open source database. Among the performance features you'll be excited about in 8.3 are:

    * Heap Only Tuples
    * BGWriter Autotuning
    * Asynchronous Commit
    * Spread Checkpoints

   

    * Synchronous Scan
    * "Var-Varlena"
    * L2 Cache Protection
    * Lazy XID


8.3 also has a lot of cool features for PostgreSQL DBAs and developers, including:

    * CSV Logging
    * SQL/XML
    * MS Visual C++ support
    * ENUMs

   

    * Integrated Tsearch
    * SSPI & GSSAPI
    * Composite Type Arrays
    * pg_standby


There are many, many other features included in this release. Visit the features list and the features matrix for more information, and browse the release notes to see the more than 300 patches that went into the release. You can even visit the press page.
Title: Re: Feature Request - Database relocation
Post by: colinjones on February 07, 2008, 09:11:28 pm
RichardP;

The full function mysql database is not free to the public.   

As well, SUN recently announced their acquisition of the company that owns mysql.  SUN is profit driven.  Expect more changes in the future while SUN squeezes every penny out of that puppy.

There are many companies like mysql that have an entry level product like mysql.   This is how they get you hooked on their crack.   Free to start, then as you require better crack, i mean features you have to pay up.  mysql does not fall under a true "open source" license.   Postgresql does.   It is also fact that; for enterprise computing postgresql is often compared with Oracle, DB2 and SQL Server.

RichardP

Not sure what Powrrrplay is referring to either - MySQL is still open source! Perhaps (s)he is getting mixed up with MaxDB? Or MySQL Enterprise? MaxDB was a project that SAP split off from MySQL years ago as a supported DB for SAP (I use it at work), this isn't open source (at least in the GPL sense). And MySQL Enterprise is a pay-for product, but still part of the open source project - its not that different from the way Canonical offer pay-for support services for the Ubunutu family, they are still open source, and free to use, but you need to pay if you want professional/enterprise support... which is entirely reasonable if you ask me!

BTW - I'm sure that PostgreSQL is a wonderful product, however LMCE just needs a simple database for storing config and metadata, I can't see any requirement for massively high speed transaction processing, other performance enhancements and all the other features. From what I have seen performance is unlikely ever to be a problem, and the vast majority of activity is processing relatively simple SQL Select statements. MySQL is more than capable of this (and much more). I don't see any value in tying up valuable dev time porting to a new platform. Thom - I don't think the irony in your comment came across .... :)
Title: Re: Feature Request - Database relocation
Post by: tschak909 on February 07, 2008, 11:44:05 pm
why are you laughing?

you're talking a big game, why don't you step up to the plate and help make it a reality? you can check out the sources and try it on your copy.

or are you more talk than action?

-Thom


LOL;    Thom

I will leave that one up to the project manager.   But it is good food for thought.  Replication and a pile of other features you need in a commercial DBMS are free/open source in Postgresql.   What is your favourite flavour of crack?

http://en.wikipedia.org/wiki/PostgreSQL - FOR THOSE WONDERING - http://www.posgresql.org

as well: PostgreSQL 8.3 Released 3 days ago
Posted on 2008-02-04
Posted by josh@postgresql.org

Today the PostgreSQL Global Development Group releases the long-awaited version 8.3 of the most advanced open source database, which cements our place as the best performing open source database. Among the performance features you'll be excited about in 8.3 are:

    * Heap Only Tuples
    * BGWriter Autotuning
    * Asynchronous Commit
    * Spread Checkpoints

   

    * Synchronous Scan
    * "Var-Varlena"
    * L2 Cache Protection
    * Lazy XID


8.3 also has a lot of cool features for PostgreSQL DBAs and developers, including:

    * CSV Logging
    * SQL/XML
    * MS Visual C++ support
    * ENUMs

   

    * Integrated Tsearch
    * SSPI & GSSAPI
    * Composite Type Arrays
    * pg_standby


There are many, many other features included in this release. Visit the features list and the features matrix for more information, and browse the release notes to see the more than 300 patches that went into the release. You can even visit the press page.
Title: Re: Feature Request - Database relocation
Post by: RichardP on February 08, 2008, 03:39:12 am
LOL;    Thom

I will leave that one up to the project manager.   But it is good food for thought.  Replication and a pile of other features you need in a commercial DBMS are free/open source in Postgresql.   What is your favourite flavour of crack?

What a can of worms this seems to have opened - seems to have hit a nerve somewhere. When it comes to LAMP-type projects, MySQL is (arguably) the most popular choice even though PostgreSQL is available. This is usually because MySQL is smaller, quicker (in development and runtime) and simpler. That choice comes with a tradeoff - you are giving up the scalability and other features. Put yourself in the shoes of someone starting out on a project and weighing up the possibilities. PostgreSQL has good support for transactions and MySQL has only basic support, but if I use PostgreSQL and use transactions, the project will take 20% longer. It's like you say - what flavour of crack do you prefer. In most cases, the Project Leader knows exactly what he is giving up, but is happy to give them up in return for what he is gaining. However, if the application an enterprise-wide commercial application that absolutely must have the sort of features that SQL-Server and Oracle offer, then MySQL goes out the window and PostgreSQL sits higher on the list of candidates.

When a project is under way, though, like this one, changing comes at a very high cost. Changing DB means months of work, only to find at the end of it that you haven't moved an inch in terms of new features.

Best Regards,
Richard.
Title: Re: Feature Request - Database relocation
Post by: colinjones on February 09, 2008, 08:52:05 am
LOL;    Thom

I will leave that one up to the project manager.   But it is good food for thought.  Replication and a pile of other features you need in a commercial DBMS are free/open source in Postgresql.   What is your favourite flavour of crack?

What a can of worms this seems to have opened - seems to have hit a nerve somewhere. When it comes to LAMP-type projects, MySQL is (arguably) the most popular choice even though PostgreSQL is available. This is usually because MySQL is smaller, quicker (in development and runtime) and simpler. That choice comes with a tradeoff - you are giving up the scalability and other features. Put yourself in the shoes of someone starting out on a project and weighing up the possibilities. PostgreSQL has good support for transactions and MySQL has only basic support, but if I use PostgreSQL and use transactions, the project will take 20% longer. It's like you say - what flavour of crack do you prefer. In most cases, the Project Leader knows exactly what he is giving up, but is happy to give them up in return for what he is gaining. However, if the application an enterprise-wide commercial application that absolutely must have the sort of features that SQL-Server and Oracle offer, then MySQL goes out the window and PostgreSQL sits higher on the list of candidates.

When a project is under way, though, like this one, changing comes at a very high cost. Changing DB means months of work, only to find at the end of it that you haven't moved an inch in terms of new features.

Best Regards,
Richard.


Richardp - I think the point is moot. Powrrrplay is incorrect saying that MySQL is not open source. It is, it is GNU GPL. Both Community and Enterprise - and they share a common code-base, Enterprise server is more about support and guaranteed updates, moving to another database isn't even relevant. As to the other comment about now that Sun own it, look out for coming changes. This is unnecessarily cynical and unrealistic anyway. Even if Sun decided to close the source and start charging for the product - highly unlikely, this isn't necessary for the company to make money, they already are from the support subscription - the existing and previous versions are still GNU GPL, with millions of installations worldwide and many more devs involved, the existing version would simply be forked and continue independent development.
Title: Re: Feature Request - Database relocation
Post by: PowrrrPlay on February 10, 2008, 09:52:56 pm
Ok, I will drop the postgresql thing.  The rhetoric is getting out of control and not what this post is about, so lets just agree to disagree.

So, the original question, database relocation.  Is that a viable request?  I want database relocation/separation from the core OS.

Title: Re: Feature Request - Database relocation
Post by: royw on February 11, 2008, 12:52:24 am
I did a google on "moving mysql database" and found what looks like good instructions:

  http://www.vbulletin.com/forum/showthread.php?t=185701 (http://www.vbulletin.com/forum/showthread.php?t=185701)

I'd suggest giving it a try and if it works, create a lmce specific howto on the wiki...

HTH,
Roy
Title: Re: Feature Request - Database relocation
Post by: PowrrrPlay on February 11, 2008, 04:05:17 pm
tschak909, I am laughing because the admin or somebody with authority is removing my posts.  Nice community.
Title: Re: Feature Request - Database relocation
Post by: hari on February 11, 2008, 06:51:02 pm
tschak909, I am laughing because the admin or somebody with authority is removing my posts.  Nice community.
talked to the other devs.. nobody deleted your post. Maybe you hit the delete link by mistake?

If you don't like our community, nobody forces you to take part.

best regards,
Hari
Title: Re: Feature Request - Database relocation
Post by: RichardP on February 12, 2008, 01:47:44 am
tschak909, I am laughing because the admin or somebody with authority is removing my posts.  Nice community.

Could it be that you're not using the Post button after you Preview?
Title: Re: Feature Request - Database relocation
Post by: Zaerc on February 12, 2008, 01:50:17 am
tschak909, I am laughing because the admin or somebody with authority is removing my posts.  Nice community.
That would very much surprise me as well as I've never seen a post or thread just disappear before, and trust me I have said some things before that were pretty damn rude (and in all honesty: not always called for).  At most threads get deleted or locked by the person who started the thread.  Never saw a single complaint about missing posts before either.  So I also think you are mistaken, no offence intended. 
Title: Re: Feature Request - Database relocation
Post by: PowrrrPlay on February 12, 2008, 05:53:46 pm
RichardP/Zaerc;

Was not sure what was happening after a post disappeared and then all the flaming started. Thank you for the professional response. My other comments come from years of experience and I was just trying to convey my concerns for such a young aggressive project.

Royw:  Good information, thank you.  I will be spending more time dissecting MCE and its components.  Just trying to avoid some "got-yah's".

Cheers.
Title: Re: Feature Request - Database relocation
Post by: RichardP on February 13, 2008, 03:23:44 am
In order for the database to be relocatable, there needs to be, in LMCE, a single configuration file which points to the DB location, and from which all other scripts get the DB location when then need to access the DB. Does anyone know if this is how it is done?
If any of the scripts hold the DB location within them, then this will be a larger task than simply moving the database.
Title: Re: Feature Request - Database relocation
Post by: royw on February 13, 2008, 08:25:42 am
In order for the database to be relocatable, there needs to be, in LMCE, a single configuration file which points to the DB location, and from which all other scripts get the DB location when then need to access the DB. Does anyone know if this is how it is done?
If any of the scripts hold the DB location within them, then this will be a larger task than simply moving the database.

First, I'm not a db kind of guy, but I've been forced (kicking and screaming) to use them occasionally.   ;)

LMCE is using mysql.  Mysql runs as a daemon.  When mysql daemon is started, it reads it's configuration from /etc/mysql/my.cnf.  On LMCE 0710B3, my.cnf has datadir = /var/lib/mysql.  Looking in /var/lib/mysql you will notice directories that correspond to the various databases.

Scripts, programs, etc, should not be overriding my.cnf (that's a no no).  Also they should never access the files directly (that's a big NO NO).

During my, admittedly limited, browsing of the source, I've seen just the expected mysql connection calls.

When you use a database, you open a connection, do your queries, then close the connection.  When you open the connection, you actually query the daemon for a handle.  This handle is then passed to the daemon with each of your db calls (queries).  So you never know (nor need to know) the physical location of the data on disc.  So moving the location of the database should be transparent to all applications.

The primary concern I would have is LMCE's bad habit of "restoring" config files.  I have not found any list of the files that LMCE expects you not to mess with.  I know from experience that LMCE "restores" domainname (to "pluto") and from the forum it apparently does not play nice with xorg.conf.  I would suggest doing an innocent change to my.cnf, rebooting, then see if my.cnf was "restored" or not...

If you are really concerned about messing something up by moving the database, then why not just mount your raid partition on /var/lib/mysql?  The only config change would be adding the mount to /etc/fstab.  Simply create your partition, format it, mount it somewhere temporary, stop mysql daemon, copy /var/lib/mysql/* to it (preserving permissions, ownership,...), then umount it and remount it on /var/lib/mysql, and restart the mysql daemon.

HTH,
Roy


Have fun,
Roy
Title: Re: Feature Request - Database relocation
Post by: RichardP on February 14, 2008, 07:40:35 am
LMCE is using mysql.  Mysql runs as a daemon.  When mysql daemon is started, it reads it's configuration from /etc/mysql/my.cnf.  On LMCE 0710B3, my.cnf has datadir = /var/lib/mysql.  Looking in /var/lib/mysql you will notice directories that correspond to the various databases.

Scripts, programs, etc, should not be overriding my.cnf (that's a no no).  Also they should never access the files directly (that's a big NO NO).

During my, admittedly limited, browsing of the source, I've seen just the expected mysql connection calls.


I was thinking of a different problem. When you use a DB from a script, you open a connection to a DB to access tables, stored procedures and the like. You open a connection by specifying the server (like 192.168.80.1 or localhost or dcerouter.com) and a DB name.

Lets say LMCE opens a connection to a the DB from 50 different scripts. The three possibilites are:

Can you see the problem we will face if LMCE does not already follow the first option? Moving the DB will have a lot of scripts breaking if they assume the Servername and DB Name

Best Regards,
Richard.

Title: Re: Feature Request - Database relocation
Post by: royw on February 14, 2008, 10:15:16 am
Ah, but you are moving the database location on the core, we are not talking about moving the daemon (server).  The servername for all the scripts and programs is the core, whether it is referenced as 127.0.0.1, core_ip_address (ex, 192.168.80.1), localhost, or dcerouter.  All the scripts and programs then talk to the daemon running on the core.  The daemon then handles the physical location stuff behind the scenes.

In other words the database daemon IS the central point, i.e., your first option.

Also what we've been talking about is moving the location of ALL the databases (/etc/mysql/my.cnf:datadir).  So again, not an issue to the clients, just the daemon.

HTH,
Roy
Title: Re: Feature Request - Database relocation
Post by: colinjones on February 14, 2008, 01:37:43 pm
Yes, would only be an issue if you wanted to move the MySQL off to a completely different computer. Otherwise the server/db names/tables/ports etc all stay the same...
Title: Re: Feature Request - Database relocation
Post by: Zaerc on February 14, 2008, 11:26:48 pm
Nobody found /etv/pluto.conf yet?

# Pluto config file
MySqlHost = localhost
MySqlUser = root
MySqlPassword =
MySqlDBName = pluto_main
MySqlPort = 3306
...

Oh darn, now everybody knows I don't have a root password on my database. ;)
Title: Re: Feature Request - Database relocation
Post by: Matthew on February 16, 2008, 08:05:09 pm
Ok, I will drop the postgresql thing.  The rhetoric is getting out of control and not what this post is about, so lets just agree to disagree.

There are other good reasons for running LMCE on Postgres rather than MySQL. One good reason is if the site already runs Postgres, and adding LMCE's database to it would allow integrating other apps that aren't part of LMCE right at the data tier, with joins etc.

One technique could be to use DB-Link/DBI-Link (http://www.google.com/search?q=db-link+mysql+postgresql) to let a MySQL DB (local or networked) just front for a Postgres DB that actually contains the data.

But the SQL code in LMCE that I've seen doesn't expoit any specific MySQL features. A developer could just switch the /etc/pluto.conf and DSN strings to point directly at a Postgres DB with the same schema as the MySQL one, then regression test to be sure everything still works.
Title: Re: Feature Request - Database relocation
Post by: hari on February 16, 2008, 08:53:24 pm
But the SQL code in LMCE that I've seen doesn't expoit any specific MySQL features. A developer could just switch the /etc/pluto.conf and DSN strings to point directly at a Postgres DB with the same schema as the MySQL one, then regression test to be sure everything still works.
sqlCVS does.. And some other pieces use e.g. "show tables"..

best regards,
Hari
Title: Re: Feature Request - Database relocation
Post by: RichardP on February 18, 2008, 01:19:10 am
Ah, but you are moving the database location on the core, we are not talking about moving the daemon (server).  The servername for all the scripts and programs is the core, whether it is referenced as 127.0.0.1,

You may be leaving the server in the same location, but I'm not  ;D

I'd like to have the DB running on a server which is already running both MySQL and PostgreSql, and which already has a both a tape drive and a backup plan running. Makes my maintenance easier, and also means I can nuke my system without hesitation when upgrading either software or hardware. I realise this is not for everyone, though.

Best Regards,
Richard.
Title: Re: Feature Request - Database relocation
Post by: Matthew on February 18, 2008, 02:41:30 am
Ah, but you are moving the database location on the core, we are not talking about moving the daemon (server).  The servername for all the scripts and programs is the core, whether it is referenced as 127.0.0.1,

You may be leaving the server in the same location, but I'm not  ;D

I'd like to have the DB running on a server which is already running both MySQL and PostgreSql, and which already has a both a tape drive and a backup plan running. Makes my maintenance easier, and also means I can nuke my system without hesitation when upgrading either software or hardware. I realise this is not for everyone, though.

It might not be for everyone, but neither am I ;). Let me know how it goes, and if you want to collaborate on the switchover. Especially if you want to work on some way to base LMCE's data in Postgres, whether or not you keep MySQL. That's what I want too, but I can't prioritize working on it directly.
Title: Re: Feature Request - Database relocation
Post by: cybernard on May 07, 2008, 06:12:38 pm
*****Before dumping bring the database offline so no one can use it.*****
Otherwise you may have doom and disaster
I recommend unplugging the cable from all NIC(s) during the mysqldump process.
I assume NO LIABILITY of any kind, but I have done this before for other programs.

LinuxMCE PC

mysqldump -c -u <username> -p <database name>  >/path-of output/linuxmce-backup.sql
Obviously you need to supply valid credentials including password.

There is a command line switch to dump all databases, but I forgot what that was try mysqldump --help.
(something like --all-databases)

You may/or may not have to add "connect <database name>;" as the first line of code.  If you use the all switch you won't have to, but if you use the "all" you could wipe out existing username and passwords if your not careful.  ***If both systems have a user joe some of the data could be overlayed especially the password.**
***Other bad things can occur****

copy linuxmce-backup.sql to your other machine.

I also recommend(strongly!!) using the same procedure to back up your other database in case something goes horribly wrong.

You need to find and use the "all database" switch for your original database, on the destination pc, because that will backup usernames,passwords, and permissions.

Destination PC

EITHER
mysqldump -c -u <username> -p <database name>  >/path-of output/orginal-db-on-destination-pc.sql
OR (better)
mysqldump -c -u <username> -p --all-databases  >/path-of output/orginal-db-on-destination-pc.sql

Using the same steps with a different filename.


Now hopefully you backed up both of them in case of disaster.
No backup=No recovery



mysql -u <username> -p <database name> /path-to existing file/linuxmce-backup.sql
If your doing all you omitted the database name.

Specify credentials and wait for the process to complete.

If something goes horribly wrong you'll be glad you backed up.
---In case of doom as disaster:----------
mysql -u root -p
delete each affect database one at a time
commit;
exit or bye I forget which.
mysql -u root -p <database name> </path-of output/orginal-db-on-destination-pc.sql
Specify credentials and wait for the process to complete.
You are now restored
---End of doom and disaster---------------

I have no idea where the setting is located, but all thats left is to change the IP address that LinuxMCE is trying to connect to from localhost to the ip address of your other machine and your done.
Assuming you found this location you and now migrated.
Title: Re: Feature Request - Database relocation
Post by: hari on May 09, 2008, 08:22:09 pm
I have no idea where the setting is located, but all thats left is to change the IP address that LinuxMCE is trying to connect to from localhost to the ip address of your other machine and your done.
Assuming you found this location you and now migrated.


good one ;)

*LMAO*
Title: Re: Feature Request - Database relocation
Post by: cybernard on May 12, 2008, 10:09:12 pm
If you can't find the setting, use iptables to generate a NAT rule to foward the traffic.  If you don't know iptables use Firewall builder(30 day trail ediition) from fwbuilder.com to generate the necessary rules yourself the necessary iptable's settings through a nice windows GUI.  Route any "source" with 127.0.0.1 as the destination and 3306 as the service to the ip address of the new database with the original service.  Then save and compile.  You will get a .fw file which you can execute in a terminal window on your LinuxMCE box.  The script will have to be executed upon any reboot of the box.