caused by databases at that time. Analysis of those troubles revealed the
following two major problems.:
• First, the number of people who were familiar with the databases in the company
was limited. When a failure occurred, they spent too much time resolving the
trouble because they didn't know the details of the database, which was like a
“Black box.”
• Second, KDDI didn't have enough resources to check every item entrusted to SI
partners and keep the quality of database to a high level because KDDI had many
SI partners whose skills with databases were different, and this caused the first
problem as well.
• KDDI DBA Secretariat created a basic policy on quality control for the databases of
about 1,000 systems that exist in the company, and believed that two database
management and operational policies were needed.
• One is a system managed individually and totally like the “F1 machine.” The
database supporting various telecommunication services, which is KDDI's core
business, requires a platform with higher performance and availability, such as
Oracle Exadata Database.
• The other is a system generalized and integrated, such as “a mass‐produced car.”
It was difficult to estimate the future workload of databases generated by services
in System of Engagement (SoE) fields other than telecommunications, so KDDI
often launched the systems on a small start basis. KDDI uses MySQL provided by
Oracle for these platforms.
• However, KDDI needed to guarantee the availability and reliability even for
general-purpose and collectively managed databases. The cost was an essential
requirement at the same time as guaranteeing the service level of the databases.
KDDI believed MySQL InnoDB Cluster would be a powerful solution for these
types of database. KDDI also decided to adopt MySQL Enterprise Monitor and
MySQL Enterprise Backup from MySQL Enterprise Edition.
RESULTS
• By the end of June 2019, KDDI had launched two systems using MySQL InnoDB
Cluster.
• One is a system originally using MySQL Master-Slave configuration for
replication. The rapid increase in service demanded higher system requirements
than initially expected. Since migrating to another platform while providing
services was too risky, KDDI chose MySQL InnoDB Cluster as the best option to
ensure availability under the same MySQL architecture.
• The other is a system construction project which was started to shift to in-house
development. KDDI aimed to accelerate service deployment by using MySQL
InnoDB Cluster.
• When a failure occurred in the conventional MySQL Master-Slave configuration,
the operator had to perform many operations for recovery, but the number of
operators having the necessary skills was limited. MySQL InnoDB Cluster solved
the problem and realizes automatic failover, eliminating the fear of a long service
outage.
• MySQL Shell has been particularly useful in disaster recovery. It enables everyone
to perform the same high-quality operations without depending on the skill level
of the operator and reduces the time required for recovery by more than 80%. In
some cases, by using MySQL Shell, failure recovery time has been reduced to
about 10 minutes when it used to be nearly an hour.
• MySQL InnoDB Cluster made it possible for KDDI to recover from potential failure
without affecting applications and businesses. No database downtime has occurred
since the system was launched.
• In addition, MySQL Enterprise Monitor is very effective in monitoring failures and
detecting potential issues. For operators who are not database experts, it was
评论