Translate

Показ дописів із міткою db. Показати всі дописи
Показ дописів із міткою db. Показати всі дописи

четвер, 25 серпня 2016 р.

Redis Sentinel

У цій статті піде мова про Sentinel - один із способів забезпечення високої доступності Redis. Забігаючи наперед, скажу, що Redis Sentinel не надає можливостей шардингу (sharding), тобто для збільшення простору збереження даних необхідно збільшувати кількість оперативної пам’яті сервера.

Дуже раджу попередньо ознайомитись з простою реплікацією Redis, про яку я писав дещо раніше. У двох словах, Redis Sentinel - це звичайна реплікація Redis, але з можливістю автоматичного міграції майстра на інший працюючий вузол, що був у реплікації. Після такої міграції майстра, попередній майстер, завдяки додатковому демону Sentinel, автоматично переконфігуровується в слейв, який може використовуватись лише для читання.

Для налаштування Redis Sentinel використаємо такі адреси:

192.168.1.39
192.168.1.42
192.168.1.43

Установимо пакети redis-server та redis-sentinel на кожен із серверів. У якості дистрибутиву я обрав останню LTS Ubuntu - 16.04. Зі стандартного репозиторію встановимо Redis та Sentinel:

# apt install redis-server
# apt install redis-sentinel

Зрештою, сервер Redis займе звичний порт 6379, а sentinel - 26379. Ясна річ, що ці порти мають бути відкритими в фаєрволі, якщо такий є.

Перезавантажимо Redis та перевіримо його роботу:

# redis-cli ping
PONG

Конфігурація кластера Sentinel не має викликати особливих труднощів. Перше, що необхідно перевірити - це те чи відкритий порт Redis для віддаленої роботи:

# vim /etc/redis/redis.conf
...
bind 0.0.0.0
...

Порт 6379 має працювати на нелокальному інтерфейсі для взаємодії Redis-процесу з іншими вузлами. Ця опція має приймати аналогічне значення і для Sentinel сервісу в /etc/redis/sentinel.conf.

Налаштовуємо Sentinel-процес:

# vim /etc/redis/sentinel.conf
...
sentinel monitor mymaster 192.168.1.39 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1
...

неділя, 14 серпня 2016 р.

Redis Replication: Master-Slave

Декілька тижнів тому, я писав базові можливості Redis та як з ним працювати. Також я обіцяв продовжити цикл статей про Редіс і розповісти про високу доступність, кластеризацію та реплікацію цього сервісу. Отже цього разу мова піде про вбудовану в Redis асинхронну реплікацію Master-Slave.

Redis має вбудовану Master-Slave реплікацію і особливості її наступні:
  • Асинхронність, що на практиці означає, що дані лише з часом потрапляють на слейв. З версії 2.8 слейв періодично надсилає майстру підтвердження щодо того, скільки даних було cкопійовано.
  • Майстер може мати декілька слейвів одночасно
  • Слейви можуть бути підключені каскадно один до одного. Тобто для кожного наступного слейву, попередній слейв виступатиме джерелом даних для реплікації.
  • Процес реплікації є неблокуючим для майстра. Це значить, що майстер продовжує відповідати на всі запити, навіть якщо слейв запитав початкову синхронізацію
  • Процес реплікації також не є блокуючим і для слейвів, у разі, якщо в конфігураційних файлах дозволено використання старого набору даних для відповіді на запити. Інакше, є можливість заборонити такі дії і слати помилки клієнтам, якщо процес реплікації зупинений. 
  • Реплікація може використовуватись для масштабування операцій читання: чим більше слейвів - тим швидше відбуваються операції читання, і тим більшу кількість запитів мають можливість обробити сервера. У разі падіння діючого майстра - слейв можна зробити новим майстром. Тобто слейви можуть використовуватись лише для читання, зі зрозумілих причин операції запису на них заблоковані.
