Highly Available
Highly available (high availabiltity)
- The ability of applications to provide continuous, uninterrupted (usable) services
- Evaluation of system high availability is usually expressed as an availability rate
Causes that are not available
- Hardware failure (various)
- Expected system hardware and software maintenance
- Software defects (application code, service programs may have bugs)
- Attack, leak, think of a mistake ... and other security events
- For the system, the unavailable time is the sum of the unavailable time for each key component ....
The main means of improving usability
- Redundant, redundancy
- Critical hardware and software to avoid long-time outages through backup redundancy
- Data software, hardware, stored data, all need to be redundant to ensure that the fault can be replaced
MySQL high availability common scenarios:
- Database service has its particularity in redundancy implementation
-
- Data: Service "stateful" and data redundancy
- Database availability takes two parts: data availability, service availability;
- There are many ways to implement the same data, there will be a variety of implementation scenarios
- Availability Targets Step
-
- No data loss caused by any failure-> can recover service faster (high availability)
Highly Available scenarios
1.mysql--single-live scheme based on shared storage (infrequently used)
- SAN, the scheme is more expensive, so it is not used;
- and the database standby machine, but the machine is alive, but there is no MySQL service;
-
- Because most shared storage or databases do not allow the same data to be used by different data;
- Local data security through raid and other means
2. Storage replication-based data redundancy single copper (infrequently used)
- There is a certain waste, standby machine has not been used, waiting for the host to hang up, will use the standby machine;
- and DRBD (two machines across the network, backup data), not 100% of the guaranteed data is not lost;
3. Multi-master replication based on the Cluster Submission communication protocol (for certain scenarios)
high-availability scenarios based on master-slave replication
4. mysql-based master-slave replication (common, pervasive)
- Provision of services on-line, to avoid waste;
- and master-slave replication, but also ensure that the data will not be lost.
MySQL master-slave replication high-availability scenarios require improved issues
- The master-slave server each has an IP address, and the application needs to be changed after the master-slave switch.
- How to get the app to find it quickly from the library; Vip/dns
- It takes a lot of time to manually determine if the main library fails and then initiates the switchover.
- How to detect automatically, monitor the detection and automatically vip/dns;
- There is an objective delay in the master-slave replication, which can cause transaction data loss.
- How to avoid data loss due to network latency.
1. In order to avoid the application of manually modifying the switching IP, the VIP (virtual IP) drift scheme is introduced:
Scenario Two: DNS, application server, use domain name, usually, the domain name is registered in the main library, and the main library hangs, the domain name is registered to the library on it; 2. In order to reduce the time overhead of manual intervention, the introduction of automatic
mechanism of exploration and treatmentHighly available middle tier and RDS
- Vip/dns Resolving application switching issues
- Monitor and manage servers to resolve auto-judgment failover and vip/dns drift
- Vip/dns Management + exploration + master-slave Relationship switching = highly available middle tier
-
- Transparent switch management + reliable data exploration + use Toggle = High available middle tier
- Cloud Environment + highly available middle tier + underlying database = a paas= basic RDS,
High-availability middle tier
- MHA
-
- Automatically selects the minimum replication delay from the node and attempts to fill the log (but most host failures do not work)
- Usually requires two from above, will be the master-slave relationship switching
- Do not provide VIP management solutions
- MMM
-
- Provides a basic VIP management function
- A pair of hosts that are suitable for dual-master configurations and do not actively switch master-slave relationships
- No support for master-slave data delay judgment and completion
General use of MHA, open source; 3.mysql master-slave replication delay Why log transmission delay why the master-slave replication, the master-slave library data inconsistency; solution: MySQL Semi-synchronous technology: Primary repository Commit, wait until the main library is persisted and persisted from the library. To give the primary key back to commit successfully. But the problem: the main library waiting time from the library is not controllable, the main library is not written in the library, can wait a few seconds, and then the main library replication automatically degraded to asynchronous replication, but this may also lead to inconsistent data; a more complete MySQL high-availability scenario
- Semi-synchronous replication + highly available middle tier +VIP management solution
- Highly available middle tier = Live Scout + Master-slave switch + interface with VIP management
For example:
- Semi-synchronous replication +mha (high-availability middle tier) +keeplive (VIP management Scheme)
- Semi-synchronous replication +rds
Summary
- High-availability indicators at least 3 9 targets 4 x 9
- The high-availability core is the use of redundancy
- Two sections of database high availability
-
- Data availability-data is stateful
- Availability of services
- Highly Available scenarios
-
- A single live solution based on a shared storage San
-
- SAN, expensive equipment
- Single live, spare machine waste, because the same data can not be used by different MySQL instances;
- Local data can be guaranteed by means of raid
- Data redundancy single live based on DRBD storage replication
-
- SAN-based improvements that do not use SAN devices
- Single live, spare machine waste
- DRBD backs up data over the network based on two machines, data cannot be guaranteed 100%
- Multi-master replication--mysql cluster
- MySQL-based master-slave replication (common, pervasive)
-
- Backup, can provide read-only service on-line, avoid wasting;
- Master-slave replication ensures that data is not lost
- MySQL master-slave replication based on the problem
-
- Master-Slave server each has an IP address, after the master-slave switch application needs to modify the restart;
-
- With the VIP (virtual IP)/dns management scenario, when a switchover occurs, only the VIP is shifted from the main library to the slave library, which is transparent to the application.
- Manually determine if the main library is faulty, it takes a long time to initiate the switchover
-
- Using monitoring server, automatic detection + automatic master-slave switch
- There is an objective delay in master-slave replication, which may result in loss of transactional data
-
- The use of semi-synchronous replication technology, but also to consider the outage from the library, the main library should be automatically degraded into asynchronous replication;
- MySQL high-availability solution after problem solving
-
- VIP Management solution + highly available middle tier + semi-synchronous replication
- High-availability middle tier
-
- Vip/dns Management + Reliable exploration + master-slave Relationship switching = highly available middle tier
- Cloud Environment + highly available middle tier + underlying database = a paas= basic RDS
- Mha/mmm
- MHA
-
- Automatically selects the minimum replication delay from the node and attempts to fill the log (host failure is not feasible)
- Automatic exploration
- Automatic master-Slave switching
- does not provide VIP management solutions, but provides interfaces that use the VIP scheme
MySQL High-availability architecture
