Shulou(Shulou.com)05/31 Report--

This article will explain in detail how to prevent GitHub from being cut off for 43 seconds and paralyzed for 24 hours, so the content of the article is of high quality, so the editor will share it for you as a reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

The main culprit that paralyzed the network for 43 seconds and 24 hours was the database. Because the database clusters deployed in the two data centers are not synchronized in real time. At the time of the accident, Github engineers were afraid to safely switch the primary database to a backup data center on the East Coast because of data loss.

Programmers left messages under GitHub's confession to express their "condolences" to the database cluster. But more IT practitioners are concerned about how to prevent such a disaster from befalling their own companies and maintaining their own systems.

Ant Financial Services Group OceanBase distributed database experts believe that the Github event is a typical city-level failure. If the system adopts a highly available three-place and five-center solution, it can deal with it freely.

Just a month ago, at this year's Hangzhou Yunqi Congress, Hu Xi, deputy CTO of Ant Financial Services Group, simulated cutting nearly half of Alipay's server fiber optic cables. In only 26 seconds, Alipay in the simulated environment completely returned to normal, which is the self-healing ability of OceanBase city-level faults.

It turns out that Github is similar to the traditional database two-place and three-center model adopted by banks, that is, "main database (main computer room) + hot backup database in the same city (hot backup computer room in the same city) + remote disaster preparedness database (remote disaster preparedness computer room)". In this way, only the server in the main computer room can provide write service. If there is a city-level failure in the main city, the database of the disaster recovery city can work, but because there is no synchronous up-to-date data, the data of the disaster recovery database is damaged.

However, under the deployment of three places and five centers, any single city failure, OceanBase will not stop service, and there will be no loss of data.

Github says it has to sacrifice recovery time to ensure data integrity. In fact, the proposal of "three places and five centers" can better deal with this problem. In case of urban failure, OceanBase can provide normal service without any data loss as long as the three computer rooms in the two living cities can communicate with each other.

On how to avoid GitHub as 43 seconds paralyzed 24 hours to share here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.