HighLoad++ 2017 Зал Дели + Калькутта, 7 ноября, 17:00 Тезисы: http://www.highload.ru/2017/abstracts/2853.html История развития инфраструктуры баз данных в Dropbox. Путь от одной глобальной базы к 6 тысячам шардов. - Как конфигурировать для разных типов, железа, версий mysql. - Интеграционные тесты для всех операций над кластером. - Multi instance (несколько серверов баз данных на одном сервере). Причины. - Бэкапы и восстановление за десятки минут. ...

1. Развитие баз
данных в
Dropbox.
Путь от одной глобальной базы MySQL
к тысячам серверов.
Слава Бахмутов - Dropbox SRE

2. Автор доклада
Site reliability engineer в Dropbox
Techlead в команде баз данных
Евангелист Go, соведущий golangshow.com
twitter: m0sth8
email: m0sth8@gmail.com

3. Структура доклада
• Кратко об архитектуре Dropbox
• История развития баз данных
• Операции (фейловеры, бекапы, клоны)
• Автоматизация
• Мониторинг
• Тестирование, стейджинг и DRT

4. Кратко об архитектуре Dropbox
Простым языком

5. Dropbox
500 млн пользователей
более 1.2 млрд новых файлов каждый день
200 000 бизнесов

6. Dropbox - файловое хранилище
Metaserver Blockserver
Клиенты (web, api, desktop)

7. Dropbox - файловое хранилище
https://blogs.dropbox.com/tech/2014/07/streaming-file-synchronization/

