First, MySQL
MySQL small high-availability architectureScenario: MySQL dual master, master-slave + keepalived master-Slave automatic switch server resources: Two PC server advantages: Simple architecture, save resources disadvantage: Unable to linearly expand, master and slave failure after manual recovery of master-slave architecture
MySQL medium high-availability architectureScenario: MMM + mysql dual master + multi from high-availability Program server resources: 1, at least five PC server,2 console MySQL main library, 2 MySQL from the library, 1 mmm monitor;2, 1 mmm Monitor choose low match; 3, If you do not use F5 as a load balancer from the library, you can use 2 PC servers to deploy LVS or haproxy+keepalived combinations instead; advantages: Dual-Master hot standby mode, read and write separation, slave cluster linear expansion disadvantage: Read and write separation needs to be resolved at the terminal, Master High-Volume write operation will result in master-slave delay
MySQL large high-availability architectureMain idea: Middleware +mysql sharding such as scheme: Cobar and other middleware +mysql technical picture slightly. In addition, I also share some of the main MySQL high-availability architecture 1, MySQL dual master + keepalived automatic switching scheme (above) 2, MySQL master-slave + keepalived master-slave automatic switching scheme (above already) 3, Mmm+mysql dual Master + Multiple from highly available scenarios (above already) 4, MySQL + pecemaker (Heartbeat) + DRBD High Availability 5, MySQL + RHCs high Availability scenario 6, MySQL + cluser cluster architecture 7, Percona Xtradb Cluster cluster high Availability Solution 8, middleware + MySQL large cluster solution (mentioned above) MySQL + pecemaker (Heartbeat) + DRBD high availability && MySQL + RHCs high Availability scenario Percona Xtradb C Luster Cluster High Availability solution MySQL multi-room deployment Architecture Reference II, Oracle
1. Oracle ActivedataguardServer resources: 2 pcs Server1, Oracle's own disaster recovery system, fully redundant database protection, can be deployed across IDC; 2, Oracle 11g or above version standby can be opened redo mode, can be used as a data warehouse, or as a backup database; 3, switchable, Manual switching is generally used.
2. Oracle RACServer resources: At least two PC servers as RAC nodes, SAN storage One, other resources: Fiber network environment RAC features: 1, high availability: Ensure that as long as there is a surviving node, will not break the business, maintain business continuity 2, dual-machine duplex: RAC is a parallel mode of work, The relationship between nodes is active to active, each node can provide services to clients 3, easy scaling: RAC increase, delete nodes very convenient 4, high throughput: The number of nodes and throughput is proportional to the relationship
3. Oracle MAAScenario: Rac+asm+standby (RAC) Deployment Server resources: Resources required for RAC * Other resources: Offsite room Notes: Maa is essentially a rac+dataguard combination. Oracle also has many other highly available architectures, such as replication with Oracle Golden Gate, etc...
Third, MongoDB
MongoDB High-availability architectureScenario: MongoDB Replica set +sharding shard server resources: 1, 9:6 PC Server as a shared node, 3 as the quorum node, three MONGOs and config each deployed on three shared nodes, such as; 2, scale-out shards, A component piece is composed of 3 PC servers; 3. The Quorum node server does not store the actual data, so it is low. Note: 1, considering the high scalability issues, to abandon the MongoDB master-slave replication scheme, 2, the data security requirements very high business, each group of shards can be composed of 5 PC server; 3, it is recommended that developers combine business to select the most appropriate chip key.
Four, Redis
Redis Small, highly available architectureScenario: Redis Master-slave replication +keepalived implements failover server resources: Two PC server benefits: Simple architecture, reduced resource disadvantage: there is an interval between master and slave switching, during which the client will receive an error scenario: Redis Sentinel Implementation failover Server resources: 1, two PC server to deploy Redis, one Redis sentinel;2, Redis can choose a master multi-slave architecture, 3, a redis Sentinel choose low Match. Pros: The Redis official HA scenario, written by the Redis author, has drawbacks: After failover occurs, the client needs to correct the address manually
Redis Medium High-availability architectureScenario: Redis master-slave +haproxy load Balancing server resources: At least 3 PC servers deploying Redis Master-Slave, two PC server deployments Haproxy benefits: Read-write separation, scale-out slave disadvantage: Master is a single point
Redis Large, highly available architectureScenario: Twemproxy Implementing Redis Storage Shard Server resources: At least 6 PC servers deploying Redis master-Slave, at least 3 PC servers deploying twemproxy,2 PC Server Deployment Haproxy Benefits: sharding, load Balancing, Redis and Twemproxy can scale the disadvantage: the shortcomings of the Twemproxy: 1, twemproxy node expansion, the original data needs to be re-processed distribution, to avoid the occurrence of the key value, 2, expand the Redis node, the data is not automatically distributed evenly, And it needs to be handled manually.
Database High-availability architecture (MySQL, Oracle, MongoDB, Redis)