Більш того, опціонально можна вимкнути механізм(и) збереження даних на диск на майстрі, задля підвищення швидкості його роботи. Так як слейви все реплікують - вони і будуть джерелом наповнення даних у разі падіння останнього. Але є одне але: у такому разі автозапуск Redis-процесу необхідно заборонити, адже інакше відсутні дані майстра (дивно звучить), після його можливого падіння, скопіюються і на слейви, що призведе до повного видалення баз. Але навіть так це достатньо ризиковано.

неділя, 24 липня 2016 р.

Redis Basics

Redis (REmote DIctionary Server) - високопродуктивна нереляційна база даних типу ключ-значення, розробку якої наразі фінансує Redis Labs, а раніше - Pivotal Software та VMware. Це програмне забезпечення з відкритим сирцевим кодом написане на мові C. Redis досить зрілий проект і має набір готових біндингів до різноманітних мов програмування.

Redis дуже часто розглядають як заміну Memcached, адже доступ до значень також відбувається по ключу. Проте він, на відміну від останнього, володіє купою переваг, серед яких:
  • Можливість з певною частотою зберігати дані з оперативної в постійну пам'ять. Тож у разі падіння демона дані будуть наявні після рестарту. У останніх версіях Redis є можливість вести лог операцій запису. Щось на зразок бінлогу в MySQL.
  • Більше можливих типів даних, котрі можуть зберігатись. Redis, окрім рядків (strings), підтримує збереження масивів (lists), хеш-таблиць (hash tables), множин (sets), сортованих множин (sorted sets), масиви біт (bitmaps) та HyperLogLog. Останні по-суті базуються на рядках (strings), які мають свою власну семантику. Детальніше про них далі.
  • Реплікація (built-in), кластеризація (Redis Sentinel, Redis Cluster), шардинг (Redis Cluster), висока доступність (Redis Sentinel, Redis Cluster). Цього всього немає в ванільному Memcached, але воно так необхідне при створенні інфраструктур високої доступності.
  • Підтримка транзакцій. Команди можуть бути виконані групою, і у разі невиконання однієї із них - відбудеться повернення на попередній стан. Також команди можна виконувати пакетами (виконуємо пачку команд, потім отримуємо пачку результатів).
  • Підтримка механізму publish/subscribe. Програми, що використовують Redis, можуть створювати іменовані канали і додавати в них повідомлення, а інші програми, відповідно, можуть забирати дані з таких каналів. У моєму розумінні, це щось схоже на черги в RabbitMQ.

неділя, 18 жовтня 2015 р.

Cassandra. Part II: Cluster

Тиждень тому я опублікував першу статтю про базу даних Cassandra. Це була теоретична стаття, у якій переважно було про те як влаштована Cassandra та її особливості. Цього разу я розповім як налаштувати власний кластер Cassandra.

Для побудови кластера будемо використовувати 4 віртуальні машини з такими адресами і хостнеймами:

10.131.75.141  cs-1
10.131.75.142  cs-2
10.131.75.143  cs-3
10.131.75.144  cs-4

Із них і буде складатись кільце кластеру (Token Ring). Отже, створимо ці віртуальні машини та додамо цей список адрес до кожної із них в /etc/hosts. У якості ОС я обрав Ubuntu 14.04. Кількість оперативної пам'яті для кожної віртуальної машини рівна 1 ГБ, що звісно достатньо лише для тестових цілей.

Установлюємо Java:

# add-apt-repository ppa:webupd8team/java
# apt-get update
# apt-get install oracle-java8-installer

# apt-get install oracle-java8-set-default

Та останню версію Cassandra з репозиторіїв DataStax:

# echo "deb http://debian.datastax.com/community stable main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list
# curl -L http://debian.datastax.com/debian/repo_key | sudo apt-key add -

# apt-get update
# aptitude install cassandra
The following NEW packages will be installed:
  cassandra libopts25{a} ntp{a} python-support{a} 
0 packages upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 24.9 MB of archives. After unpacking 34.0 MB will be used.
Do you want to continue? [Y/n/?]

Java та Cassandra, очевидно, необхідні на всіх нодах кластеру. Після установки перевіримо роботу бази, підключившись до неї через CQLSH:

# cqlsh
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 2.2.1 | CQL spec 3.3.0 | Native protocol v4]
Use HELP for help.
cqlsh>