8. Dropbox - файловое хранилище
https://blogs.dropbox.com/tech/2014/07/streaming-file-synchronization/
Client Metaserver
commit("video.avi", "h1,h2,h3,h4)

9. Dropbox - файловое хранилище
https://blogs.dropbox.com/tech/2014/07/streaming-file-synchronization/
Client Metaserver
("no blocks", "h1,h2,h3,h4")
commit("video.avi", "h1,h2,h3,h4)

10. Dropbox - файловое хранилище
https://blogs.dropbox.com/tech/2014/07/streaming-file-synchronization/
store([h1, h2, h3, h4], [b1, b2, b3, b4])
Client Blockserver

11. Dropbox - файловое хранилище
https://blogs.dropbox.com/tech/2014/07/streaming-file-synchronization/
store([h1, h2, h3, h4], [b1, b2, b3, b4])
ok
Client Blockserver

12. Dropbox - файловое хранилище
Metaserver Blockserver
Clients (Web, api, desktop)
MySQL

13. Dropbox - файловое хранилище
Metaserver Blockserver
Clients (Web, api, desktop)
MySQL

14. Dropbox - файловое хранилище
Exabytes of raw data
Metaserver Blockserver
Clients (Web, api, desktop)
MySQL
Block
Storage

15. Dropbox - файловое хранилище
Exabytes of raw data
Petabytes of data
~6000 servers
Metaserver Blockserver
Clients (Web, api, desktop)
MySQL
Block
Storage

16. История развития баз данных
от одной глобальной базы до 6000 серверов

17. 2008
Metaserver
Global DB

18. 2011 - Shards?
Metaserver
Global DB User 1
User 2
Host 1
Host 2
Misc
Misc не в обработке запросов в продакшене
Blockserver

19. Рост пользовательской базы

20. 2011 - Shards!
Metaserver
Global DB User 1
User 2
Host 1
Host 2
Misc
Blockserver
Shard 0-1600
Shard 0-1600
Shard 0-1600

21. 2012 - Edgestore
Metaserver
Global DB User 1
User 2
Host 1
Host 2
Misc
Blockserver
Shard 0-1600
Shard 0-1600
Shard 0-1600
Edgestore
Edgestore
Shard 0-2048
https://www.youtube.com/watch?v=VZ-zJEWi-Vo

22. 2012 - Edgestore
https://blogs.dropbox.com/tech/2016/08/reintroducing-edgestore/

23. 2015 - Magic Pocket
Metaserver
Global DB User 1
User 2
Host 1
Host 2
Misc
Blockserver
Shard 0-1600
Shard 0-1600
Shard 0-1600
Edgestore
Edgestore
Shard 0-2048
Magic Pocket
BlockIndex
0-64
https://blogs.dropbox.com/tech/2016/05/inside-the-magic-pocket/

24. Архитектура баз данных
Топология, мультиинстанс, дисковери

25. Принципы
1. Надежность и долговечность

26. Принципы
1. Надежность и долговечность
2. Оптимальность решения

27. Принципы
1. Надежность и долговечность
2. Оптимальность решения
3. Простота решения

28. Принципы
1. Надежность и долговечность
2. Оптимальность решения
3. Простота решения
4. Стоимость владения

29. Принципы
1. Надежность и долговечность
2. Оптимальность решения
3. Простота решения
4. Стоимость владения
• Все принципы должны быть проверяемыми и измеряемыми

30. Принципы
1. Надежность и долговечность
2. Оптимальность решения
3. Простота решения
4. Стоимость владения
• Все принципы должны быть проверяемыми и измеряемыми
• Мы должны следовать этим принципам при любых решениях

31. Базовая топология
master
DC 1

32. Базовая топология
master
slave slave
DC 1
Cluster 11
Cluster 12 Cluster 13
Semisync

33. Базовая топология
master
slave slave
pseudo master
slave
DC 1 DC 2
Cluster 11
Cluster 12 Cluster 13
Cluster 21
Cluster 22

34. Специализированные топологии

35. Топология Magic Pocket
master
slave slave
DC 1
Cluster 11
Cluster 12 Cluster 13
DC 2 DC 3

36. Топология active-active
master
slave slave
DC 1
Cluster 11
Cluster 12 Cluster 13
master
slave slave
DC 2
Cluster 21
Cluster 22 Cluster 23

37. Инстансы
2x Xeon 10 cores
5TB (8 SSD Raid 0)
384 GB memory
Сервер

38. Сингл инстанс
+ Просто оперировать
+ Простые фейловеры
- Операции над одним
сервером
- Шарды влияют друг на
друга
mysqld:3306
shard1
shard2
shard3
shard4
proxy1-4:3001-3004
Сервер
Инстанс 1
"config": {
"mysqld": {
"innodb_buffer_pool_size": {
"value": "310G"
},

39. Мульти инстанс Сервер
mysqld:3307
shard1
proxy1-4:3001-3004
Инстанс 1
mysqld:3308
shard2
mysqld:3309
shard3
mysqld:3310
shard4
Инстанс 2
Инстанс 3
Инстанс 4
+ Операции над
инстансом
+ Шарды почти не влияют
друг на друга
+ Микс разных категорий
и классов баз
+ Улучшение репликации
- Сложнее управлять
- Сложнее фейловеры

40. Discovery
• Клиенты должны быстро узнавать об изменениях топологии
• Топология не должна зависеть от топологии репликации MySQL
• Атомарность изменений и верификация состояния

41. 2008 Discovery
Metaserver
Global DB
Адрес базы в конфиге в исходном коде

42. Discovery - 1
ConfigDB
Databases
scripts
Clients

43. Discovery - 1
+----------+-----------+--------+--------------+------+------------+
| category | shard_key | tclass | host | port | db_name |
+----------+-----------+--------+--------------+------+------------+
| host | 1 | master | 10.20.2.48 | 3306 | host1 |
| host | 2 | master | 10.50.83.24 | 3306 | host2 |
| sbc | 0 | master | 10.48.58.170 | 3306 | sbc0000000 |
| sbc | 1 | master | 10.48.58.170 | 3306 | sbc0000001 |
| sbc | 2 | master | 10.48.34.176 | 3306 | sbc0000010 |
| sbc | 3 | master | 10.48.34.176 | 3306 | sbc0000011 |
| sbc | 4 | master | 10.22.60.40 | 3306 | sbc0000100 |
| sbc | 5 | master | 10.48.53.43 | 3306 | sbc0000101 |
| sbc | 6 | master | 10.22.60.40 | 3306 | sbc0000110 |
| sbc | 7 | master | 10.48.53.43 | 3306 | sbc0000111 |
+----------+-----------+--------+--------------+------+------------+
Get (category, tclass, shard_key)
-> [host:port/dbname?user=password]

44. Discovery - 1.1
ConfigDB
Databases
scripts
Clients
Memcache

45. Discovery - 3 Категория/класс это один файл в AFS(zookeeper)

46. Discovery - 3 Категория/класс это один файл в AFS(зукипере)

47. Discovery - 3 Категория/класс это один файл в AFS(зукипере)

48. Discovery - 3. Формат данных
syntax = "proto3";
package register;
message Database {
repeated uint32 ports = 1;
string name = 2;
}
message Host {
fixed32 ip4 = 1;
// shard_key -> Database map
map<string, Database> shards = 2;
}
message FileContent {
fixed64 version = 1;
string category = 2;
string tclass = 3;
// hostname -> Host map
map<string, Host> hosts = 4;
}
afs ls -l /afs/iad/services/registry3/topology
28906 2017-06-14 04:35:57 shard.slave_proxy.pb.gz
25570 2017-06-14 04:35:57 edgestore.slave.pb.gz
20292 2017-06-14 04:35:57 shard.slave.pb.gz
13727 2017-06-14 04:35:55 edgestore.master.pb.gz
8515 2017-06-14 04:35:58 shard.proxy.pb.gz
8101 2017-06-14 04:35:55 shard.master.pb.gz

49. Операции
promotion, clone, backups/recovery

50. Операция

51. Promotion (смена мастера)

52. Promotion

53. Фейловер (замена поломанного мастера)
• Мастер умер <- идеальный случай

54. Фейловер (замена поломанного мастера)
• Мастер умер <- идеальный случай
• Мастер иногда жив

55. Фейловер (замена поломанного мастера)
• Мастер умер <- идеальный случай
• Мастер иногда жив
• Мастер медленно умирает и все системы сбоят по своему (slow
death)

56. Фейловер (замена поломанного мастера)
• Мастер умер <- идеальный случай
• Мастер иногда жив
• Мастер медленно умирает и все системы сбоят по своему (slow
death)
• Мастер перегружен. <- промоушен сделает только хуже

57. Фейловер
• 4-5 раз в неделю
• Полностью автоматизирован
• Занимает около 30 секунд
• Куча дополнительных проверок (а что если мастер жив?)

58. Фейловер

59. Фейловер
Перезагрузка мастера

61. Фейловер
Синхронизация кластера

63. Фейловер
Промоушен

66. Бекапы
• Паттерны использования и гарантии
• Цикл
• Операция
• Планы

67. Паттерны использования
1. 👬 Добавить новый слейв. (постоянно)

68. Паттерны использования
1. 👬 Добавить новый слейв. (постоянно)
2. ⏳ Восстановление данных на точку в прошлом (часто)

69. Паттерны использования
1. 👬 Добавить новый слейв. (постоянно)
2. ⏳ Восстановление данных на точку в прошлом (часто)
3. 🆘 Восстановить целиком весь кластер с нуля. (никогда)

70. Гарантии.
1. В нормальных условиях, ожидаемая скорость восстановления 1TB
за 40 минут.
2. Любую базу можно восстановить на любой период времени за
последние шесть дней.
Основные факторы: ограничения скорости работы по сети, троттлинг.

71. Цикл
Global DBShard 0-1600
Edgestore
Shard 0-2048
BlockIndex
0-64
HDFS
Каждые 24 часа

72. Цикл
Global DBShard 0-1600
Edgestore
Shard 0-2048
BlockIndex
0-64
HDFS
Каждые 6 часов

73. Цикл
Global DBShard 0-1600
Edgestore
Shard 0-2048
BlockIndex
0-64
HDFS S3
Каждые 3 дня

74. Цикл
Global DBShard 0-1600
Edgestore
Shard 0-2048
BlockIndex
0-64
HDFS S3
Каждые три дня

75. Цикл

76. Hot backup ||
/
/
+-------------------------------------------+
| xtrabackup --parallel --stream=xbstream |
| | |
| splitter --chunks 8 --manifest_path |
| | | | |
| qpress qpress ... |
| | | |
| encode encode |
| | | |
| HDFS/S3 HDFS/S3 |
+-------------------------------------------+

77. Hot recovery
/
/
||
2. Crash-recovery + binlog replay
+-------------------------------------------+
| xtrabackup --parallel --stream=xbstream |
| | |
| splitter --chunks 8 --manifest_path |
| | | | |
| qpress qpress ... |
| | | |
| decode decode |
| | | |
| HDFS/S3 HDFS/S3 |
+-------------------------------------------+
1. Server bootstrap

78. Binlogs

79. Планы
Холодные бекапы.
Предпосылки:
1. Скорость каналов стала больше, можно утилизировать больше.
2. Хочется восстанавливать быстрее и создавать клоны тоже быстро.
3. Полная верификация бекапов (pt-table-checksum).

80. Холодные бекапы. Гарантии
1. В нормальных условиях, ожидаемая скорость восстановления 1TB
за 10 минут.
2. Любую базу можно восстановить на любой период времени за
последние шесть дней.

81. Холодные бекапы
master
slave slave
pseudo master
slave
DC 1 DC 2
Cluster 11
Cluster 12 Cluster 13
Cluster 21
Cluster 22
Останавливаем этот слейв,
делаем бекап, запускаем обратно.

82. Планы ++
Дополнительный диск (HDD) на каждом сервере. (10 TB)
Горячие бекапы на этот диск + сrash recovery xtrabackup.

83. Клон
1. Восстановление из бекапа и проигрывание бинарных логов
2. Процесс бекапа сразу на целевой сервер

84. Автоматизация

85. Автоматизация
• Auto-replace
• DBManager
• Naoru, Wheelhouse

86. Auto-replace
1. Сервер почил в бозе
2. Нужно понять что за проблема
3. Решить как можно быстрее

87. Availability (доступность)
MTBF - mean time between failure
MTTR - mean time to repair
MTTR = "time to detect" + "time to remediate"
https://www.vividcortex.com/blog/the-factors-that-impact-availability-visualized

88. Health check
mysqld:3306
Node
proxy:3001-3004
Service 1
Пишет heartbeat в мастер,
реплицируется на слейвы

89. Health check
mysqld:3306
Node
proxy:3001-3004
Service 1
Пишет heartbeat в мастер,
реплицируется на слейвы
Service 2 Проверяет мастер на RW.
Прокси на ответ.

90. Health check
mysqld:3306
Node
proxy:3001-3004
Service 1
Пишет heartbeat в мастер,
реплицируется на слейвы
Service 2 Проверяет мастер на RW.
Прокси на ответ.
Хранилище
heartbeat в ДЦ

91. Auto-replace

92. Auto-replace

93. Auto-replace

94. Auto-replace

95. Auto-replace

96. Auto-replace

97. Auto-replace
Reverse health check

98. Auto-replace

99. Auto-replace

100. DBManager
• Умный планировщик задач
• Источник правды
• Точка синхронизации

101. DBManager

102. DBManager
Планировщик и API

103. DBManager
Клиенты

104. DBManager
Воркеры

105. DBManager

106. DBManager

107. DBManager

108. DBManager

109. Remediations
• Naoru - параноидальная автоматизация
• Wheelhouse - долгие процессы и стейт машины
https://m.youtube.com/watch?v=4Fe3DyzPtlo

110. Мониторинг
Метрики, инциденты

111. Мониторинг mysql

112. Алёрты

113. Инциденты

114. Инциденты - анализ

115. Тестирование, стейджинг и DRT

116. Интеграционные тесты
• Тестирование всех используемых топологий
• Тестирование всех операций

117. Интеграционные тесты
➜ topologies master ls
BUILD ext_proxy.json
BUILD.bzl master_slave.json
analytics_master_slave.json master_slave_multi.json
clone.json master_slave_multi_shards.json
clone_2dc_free_multi.json master_slave_shards.json
clone_2dc_free_shards.json multiple_clusters.json
clone_2dc_free_test.json no_node.json
clone_shards.json prodlike_1dc.json
clone_target_finder.json prodlike_1dc_multi.json
cluster.json prodlike_1dc_multi_shards.json
dbtestenv.bzl prodlike_1dc_shards.json

118. Интеграционные тесты
{
"mdb_common": {
"tags": [
"db"
],
"attrs": {
"owner": "team-server+database-ops",
"lifecycle": "allocated",
"databases-isotester": "shrink_instance",
"hwclass": "mustafa",
"metro": "sjc",
"cluster": "sjc8a",
"row": "c",
"os": "Ubuntu-12.04"
}
},
"nodes": {
"sjc8a-rc04-1a": {
"mdb_overrides": {
"instances": {
"sjc8a-rc04-1a:3306": {
"registered": true,
"register_data": [
{
"category": "schema_test",
"tclass": "master",
"port": 3306,
"shard_key": "",
"db_name": "schema_test"
},
{
"category": "schema_test",
"tclass": "proxy",
"port": 3001,
"shard_key": "",
"db_name": "schema_test"
},

119. Интеграционные тесты
class TestAutoReplaceMaster(BaseIntegrationTest):
TOPOLOGY = 'clone_shards.json'
def test_auto_replace_master(self):
with create_auto_replace_service() as auto_replace_service:
auto_replace_service.start()
cluster = self.instances['master'].cluster
master_kill = KillAllInstancesForce(node=self.nodes[self.master_node])
master_kill.run()
self.assertFalse(self.instances['master'].instance.is_responsive())
new_master = cluster.get_master_by_registry().config
self.assertIn(new_master, [self.instances['slave1']])
self.assertTrue(new_master.state == 'master')
self.assertIsNone(new_master.instance.get_master())
self.assertNotIn('mysql', self.nodes[self.master_node].mdb.tags)
self.assertNotIn('master', self.nodes[self.master_node].mdb.tags)

120. Stages
• Интеграционное тестирование в реальной инфраструктуре
• Под искусственной, но близкой к реальной нагрузкой
• Тестирование алёртов/метрик
• Тестирование всей автоматизации вместе (в тестах системы
разделены)

121. DRT (Disaster recovery testing)
• Тестируем наши гарантии
• Клиенты готовы к ошибкам (замена и смерть мастера)
• Бизнес часы дежурства, меньше стресса.

122. Заключение
1. Всё автоматизировать (не лезть руками)

123. Заключение
1. Всё автоматизировать (не лезть руками)
2. Постоянные автоматизированные тесты (и в продакшене)

124. Заключение
1. Всё автоматизировать (не лезть руками)
2. Постоянные автоматизированные тесты (и в продакшене)
3. Владеть клиентами (библиотеками)

125. Заключение
1. Всё автоматизировать (не лезть руками)
2. Постоянные автоматизированные тесты (и в продакшене)
3. Владеть клиентами (библиотеками)
4. Соблюдать принципы и проверять свои гарантии

126. Заключение
1. Всё автоматизировать (не лезть руками)
2. Постоянные автоматизированные тесты (и в продакшене)
3. Владеть клиентами (библиотеками)
4. Соблюдать принципы и проверять свои гарантии
6000 серверов баз данных на 5 человек

127. Вопросы?
twitter: m0sth8
email: m0sth8@gmail.com

128. Не влезло

129. Сплит шардов (two way)
1. Добавляем 3 слейва в основном дц, 2 в дополнительном
2. Выбираем таргет слейв(будущий новый мастер)
3. Реперентим часть слейвов на таргет слейв
4. Промоутим только часть шардов на таргет слейв
5. Переименовываем базы данных
1. на 1-ом SHARD_5-8_REMOVED
2. на 2-ом SHARD_1-4_REMOVED
6. У нас теперь два кластера с разделёнными шардами.

130. Discovery - 2 Каждый шард это нода в зукипере

131. Remediations by Naoru
A human operator must authorize execution here,
unless the Prescription was instantiated
with run_automatically=True
+
+
+
Issues Issue Prescription + IssuePullPlugin
IssuePullPlugin --------*---------> DiagnosePlugin -------------+> RemediatePlugin ----> verifies that the ------|
^ ^ ^ ^ + ^ ^ issue is no longer ^
| | | | | | a problem |
Hooks Hooks Hooks Hooks Hooks Hooks Hooks
Hooks have the ability to
postpone execution or even
to completely deny it
Параноидальная автоматизация

132. Naoru
Alerting

133. Naoru

134. Naoru
Alerting
Diagnose
Plugin

135. Naoru
1. Проверить что ssh работает
2. Подключиться по IPMI
A. Нет ответа - Перезагрузка
B. Зависло в initramfs - Деаллокация машины
C. CPU soft lockup - Перезагрузка

136. Naoru
Alerting
Diagnose
Plugin
Remediate
Plugin
Авторизация
оператором

137. Naoru

138. Naoru
Alerting
Diagnose
Plugin
Remediate
Plugin
Авторизация
оператором
Hooks

139. Naoru

140. Naoru
Alerting
Diagnose
Plugin
Remediate
Plugin
Авторизация
оператором
Hooks

141. Naoru

142. Naoru
Alerting
Diagnose
Plugin
Remediate
Plugin
Авторизация
оператором
HooksHooks

143. Wheelhouse
• Сложная и долгая автоматизация
• Обновление ядра или версии БД
• Перемещение серверов из одной стойки в другую
• http://bitly.com/stm-dropbox <- пример

144. Wheelhouse
144

145. Wheelhouse
145

146. Wheelhouse
146

147. Wheelhouse
147

148. Wheelhouse
148

149. Wheelhouse
149

150. Wheelhouse
150

151. Wheelhouse
151

152. Wheelhouse
152

153. Wheelhouse
• Только один маленький блок
• Переиспользуем в других проектах
153

154. DRT (Disaster recovery testing)

155. DRT (Disaster recovery testing)