Pull to refresh
  • by relevance
  • by date
  • by rating

Путеводитель по репликации баз данных

High performance *Data recovery *Database Administration *Data storage *
Повторяться, но каждый раз по-новому – разве не это есть искусство?

Станислав Ежи Лец, из книги «Непричёсанные мысли»

Словарь определяет репликацию как процесс поддержания двух (или более) наборов данных в согласованном состоянии. Что такое «согласованное состояние наборов данных» – отдельный большой вопрос, поэтому переформулируем определение проще: процесс изменения одного набора данных, называемого репликой, в ответ на изменения другого набора данных, называемого основным. Совсем не обязательно наборы при этом будут одинаковыми.



Поддержка репликации баз данных – одна из важнейших задач администратора: почти у каждой сколько-нибудь важной базы данных есть реплика, а то и не одна.

Среди задач, решаемых репликацией, можно назвать как минимум

  • поддержку резервной базы данных на случай потери основной;
  • снижение нагрузки на базу за счёт переноса части запросов на реплики;
  • перенос данных в архивные или аналитические системы.

В этой статье я расскажу о видах репликации и о том, какие задачи решает каждый вид репликации.
Читать дальше →
Total votes 9: ↑8 and ↓1 +7
Views 25K
Comments 11

Траблшутинг DRBD9 в LINSTOR

System administration **nix *Data storage *
Tutorial


За последние несколько лет плотной работы с LINSTOR и DRBD9 у меня накопилось достаточное количество проблем и рецептов решения для них, что мне захотелось оформить их в небольшую статью. Не уверен что они полностью совпадут с вашими случаями, но теперь вы хотя бы сможете понять механику работы с DRBD9, а именно, самую неприятную его часть — траблшутинг.


Информации по данному поводу в интернете немного, так что если вы используете или планируете использовать LINSTOR, уверен рано-или поздно вам эта информация может пригодиться.

Читать дальше →
Total votes 4: ↑4 and ↓0 +4
Views 1.2K
Comments 14

Таков путь! Эволюция бэкапов в Timeweb: от rsync до ZFS

Timeweb corporate blog System administration *
Мы постарались кратко описать путь, который прошла команда Timeweb за 10 лет: от rsync, LVM и DRBD до ZFS. Эта статья будет полезна тем, кто занимается серверной масштабируемой инфраструктурой, планирует делать бэкапы и заботится о бесперебойной работе систем.

image

Расскажем о:

  • rsync (remote synchronization)
  • DRBD (Distributed Replicated Block Device)
  • инкрементальные бэкапы под DRBD с помощью LVM
  • DRBD + ThinLVM
  • ZFS (Zettabyte File System)
Читать дальше →
Total votes 26: ↑24 and ↓2 +22
Views 8.1K
Comments 22

Управление кластерным хранилищем с помощью LINSTOR

Фактор груп corporate blog Open source *SAN *Data storage *
Translation
Tutorial

Электронное хранилище

LINSTOR​​ - это инструмент для автоматизированного управления кластерами, который позволяет упростить управление DRBD​ и предлагает широкий спектр функций, включая резервирование и моментальные снимки.

LINSTOR​​ - это программное обеспечение с открытым исходным кодом, предназначенное для управления блочными устройствами хранения в больших кластерах Linux серверов. Оно упрощает развертывание хранилища высокой доступности с помощью распределенного реплицированного блочного устройства версии 9 (DRBD​ 9), динамически резервирует хранилище и упрощает управление посредством интеграции с Kubernetes, Docker, OpenStack, OpenNebula, OpenShift и т.д. Кроме того, LINSTOR​​ может обеспечивать высокую доступность с помощью DRBD​​. В этой статье я рассмотрю настройку и работу этого инструмента.

На первый взгляд, автоматизация хранения данных не кажется сложной задачей: уже давно создания, расширения и удаления томов хранилища не ограничиваются объемом отдельных устройств хранения или объемом и положением слоев или разделов, созданных на устройствах хранения. Такие технологии, как диспетчер логических томов (LVM) или файловая система Zetabyte (ZFS), уже давно позволяют управлять пулами хранения, в которых можно легко создавать или удалять практически неограниченное количество томов хранилища любых размеров.

Что трудного в том, чтобы автоматизировать такие рутинные задачи с помощью нескольких скриптов? Но дело в том, что при автоматизации необходимо уделять внимание мельчайшим деталям, поскольку этот процесс содержит много потенциальных ловушек для администратора. Какие-то мелкие моменты, которые могут быть не заметны при ручном администрировании, легко могут привести к проблемам в автоматизации – например, когда файлы устройств еще не существуют в файловой системе /dev, хотя соответствующая команда для создания тома уже сообщила о завершении, или если вы хотите удалить не смонтированные тома, которые используются подсистемой udev. Если дополнительно требуется централизованное управление целым кластером, а не только одной системой, становится ясно, что несколько готовых скриптов не справляются с этой задачей.

Читать далее
Total votes 2: ↑2 and ↓0 +2
Views 793
Comments 1

Зеркало здесь, зеркало там: сетевая репликация дисков под Windows

RUVDS.com corporate blog System administration *IT Infrastructure *Backup *Data storage *
Tutorial
Однажды на моём компьютере сгорел блок питания. С дымом, шумом, и прочими спецэффектами. Жёсткий диск тоже не выжил.

К счастью, там не было ничего ценного. Но я в очередной раз убедился, что RAID-массив не всегда помогает, т.к. может погибнуть вместе с компьютером.

Поэтому лучше, если копия данных будет находиться на другом компьютере. И хорошо, если она будет максимально свежей, чтобы в случае аварии продолжить работу с прерванного места.

Такие решения есть для Linux и FreeBSD — DRBD и HAST. Они позволяют реплицировать блочные устройства хранения по сети. То есть, создать что-то вроде RAID-1, где «половинки» дискового массива находятся на разных компьютерах. Теперь такое решение есть и для Windows.


Читать дальше →
Total votes 43: ↑42 and ↓1 +41
Views 7.3K
Comments 54
2