A typical (single-server) database keeps all information in one location (eg Mumbai).
You could add a read replica in another region (eg Ohio). This would replicate information to Ohio, but the replica in Ohio could only be used for querying (reading) data. All updates would need to be made to the primary database in Mumbai. This makes querying faster without needing "multiple masters".
From Working with Amazon Aurora Global Database:
An Aurora global database consists of one primary AWS Region where your data is mastered, and up to five read-only, secondary AWS Regions. Aurora replicates data to the secondary AWS Region with typical latency of under a second. You issue write operations directly to the primary DB instance in the primary AWS Region. An Aurora global database uses dedicated infrastructure to replicate your data, leaving database resources available entirely to serve application workloads. Applications with a worldwide footprint can use reader instances in the secondary AWS Regions for low latency reads. In the unlikely event your database becomes degraded or isolated in an AWS region, you can promote one of the secondary AWS Regions to take full read-write workloads in under a minute.
The Aurora cluster in the primary AWS Region where your data is mastered performs both read and write operations. The cluster in the secondary region enables low-latency reads. You can scale up the secondary clusters independently by adding one of more DB instances (Aurora Replicas) to serve read-only workloads. For disaster recovery, you can remove and promote one of the secondary clusters to allow full read and write operations.
Going one step further, you could Work with Amazon Aurora Multi-Master Clusters where all DB instances have read-write capability:
In a multi-master cluster, all DB instances can perform write operations. The notions of a single read-write primary instance and multiple read-only Aurora Replicas don't apply. There isn't any failover when a writer DB instance becomes unavailable, because another writer DB instance is immediately available to take over the work of the failed instance. We refer to this type of availability as continuous availability, to distinguish it from the high availability (with brief downtime during failover) offered by a single-master cluster.
Each option is a trade-off between performance, cost and complexity. It is highly likely that a Read Replica or Global Database will be sufficient for your needs, because most database operations are queries rather than updates.
You should experiment with each option and run performance tests on your application to confirm that you are achieving your desired performance. Also, review the associated costs (which will likely double due to having multiple servers, plus there will be additional costs for Data Transfer between the two regions).
Also, please note that the above capabilities will differ depending upon the database engine you choose. (The above are for Amazon Aurora running MySQL.)
