The problems with geographically distributing WordPress, as you'll see, all revolve around the MySQL database.
There are basically two ways to architect this:
In this architecture, you run your LAMP frontend with WordPress in several geographic locations, each of which has a read-only replica (slave) of the master MySQL database. You will need to use something like MySQL Proxy to direct write operations back to the master, as WordPress doesn't natively support using a different database connection for reads versus writes.
The big problem with this setup is that if your master goes down, you can't make changes (e.g. no new posts or comments). So the master should probably be clustered or otherwise protected (e.g. using Amazon RDS Multi-AZ). Database writes are also delayed slightly due to network latency between the LAMP frontend and the remote MySQL master.
In this architecture, you run your LAMP frontend with WordPress in several geographic locations, each of which has a multi-master replicated database, using something like MariaDB Galera or an equivalent MySQL solution (if you can find one). You need to have at least three masters if you go this route.
As there's no single point of failure, it really doesn't matter if one master goes down (so long as they don't ALL go down at the same time; that situation requires manual intervention to recover).
The problem with this is that writes take much longer, as they have to be replicated to all of the multiple masters. So people may notice a few seconds' delay when doing anything that writes to the DB, such as commenting or writing a new post. In practice, this delay isn't that significant, as users already expect delays when they submit information in these contexts.
If you have three or more geographic locations you're going to deploy to, I'd go ahead and spend the effort to go multi-master. If you only have two locations, you can get by with a read replica and proxy for now.