Fabian Arrotin wrote:
On Tue, 2006-05-23 at 12:49 -0700, Dan Trainor wrote:
For the backend storage, it depends what's your budget ... :o) A minimal setup is to use nfs on a central server to host/share the same data across all your machines ... the problem in this config is that the nfs server becomes the single point of failure ... so why not using a simple heartbeat solution for 2 nfs servers acting as one and uses drdb between these 2 nodes for the replication ... Other method is to have a dedicate san with hba in each webservers but that's another budget ... :o)
Just my two cents ...
HI, Fabian -
I've been toying aroudn with both NFS and GFS, but NFS does leave me with a single point of failure. I'd rather not use something like drdb, however. I'm still researching GFS to see if it's a viable alternative for what I'm looking for.
Thanks! -dant
GFS can do the job, but in this case you should have a real shared storage to permit all the servers to access the shared data in the same time ... If you don't want to invest a lot, you can still use iscsi but the single point of failure still exists ...
It tends to be expensive to do away with all points of failure. The best you can do on a budget is try to limit your points of failure to things that tend to have a long lifespan (i.e. almost anything other than servers and individual hard drives).
For another (relatively) low-cost option, check out the AoE storage appliances from Coraid.com. Mine is still in testing, but it was very easy to configure with CentOS4 and I haven't found any problems with it so far. I currently have a 1.2TB storage area shared between three CentOS servers with GFS.
From what I have learned reading. What do people think about using heart beat between two boxes, rsync to sync the www directories and other files, and use mysql replication?
My only question is I have found in the system that I setup with mysql replication it worked great but if you remove one of the servers and put it back in you have to stop mysql and copy over the newer database and then restart both to get it to replicate correctly.
Is there a way to get replication to work so it will automatically sync the master and slave without having to stop and copy and restart?
Bowie Bailey wrote:
Fabian Arrotin wrote:
On Tue, 2006-05-23 at 12:49 -0700, Dan Trainor wrote:
For the backend storage, it depends what's your budget ... :o) A minimal setup is to use nfs on a central server to host/share the same data across all your machines ... the problem in this config is that the nfs server becomes the single point of failure ... so why not using a simple heartbeat solution for 2 nfs servers acting as one and uses drdb between these 2 nodes for the replication ... Other method is to have a dedicate san with hba in each webservers but that's another budget ... :o)
Just my two cents ...
HI, Fabian -
I've been toying aroudn with both NFS and GFS, but NFS does leave me with a single point of failure. I'd rather not use something like drdb, however. I'm still researching GFS to see if it's a viable alternative for what I'm looking for.
Thanks! -dant
GFS can do the job, but in this case you should have a real shared storage to permit all the servers to access the shared data in the same time ... If you don't want to invest a lot, you can still use iscsi but the single point of failure still exists ...
It tends to be expensive to do away with all points of failure. The best you can do on a budget is try to limit your points of failure to things that tend to have a long lifespan (i.e. almost anything other than servers and individual hard drives).
For another (relatively) low-cost option, check out the AoE storage appliances from Coraid.com. Mine is still in testing, but it was very easy to configure with CentOS4 and I haven't found any problems with it so far. I currently have a 1.2TB storage area shared between three CentOS servers with GFS.
I guess that wouldn't work for load balancing though
Mace Eliason wrote:
From what I have learned reading. What do people think about using heart beat between two boxes, rsync to sync the www directories and other files, and use mysql replication?
My only question is I have found in the system that I setup with mysql replication it worked great but if you remove one of the servers and put it back in you have to stop mysql and copy over the newer database and then restart both to get it to replicate correctly. Is there a way to get replication to work so it will automatically sync the master and slave without having to stop and copy and restart?
Bowie Bailey wrote:
Fabian Arrotin wrote:
On Tue, 2006-05-23 at 12:49 -0700, Dan Trainor wrote:
For the backend storage, it depends what's your budget ... :o) A minimal setup is to use nfs on a central server to host/share the same data across all your machines ... the problem in this config is that the nfs server becomes the single point of failure ... so why not using a simple heartbeat solution for 2 nfs servers acting as one and uses drdb between these 2 nodes for the replication ... Other method is to have a dedicate san with hba in each webservers but that's another budget ... :o) Just my two cents ...
HI, Fabian -
I've been toying aroudn with both NFS and GFS, but NFS does leave me with a single point of failure. I'd rather not use something like drdb, however. I'm still researching GFS to see if it's a viable alternative for what I'm looking for. Thanks! -dant
GFS can do the job, but in this case you should have a real shared storage to permit all the servers to access the shared data in the same time ... If you don't want to invest a lot, you can still use iscsi but the single point of failure still exists ...
It tends to be expensive to do away with all points of failure. The best you can do on a budget is try to limit your points of failure to things that tend to have a long lifespan (i.e. almost anything other than servers and individual hard drives).
For another (relatively) low-cost option, check out the AoE storage appliances from Coraid.com. Mine is still in testing, but it was very easy to configure with CentOS4 and I haven't found any problems with it so far. I currently have a 1.2TB storage area shared between three CentOS servers with GFS.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Tue, 23 May 2006 15:32:31 -0700 Mace Eliason meliason@shaw.ca wrote:
My only question is I have found in the system that I setup with mysql replication it worked great but if you remove one of the servers and put it back in you have to stop mysql and copy over the newer database and then restart both to get it to replicate correctly.
Is there a way to get replication to work so it will automatically sync the master and slave without having to stop and copy and restart?
This is only neccessary if somethign ugly happens to your binary logs so the syncing thread of mysql has nowhere to get the good data from. Usually this should not happen. I only had it hapen when I run out of disk space. I suggest you check your setup and mysql replication docs again.
Jure Pečar wrote:
On Tue, 23 May 2006 15:32:31 -0700 Mace Eliason meliason@shaw.ca wrote:
My only question is I have found in the system that I setup with mysql replication it worked great but if you remove one of the servers and put it back in you have to stop mysql and copy over the newer database and then restart both to get it to replicate correctly.
Is there a way to get replication to work so it will automatically sync the master and slave without having to stop and copy and restart?
This is only neccessary if somethign ugly happens to your binary logs so the syncing thread of mysql has nowhere to get the good data from. Usually this should not happen. I only had it hapen when I run out of disk space. I suggest you check your setup and mysql replication docs again.
Hi -
I, too, suggest this.
I have a setup which is similar to what you're going for, I think. The MySQL part utilizes master-master replication, or multi-master replication, which gives me a hot spare just in case. In the event that one of these machines fail, it is updated automagically when it comes back online, by it's "master".
MySQL has detailed this procedure pretty well. Take a look at it and see what you can find.
Thanks -dant
Hi,
Does this require you run a particular version of Mysql? I am running Mysql-4.1 using Mastr Slave replication. I really want to do the above described Mastr Mastr scenario.
-Rick Philbrick
On 5/24/06, Dan Trainor dan.trainor@gmail.com wrote:
Jure Pečar wrote:
On Tue, 23 May 2006 15:32:31 -0700 Mace Eliason meliason@shaw.ca wrote:
My only question is I have found in the system that I setup with mysql replication it worked great but if you remove one of the servers and put it back in you have to stop mysql and copy over the newer database and then restart both to get it to replicate correctly.
Is there a way to get replication to work so it will automatically sync the master and slave without having to stop and copy and restart?
This is only neccessary if somethign ugly happens to your binary logs so the syncing thread of mysql has nowhere to get the good data from. Usually this should not happen. I only had it hapen when I run out of disk space. I suggest you check your setup and mysql replication docs again.
Hi -
I, too, suggest this.
I have a setup which is similar to what you're going for, I think. The MySQL part utilizes master-master replication, or multi-master replication, which gives me a hot spare just in case. In the event that one of these machines fail, it is updated automagically when it comes back online, by it's "master".
MySQL has detailed this procedure pretty well. Take a look at it and see what you can find.
Thanks -dant _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Rick Philbrick wrote:
Hi,
Does this require you run a particular version of Mysql? I am running Mysql-4.1 using Mastr Slave replication. I really want to do the above described Mastr Mastr scenario.
-Rick Philbrick
On 5/24/06, Dan Trainor dan.trainor@gmail.com wrote:
Jure Pečar wrote:
On Tue, 23 May 2006 15:32:31 -0700 Mace Eliason meliason@shaw.ca wrote:
My only question is I have found in the system that I setup with mysql replication it worked great but if you remove one of the servers and put it back in you have to stop mysql and copy over the newer database and then restart both to get it to replicate correctly.
Is there a way to get replication to work so it will automatically sync the master and slave without having to stop and copy and restart?
This is only neccessary if somethign ugly happens to your binary
logs so the syncing thread of mysql has nowhere to get the good data from. Usually this should not happen. I only had it hapen when I run out of disk space.
I suggest you check your setup and mysql replication docs again.
Hi -
I, too, suggest this.
I have a setup which is similar to what you're going for, I think. The MySQL part utilizes master-master replication, or multi-master replication, which gives me a hot spare just in case. In the event that one of these machines fail, it is updated automagically when it comes back online, by it's "master".
MySQL has detailed this procedure pretty well. Take a look at it and see what you can find.
Thanks -dant
Hi -
Honestly, I've not started playing with MySQL until 5.0, and more recently, 5.1 - so I cannot answer that. However, this may be documented in MySQL's manual (or someone else might be able to chime in)
Thanks! -dant
On Wed, 24 May 2006 11:04:49 -0700 Dan Trainor dan.trainor@gmail.com wrote:
Honestly, I've not started playing with MySQL until 5.0, and more recently, 5.1 - so I cannot answer that. However, this may be documented in MySQL's manual (or someone else might be able to chime in)
Master-slave was kinda working back in the 3.23.5x days and is working ok in 4.0 and 4.1. Master-master is still new, introduced in 5.0 I belive and I haven't played with it yet.
Le Mercredi 24 Mai 2006 22:03, Jure Pečar a écrit :
On Wed, 24 May 2006 11:04:49 -0700
Dan Trainor dan.trainor@gmail.com wrote:
Honestly, I've not started playing with MySQL until 5.0, and more recently, 5.1 - so I cannot answer that. However, this may be documented in MySQL's manual (or someone else might be able to chime in)
Master-slave was kinda working back in the 3.23.5x days and is working ok in 4.0 and 4.1. Master-master is still new, introduced in 5.0 I belive and I haven't played with it yet.
Just a pointer to a interesting article/howto mentionned in the MySQL newsletter I just received: http://www.onlamp.com/pub/a/onlamp/2006/04/20/advanced-mysql-replication.htm...
Also an occasion to ask people to customize the subject when "digressing", so that both original poster and archive searchers find what they want more easily ;-)
TIA
Vincent Knecht wrote:
Le Mercredi 24 Mai 2006 22:03, Jure Pečar a écrit :
On Wed, 24 May 2006 11:04:49 -0700
Dan Trainor dan.trainor@gmail.com wrote:
Honestly, I've not started playing with MySQL until 5.0, and more recently, 5.1 - so I cannot answer that. However, this may be documented in MySQL's manual (or someone else might be able to chime in)
Master-slave was kinda working back in the 3.23.5x days and is working ok in 4.0 and 4.1. Master-master is still new, introduced in 5.0 I belive and I haven't played with it yet.
Just a pointer to a interesting article/howto mentionned in the MySQL newsletter I just received: http://www.onlamp.com/pub/a/onlamp/2006/04/20/advanced-mysql-replication.htm...
Also an occasion to ask people to customize the subject when "digressing", so that both original poster and archive searchers find what they want more easily ;-)
TIA _______________________________________________ CentOS mailing list CentOS@centos.org
That article is immensely helpful. I'm working on this right now for a pair of webservers and it seems to work well. I can't say yet how well it performs etc. as it's not in a live environment yet. I'm still testing and working on it.
Mike
__________ NOD32 1.1555 (20060524) Information __________
This message was checked by NOD32 antivirus system. http://www.eset.com
Vincent Knecht wrote:
Le Mercredi 24 Mai 2006 22:03, Jure Pečar a écrit :
On Wed, 24 May 2006 11:04:49 -0700
Dan Trainor dan.trainor@gmail.com wrote:
Honestly, I've not started playing with MySQL until 5.0, and more recently, 5.1 - so I cannot answer that. However, this may be documented in MySQL's manual (or someone else might be able to chime in)
Master-slave was kinda working back in the 3.23.5x days and is working ok in 4.0 and 4.1. Master-master is still new, introduced in 5.0 I belive and I haven't played with it yet.
Just a pointer to a interesting article/howto mentionned in the MySQL newsletter I just received: http://www.onlamp.com/pub/a/onlamp/2006/04/20/advanced-mysql-replication.htm...
Also an occasion to ask people to customize the subject when "digressing", so that both original poster and archive searchers find what they want more easily ;-)
TIA
Hi -
Ah, damn. I ran across that the other day, too - I should have thrown that out here myself. It's a very good article, and quite honestly is the best one on the subject that I've read.
Thanks -dant
Hi,
just check ndbd from MySQL, i tried it with " simple " table format. It's great but there are 2 major drawback.
1. it only supports a single table format which doesn't support foreign keys. ( for me this is problematic )
2. all the database is stored in ram so large data isn't welcome.
But other than that the project looks nice. Later
On Tuesday 23 May 2006 18:32, Mace Eliason wrote:
From what I have learned reading. What do people think about using heart beat between two boxes, rsync to sync the www directories and other files, and use mysql replication?
My only question is I have found in the system that I setup with mysql replication it worked great but if you remove one of the servers and put it back in you have to stop mysql and copy over the newer database and then restart both to get it to replicate correctly.
Is there a way to get replication to work so it will automatically sync the master and slave without having to stop and copy and restart?
Bowie Bailey wrote:
Fabian Arrotin wrote:
On Tue, 2006-05-23 at 12:49 -0700, Dan Trainor wrote:
For the backend storage, it depends what's your budget ... :o) A minimal setup is to use nfs on a central server to host/share the same data across all your machines ... the problem in this config is that the nfs server becomes the single point of failure ... so why not using a simple heartbeat solution for 2 nfs servers acting as one and uses drdb between these 2 nodes for the replication ... Other method is to have a dedicate san with hba in each webservers but that's another budget ... :o)
Just my two cents ...
HI, Fabian -
I've been toying aroudn with both NFS and GFS, but NFS does leave me with a single point of failure. I'd rather not use something like drdb, however. I'm still researching GFS to see if it's a viable alternative for what I'm looking for.
Thanks! -dant
GFS can do the job, but in this case you should have a real shared storage to permit all the servers to access the shared data in the same time ... If you don't want to invest a lot, you can still use iscsi but the single point of failure still exists ...
It tends to be expensive to do away with all points of failure. The best you can do on a budget is try to limit your points of failure to things that tend to have a long lifespan (i.e. almost anything other than servers and individual hard drives).
For another (relatively) low-cost option, check out the AoE storage appliances from Coraid.com. Mine is still in testing, but it was very easy to configure with CentOS4 and I haven't found any problems with it so far. I currently have a 1.2TB storage area shared between three CentOS servers with GFS.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Charles Lacroix wrote:
Hi,
just check ndbd from MySQL, i tried it with " simple " table format. It's great but there are 2 major drawback.
- it only supports a single table format which doesn't support foreign keys.
( for me this is problematic )
- all the database is stored in ram so large data isn't welcome.
MySQL 5.1 is supposed to support on-disk clusters. So you can have much larger databases in a cluster.
--Ajay
On Thursday 25 May 2006 01:03, Ajay Sharma wrote:
Charles Lacroix wrote:
Hi,
just check ndbd from MySQL, i tried it with " simple " table format. It's great but there are 2 major drawback.
- it only supports a single table format which doesn't support foreign
keys. ( for me this is problematic )
- all the database is stored in ram so large data isn't welcome.
MySQL 5.1 is supposed to support on-disk clusters. So you can have much larger databases in a cluster.
--Ajay _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Hi,
Will it support a better table format like myisam or innodb ? I havn't read on that yet but if it's a question of time i might get started with beta/alpha release to see how it goes :)
later
Hello List:
This is my first try to install CentOS 4.3 ia64. The motherboard is:
ECS Model K8M800-M2 Chipset VIAVT 8237
AMD 754Pin 3000+ CPU 512 DDR Memory
This MB has built-in Video. When I install 4.3 32 Bit OS, it installs fine. But when I try installing 64 Bit OS, it does not recognize the Video Card.
Any suggestions?
Kirti
On Sat, 2006-05-27 at 17:52 -0400, Kirti S. Bajwa wrote:
Hello List:
This is my first try to install CentOS 4.3 ia64. The motherboard is:
You mean CentOS 4.3 x86_64 right?
ECS Model K8M800-M2 Chipset VIAVT 8237
AMD 754Pin 3000+ CPU 512 DDR Memory
This MB has built-in Video. When I install 4.3 32 Bit OS, it installs fine. But when I try installing 64 Bit OS, it does not recognize the Video Card.
Any suggestions?
Hmmmm probably a S3 UniChrome video built-in ... never had luck getting it to work. I ended up putting an old Radeon 7200 in the box for GUI.
It's possible the FB driver might work, but it would be slow for performance.
Paul
You mean CentOS 4.3 x86_64 right?
Yes.
Hmmmm probably a S3 UniChrome video built-in ... never had luck getting it to work. I ended up putting an old Radeon 7200 in the box for GUI.
It's possible the FB driver might work, but it would be slow for performance.
Any other suggestion??
On Mon, 2006-05-29 at 09:07 -0400, Kirti S. Bajwa wrote:
You mean CentOS 4.3 x86_64 right?
Yes.
Hmmmm probably a S3 UniChrome video built-in ... never had luck getting it to work. I ended up putting an old Radeon 7200 in the box for GUI.
It's possible the FB driver might work, but it would be slow for performance.
Any other suggestion??
You can try using the vesa driver to get X initially working.
Edit the file /etc/X11/xorg.conf and look for the section for your video card. It should contain I line like this:
Identifier "Videocard0"
Change the driver line to:
Driver "vesa"
and see if that works for you.
On a somewhat related subject, besides Intel integrated graphics, are there any other supported by CentOS 4?
The only other I can think of might be the Radeon Mobility based ones.
I think the latest fedora supports the nVidia 6100 & 6150 based onboard graphics.
Regards, Paul Berger
On Mon, 2006-05-29 at 09:07 -0500, Johnny Hughes wrote:
On Mon, 2006-05-29 at 09:07 -0400, Kirti S. Bajwa wrote:
You mean CentOS 4.3 x86_64 right?
Yes.
Hmmmm probably a S3 UniChrome video built-in ... never had luck getting it to work. I ended up putting an old Radeon 7200 in the box for GUI.
It's possible the FB driver might work, but it would be slow for performance.
Any other suggestion??
You can try using the vesa driver to get X initially working.
Edit the file /etc/X11/xorg.conf and look for the section for your video card. It should contain I line like this:
Identifier "Videocard0"
Change the driver line to:
Driver "vesa"
and see if that works for you.