---
aliases:
  - репликации master-slave
tags:
  - maturity/🌱
date:
  - - 2024-03-10
zero-link:
  - "[[../../../meta/zero/00 HighLoad|00 HighLoad]]"
parents:
  - "[[Репликация БД|Репликация БД]]"
linked:
  - "[[Репликация master-master]]"
---
В такой схеме у нас есть одна ведущая реплика (master) в которую пишутся изменения и несколько ведомых реплик (slave), на которые эти изменения копируются, из них можно только читать. Это наиболее распространенный подход репликации, так как он относительно прост и понятен. 

![](Pasted%20image%2020240206194227.png)

**Проблемы и недостатки:**
- Мастер обязательно когда-нибудь упадет. И нужно будет как-то выбрать из slaves нового master.
- Как и другие способы репликации не ускоряет операции вставки данных.
- Этот способ никогда не даст 99,9999 [Availability](../../../../../_inbox/Availability.md).

Управление master-slave:
- MHA (MySQL Master HA)
- MySQL Failover (Oracle)
- Orchestrator
***
## Мета информация
**Область**:: [[../../../meta/zero/00 HighLoad|00 HighLoad]]
**Родитель**:: [[Репликация БД|Репликация БД]]
**Источник**:: 
**Автор**:: 
**Создана**:: [[2024-03-10]]
### Дополнительные материалы
- [[Репликация master-master|Репликация master-master]]
### Дочерние заметки
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->