{"id":6321,"date":"2020-03-18T15:09:38","date_gmt":"2020-03-18T08:09:38","guid":{"rendered":"http:\/\/gcloudvn.wam.vn\/kien-truc-du-phong-tham-hoa-co-so-du-lieu-da-vung-cho-mysql\/"},"modified":"2023-04-24T16:41:46","modified_gmt":"2023-04-24T09:41:46","slug":"kien-truc-du-phong-tham-hoa-co-so-du-lieu-da-vung-cho-mysql","status":"publish","type":"post","link":"https:\/\/gcloudvn.com\/en\/kienthuc\/kien-truc-du-phong-tham-hoa-co-so-du-lieu-da-vung-cho-mysql\/","title":{"rendered":"Multi-Region Database Disaster Redundancy Architecture for MySQL"},"content":{"rendered":"

Enterprises expect high reliability of the data storage infrastructure their applications are using. Although you and your team prepare the best technical scenarios, carefully, there is still a risk of database failure, whether the server or network partition fails or not. Good planning can help you respond to problems and recover faster when disaster strikes.<\/span><\/p>\n

This blog shows a database architecture implementation approach that ensures high resiliency and disaster recovery for MySQL on Compute Engine<\/a>, using sector disks as well as load balancers.<\/span><\/p>\n

Any database architecture should have approaches in place for error recovery and rapid recovery from failure without data loss. These methods are demonstrated in the RTO (recovery time objective) and RPO (recovery point objective), which provide ways to set up and then measure how long the service may be unavailable and save the data to be saved. how far.<\/span><\/p>\n

When a database fails, they should be recovered as quickly as possible with as small an RTO as possible, ideally within seconds. It takes as little data as possible, not even at all. The desired RPO is the final consistent database state.<\/span><\/p>\n

From a database architecture and implementation design, this can be done with two distinct concepts: high availability and disaster recovery. Use both at the same time to achieve an architecture that prepares for the greatest range of failures or failures.<\/span><\/p>\n

Create a flexible database architecture<\/strong><\/h3>\n

A high availability database architecture has database servers in at least two or more regions. If a server on one region fails or the zone becomes inaccessible, data in other regions is also available for further processing. The figure below shows two cases, one in the zn1 region and the other in the zn2 region. The front-end load balancer assists in directing traffic to a 'healthiest' database available for read and write queries.<\/span><\/p>\n

A disaster recovery architecture adds a second highest availability database setup in the second area. If one of the zones becomes inaccessible or fails, the other is immediately put into use. The figure below shows two areas, the main area and the DR (disaster recovery) area. Data is copied from the primary to the DR zone so that the DR zone can take over from the latest consistent database state. The load balancer in front of the zones directs traffic to the zone responsible for read and write traffic. Here's how this architecture looks like:<\/span><\/p>\n

\"Multi-Region<\/p>\n

In addition to setting up the database servers, it is also necessary to implement a regional drive that is written to two zones simultaneously, to ensure safety in case of failure in any region. there. This is a huge advantage of Google Cloud, allowing you to bypass MySQL-level replication in a region. Each disk write operation is performed synchronously in two regions. When the primary server fails, a backup server is attached to the disk(s) in the region, and the database service (MySQL) is then similarly started. This gives the peace of mind of not worrying about replication latency or database state for high availability.<\/span><\/p>\n

From a disaster recovery process perspective, the following things happen over time when something goes wrong:<\/span><\/p>\n