Multiple servers.

[MediaStar]

then how u update both website at the same time?

[Desi_Boy]

use cloudflare , ur website remain online if its goes down

[BattleDuty]

^^How?? I see "Site is offline".

[Desi_Boy]

http://www.cloudflare.com/plans , i think there is way or option because they mention in plans

[BattleDuty]

^^Thank you so much It's listed "always online" cache portion!

Sounds perfect.

EDIT: Wait, do users see captcha before entering the site?

[digitallifeseff]

afaik cloudflare it's only cache image and css.. not whole content... you can try reverse proxy..

[Lock Down]

This is what is normally used for keeping databases in sync with each other.
http://dev.mysql.com/doc/refman/4.1/...uster-faq.html
or
http://www.howtoforge.com/mysql_database_replication

The only problem I see with ns 1 & 2 being different servers is that if they are both used simutaneously than the second (replicated) could have more data then the master.

[damoncloudflare]

use cloudflare , ur website remain online if its goes down

Just a quick note that Always Online will not serve a full version of your site when your server is down. The Always Online feature also has some limitations.

---------- Post added at 02:48 PM ---------- Previous post was at 02:47 PM ----------

afaik cloudflare it's only cache image and css.. not whole content... you can try reverse proxy..

Always Online actually does cache a little html (Always Online is distinctly different from regular CloudFlare caching).

[snowmanrene]

If you're with OVH, they have a fail-over option as well for this exact purpose.

Simply put, to achieve it, the main server periodically back ups all data onto the second server and when the main server goes down, the "gateway/vps" will direct traffic to the second server. This way you can use the system to perform updates/maintenance/upgrades to the main server and still have the site remain online.

[Hotaru]

I have few expriences in this field. If you have less/or equal 4 servers, it's best to setup 1 instance of MySQL. More than 4 servers, 2 mysql run in replication mode (one master and many slaves). Why? In high traffic website (I'm talking hundreds thousands visits in day or more) MySQL use a lot of RAM and CPU, try to seperate it from PHP and WebServer for best performance.
If you have more than 2 web server, and one extra for mysql, use the extra one for load balancer. The best software load balancer out there is nginx. You can config nginx to balance the request to your 2 web servers. If one web server goes down, you still have the other.
Now, for MySQL. If you have mysql run in replication mode (means 1 master server, and many slave), config for each web server connect to different mysql server. Now, if you have only 2 mysql server (1 master & 1 slave), you can config you web server read from master. If you have more than 3 (1 master & 2 slaves), do not config your web server to read from master, only read from slave. Any modification operation happens to database (UPDATE, INSERT, DELETE) you will have to perform on the master, and those modifications will be mirrored to slave. If you perform modification operations on slave, it will not change the master and other slave, go figure.
Next thing is PHP Session. Now, you have more than 2 web servers, each one will give the client different session id, and (maybe) store different session data. So, we will have to store php session in one place. There are many ways to do that: file, mysql, memcached, redis... Now, forget the session to file solution, one reason: it sucks. Well, the easiest way is to store php session in mysql. But the best way is to store in memcached, which is lightning fast.

Memcached: http://pureform.wordpress.com/2009/04/08/memcache-mysql-php-session-handler/
MySQL: http://www.tonymarston.net/php-mysql/session-handler.html

Last word: there are many solution to scale a website, those things above i points out are just few, and I'm gladly to share my exprience.
And one more thing, in nginx load balancer, there are 2 ways to load balance between servers:
1. Equally divide: client make 5 requests to your webserver (assume you're load balancing between 3 web servers), load balancer will do like this: request 1 go to svr A, req 2 go to svr B, req 3 go to C, req 4 go to A, req 5 go to B. Pros: CPU + RAM load is balanced. Cons: different session.
2. Stay in one server: client 1 make 5 requests, load balancer forwards all request to svr A and all further request will go to svr A. Client 2 make requests, all will go to svr B. Pros: no session problems. Cons: one svr may have more stress than the others, and when one go down, one other svr will take all the stress from the down svr, and there will be a chain reaction.