how to set up w/ two app server 'n one database server?
I went through the library in regards to high available server set up.
the link down below discusses high available web application set up.
However, I would like to separate the database to a third linode. And also, set up the app servers with nginx.
I was thinking of using the above link as a reference, and for database I thought about using stand alone database library link.
It seems it should be pretty straight forward. However, I wonder if there would be write, read issues with data server on mysql.
Any suggestions, constructive criticism welcome.
Thank you.
8 Replies
@superdupler:
the link down below discusses high available web application set up.
http://library.linode.com/linux-ha/ip-f … untu-10.04">http://library.linode.com/linux-ha/ip-failover-heartbeat-pacemaker-drbd-mysql-ubuntu-10.04
That's really more for running mysql on two nodes with failover. What it sounds like you're looking for isn't failover, but instead a load balanced cluster.
I was wondering if there would be any issues as far as read and write on the database… I guess the best set up - two load balancer, two app, and two data servers. However, right now for my purposes it is way overkill.
any suggestions welcome
See the 3rd example here:
What is the maximum amount of app servers possible on this 'node balancer' set up?
Lets say… when the site gets a high load, would you be able to add 5 app servers? Or even be able to go up to 10 app servers? And all along use only one data server.
MySQL does have a limit to how many connections it can handle simultaneously. Each additional connection uses a little more memory, so it is a tunable parameter.
There's also a practical limit to how much stuff a single MySQL server can do simultaneously: if you're using MyISAM and have a write-heavy database, you're going to be lucky to get one application server working well. But, with InnoDB, few writes, well-designed indexes and queries, and perhaps a layer of caching to take care of the most-common data needs, it'll hum along nicely.
> with InnoDB, few writes, well-designed indexes and queries, and perhaps a layer of caching to take care of the most-common data needs
what do you mean by well-designed indexes and queries?
does 'a layer of caching' means caching queries?
@superdupler:
so linode caps out on 5,000 concurrent connections?
The basic NodeBalancer plan caps out at 5,000 concurrent connections. However, there's no hard connection limit on a Linode, but the kernel and your applications might have limits.
> what do you mean by well-designed indexes and queries?
You typically query a database using SQL, and how the query is designed can drastically change the amount of time it takes to run. Most SQL databases also support indexes, which are somewhat like the index in the back of a book: instead of scanning through an entire book looking for the word 'gazpacho', an index tells the database that the word 'gazpacho' appears in a specific place.
Query design and indexing and SQL server tuning are an art, and they are quite application-specific. They're also the sort of thing that you don't want to optimize prematurely: it doesn't make much sense to shave 50 milliseconds off of a query that, as it turns out, only happens twice a day.
> does 'a layer of caching' means caching queries?
Or the results from them, at least. If you have queries like SELECT content FROM articles WHERE slug = 'slug-futures-skyrocket', you can save your database some work by using something like memcached to store the results for quick retrieval later on. Most decent frameworks handle this for you; there's a few rather interesting problems.
Another thing I forgot to mention originally: if you have two application servers and one of them dies, you're OK, because you have a second one. If you have one database server and it dies, you're SOL until it comes back. So, be aware that it's not a high-availability setup, just a load-balancing one.