I''m designing a new Railsapplication that needs to offer high availability. With Rails, we are already getting scalability out of the box. We are considering using a Kemp LM1500 hardware load balancer to manage requests to our Rails application servers. There will be a separate server running MySQL 5.0 and all Rails application servers will be accessing this. I''ve been considering a couple of different alternatives for MySQL fault tolerance. MySQL clustering seems too complicated and still not 100% bulletproof. The other alternative is to create a MySQL Warm Standby using frequent transaction log backups and a monitor to detect when to fail over. Has anyone done something like this before and if so, can you offer any advice? Regards, -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
> I''m designing a new Railsapplication that needs to offer high > availability. With Rails, we are already getting scalability out of the > box. > > We are considering using a Kemp LM1500 hardware load balancer to manage > requests to our Rails application servers. There will be a separate > server running MySQL 5.0 and all Rails application servers will be > accessing this. I''ve been considering a couple of different alternatives > for MySQL fault tolerance. MySQL clustering seems too complicated and > still not 100% bulletproof. The other alternative is to create a MySQL > Warm Standby using frequent transaction log backups and a monitor > to detect when to fail over. > > Has anyone done something like this before and if so, can you offer any > advice?We''re using their NDB cluster right now. It works pretty well, but has some big caveats in terms of overall DB size, row size, limitations in numbers of inserts/updates per transaction, etc... I think if Rails supported the concept of a write_db and a read_db we would have simply gone with a single master with multiple slaves, but it doesn''t so we didn''t. If one server is enough for your needs, I would simply setup another server as a slave, then use whatever is necessary to cut over when the master fails. -philip --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
On Oct 31, 2006, at 9:25 AM, Jim Dandy wrote:> I''m designing a new Railsapplication that needs to offer high > availability. > With Rails, we are already getting scalability out of the box.Hello Jim.> We are considering using a Kemp LM1500 hardware load balancer to > manage > requests to our Rails application servers.If you want true HA, you need TWO load balancers.> There will be a separate server running MySQL 5.0 and all Rails > application > servers will be accessing this. I''ve been considering a couple of > different > alternatives for MySQL fault tolerance. MySQL clustering seems too > complicated > and still not 100% bulletproof.It also doesn''t allow for schema changes while online. :-(> The other alternative is to create a MySQL Warm Standby using frequent > transaction log backups and a monitor to detect when to fail over.Yes. This is a good solution, and MySQL can replicate online in near real time. In many cases, you can also read-balance across the master and/or replicas as well. -- -- Tom Mornini, CTO -- Engine Yard, Ruby on Rails Hosting -- Reliability, Ease of Use, Scalability -- (866) 518-YARD (9273) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
>> We are considering using a Kemp LM1500 hardware load balancer to >> manage >> requests to our Rails application servers. > > If you want true HA, you need TWO load balancers. > >> There will be a separate server running MySQL 5.0 and all Rails >> application >> servers will be accessing this. I''ve been considering a couple of >> different >> alternatives for MySQL fault tolerance. MySQL clustering seems too >> complicated >> and still not 100% bulletproof. > > It also doesn''t allow for schema changes while online. :-(Actually it does... sort of... you just have to put it into "single node mode" and then make your change. But you can still serve requests while that happens... granted if you''re site falls flat with a single node, then the net affect is that yes, you have to take it offline :/ At least, that''s what our db guy does (or tells us he does :) -philip --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
On Oct 31, 2006, at 10:07 AM, Philip Hallstrom wrote:>>> We are considering using a Kemp LM1500 hardware load balancer to >>> manage >>> requests to our Rails application servers. >> >> If you want true HA, you need TWO load balancers. >> >>> There will be a separate server running MySQL 5.0 and all Rails >>> application >>> servers will be accessing this. I''ve been considering a couple of >>> different >>> alternatives for MySQL fault tolerance. MySQL clustering seems too >>> complicated >>> and still not 100% bulletproof. >> >> It also doesn''t allow for schema changes while online. :-( > > Actually it does... sort of... you just have to put it into "single > node > mode" and then make your change. But you can still serve requests > while > that happens... granted if you''re site falls flat with a single node, > then the net affect is that yes, you have to take it offline :/ > > At least, that''s what our db guy does (or tells us he does :)Interesting. I picked up a book from MySQL Press on MySQL Cluster, and on page 9, it lists inability to change schema while online as a limitation of MySQL cluster. I stand corrected, but am left wondering what that book meant by that comment. Perhaps this has been changed since the book was released? -- -- Tom Mornini, CTO -- Engine Yard, Ruby on Rails Hosting -- Reliability, Ease of Use, Scalability -- (866) 518-YARD (9273) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
>>> It also doesn''t allow for schema changes while online. :-( >> >> Actually it does... sort of... you just have to put it into "single >> node >> mode" and then make your change. But you can still serve requests >> while >> that happens... granted if you''re site falls flat with a single node, >> then the net affect is that yes, you have to take it offline :/ >> >> At least, that''s what our db guy does (or tells us he does :) > > Interesting. I picked up a book from MySQL Press on MySQL Cluster, > and on > page 9, it lists inability to change schema while online as a limitation > of MySQL cluster. > > I stand corrected, but am left wondering what that book meant by that > comment. Perhaps this has been changed since the book was released?Hrm... that''s a little vague, but I could see that being correct as well. We have three front end nodes. When we need to make a change we put it into single node mode (i don''t remember the exact command) which effectively disables two of the nodes. However that last one will still serve up requests. So, the database is still available, but the "cluster" isn''t really online.. If that makes any sense... --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---