Кластеры баз данных делаем сложные вещи просто /...
-
Upload
ontico -
Category
Engineering
-
view
380 -
download
9
Transcript of Кластеры баз данных делаем сложные вещи просто /...
Кластеры баз данных:делаем сложные вещи простоСиське!
Андрей Тихонов[email protected]
Avito.ru DevOps
Содержание
● Как начинается Highload? (6 слайдов)● Балансируем нагрузку на Backend (2 слайда)● Методы масштабирования БД (3 слайда)● Создаём кластер Redis/Memcached/Tarantool (12 слайдов)● Создаём кластер PostgreSQL (9 слайдов)
2/36
Немножко статистики Avito
● 1M+ запросов в минуту к Backend● 1Gb/s+ исходящий трафик (не считая картинки)● 100K+ запросов в секунду на nginx-балансеры● Терабайты или миллиарды картинок
3/36
Как начинается Highload?
Web-server Backend Database
4/36
Как начинается Highload?
Web-server Backend Database
Cache
5/36
Как начинается Highload?
Web-server Backend * Database
Cache
6/36
Как начинается Highload?
Web-server Backend * Database
CacheStorage Queue
7/36
Как начинается Highload?
Web-server * Backend * Database *
Cache *Storage * Queue *
8/36
Как начинается Highload?
9/36
Как работает Avito:
Балансируем нагрузку на Backend
10/36
nginx.conf:... location / { proxy_pass http://backend.local; }...
Балансируем нагрузку на Backend
11/36
nginx.conf:...upstream backend { server backend01.local:80; server backend02.local:80; server backend03.local:80;}... location / { proxy_pass http://backend; }...
Методы масштабирования БД
12/36
Backend
Database
Read
Write
Методы масштабирования БД: репликация
13/36
Backend
Read
Write
MasterSlave
Read
Replication
*репликация Master-Master здесь не рассматривается
Методы масштабирования БД: шардирование
14/36
Backend
Read
Write
Shard02Shard01
Read
Write
Создаём кластер Redis/Memcached/Tarantool
15/36
Проблемы:● Установление подключения – долгая операция● Срок жизни подключения – не дольше, чем
работает скрипт● Больше подключений – больше накладных
расходов на сервере
Создаём кластер Redis/Memcached/Tarantool
16/36
Решаем проблемы с помощью Twemproxy:● Прозрачно проксирует на уровне протокола
Memcached/Redis/Tarantool*● Держит постоянное подключение к серверу● Устанавливает мало подключений к серверу,
через них мультиплексирует много клиентских подключений
* нужен патч
Создаём кластер Redis/Memcached/Tarantool
17/36
twemproxy-redis-single.yml:
alpha: listen: 127.0.0.1:22121 redis: true auto_eject_hosts: true server_retry_timeout: 2000 server_failure_limit: 2 server_connections 1 servers: - 127.0.0.1:6379:1
Создаём кластер Redis/Memcached/Tarantool
18/36
Шардируем с помощью Twemproxy:● Автоматическое шардирование● Поддерживает стойкое хэширование● Автоматически конвейеризует запросы и
ответы
Создаём кластер Redis/Memcached/Tarantool
19/36
twemproxy-redis-shard.yml:
beta: listen: 127.0.0.1:22122 redis: true distribution: ketama hash: fnv1a_64 auto_eject_hosts: false server_retry_timeout: 500 server_connections 1 servers: - 127.0.0.1:6381:1 server1 - 127.0.0.1:6382:1 server2
Создаём кластер Redis/Memcached/Tarantool
20/36
Добавляем отказоустойчивость Redis-кластера с помощью MSR, Sentinel и HAProxy:
● Master-Slave Replication средствами Redis● Автоматическое переключение в случае отказа
мастера с помощью Redis Sentinel● Прозрачное для клиента переключение с помощью
HAProxy
Создаём кластер Redis/Memcached/Tarantool
21/36
Master-Slave Replication средствами Redis:
redis.conf (slave side):
slaveof 192.168.10.1
Создаём кластер Redis/Memcached/Tarantool
22/36
Redis Sentinel● Мониторит состояние всех нод кластера● Уведомляет об ошибках● Автоматически промотирует slave до master в случае
падения master● Выступает в качестве провайдера конфигурации
Создаём кластер Redis/Memcached/Tarantool
23/36
Redis Sentinel
redis-sentinel.conf:
sentinel monitor cluster01 192.168.10.1 6379 2sentinel down-after-milliseconds cluster01 60000sentinel failover-timeout cluster01 180000sentinel parallel-syncs cluster01 1
Создаём кластер Redis/Memcached/Tarantool
24/36
HAProxy● TCP-прокси● Балансирует нагрузку разными алгоритмами
– Round-robin, least connections, first available, param* hash● Primary/backup группы backend-серверов● Различные способы проверки доступности серверов
– TCP connect, protocol* check, TCP send-expect
Создаём кластер Redis/Memcached/Tarantool
25/36
HAProxyhaproxy-redis.conf:listen redis-cluster bind *:16379 mode tcp option tcpka option tcplog option tcp-check balance roundrobin
server redis01 192.168.10.1:6379 check port 6379 check inter 2s server redis02 192.168.10.2:6379 check port 6379 check inter 2s
tcp-check send PING\r\n tcp-check expect string +PONG tcp-check send info\ replication\r\n tcp-check expect string role:master tcp-check send QUIT\r\n tcp-check expect string +OK
Создаём кластер Redis/Memcached/Tarantool
26/36
Создаём кластер PostgreSQL
27/36
Проблемы:● Одно подключение – один процесс, создание
процесса – дорогостоящая операция● Больше подключений – больше накладных
расходов на сервере● План запросов и т. п. кэшируется внутри
процесса, новое подключение – пустой кэш● Срок жизни подключения – не дольше, чем
работает скрипт
Создаём кластер PostgreSQL
28/36
Решаем проблемы с помощью PgBouncer:● Прозрачно проксирует на уровне протокола
PgSQL● Держит постоянное подключение к серверу● Мультиплексирует клиентские подключения в
трёх режимах: session, transaction, statement pooling
● Выполняет запросы до и после подключения
Создаём кластер PostgreSQL
29/36
Решаем проблемы с помощью PgBouncer:pgbouncer.ini:
[databases]main = host=db-main pool_size=5 connect_query='select prepare_statements_and_stuff()'[pgbouncer]listen_port = 6432listen_addr = *pool_mode = transactionmax_client_conn = 1024
Создаём кластер PostgreSQL
30/36
Синхронная и асинхронная репликация
Синхронная:● Мастер ждёт, пока все слейвы получат данные● Надёжная, но медленная
Асинхронная:● Мастер отправляет данные в очередь и не ждёт● Быстрая, но ненадёжная, теряет ACID, так как
слейвы отстают
Создаём кластер PostgreSQL
31/36
Физическая и логическая репликация
Физическая:● Полная копия всех данных● Загружает I/O
Логическая:● Можно выбирать, какие данные копировать● Загружает CPU
Создаём кластер PostgreSQL
32/36
Создаём MSR-кластер
1 master, 1 slave:● Распределяем нагрузку на чтение● Нет отказоустойчивости
1 master, 2+ slave:● Можем выдержать падение мастера
Создаём кластер PostgreSQL
33/36
Создаём отдельную реплику для индексации● Не вымывается кеш на мастере● С помощью логической репликации копируются
только нужные данные● Данные умещаются в RAM – нет медленного I/O
Создаём кластер PostgreSQL
34/36
Создаём кластер PostgreSQL
35/36
Шардируем с помощью PL/Proxy● Языковое расширение PostgreSQL● Устанавливается на одной прокси-ноде● Вся логика шардирования описывается в
хранимых процедурах PostgreSQL● Можно реализовать поддержку шард с MSR
Подведём итоги
36/36
● Много кратковременных подключений к серверу – плохо, используем прокси
● Нужна отказоустойчивость – используем Master-Slave Replication, делаем несколько слейвов
● Слейвы должны быть не слабее мастера● Данные не умещаются на одном сервере – шардируем на
несколько серверов● Все эти подходы можно комбинировать