Во-первых, по причинам безопасности и другим причинам я не смогу использовать S3 или другое подобное решение.
У меня есть сервер хранения, на котором у меня был диск объемом 1 ТБ. У меня есть сервер Mysql. Наши компьютеры постоянно начинают добавлять данные в базу данных со скоростью около 1 ГБ в час. Так что примерно через месяц у меня закончится память.
Я хочу иметь возможность добавлять новые жесткие диски и подключать другие системы к сети и связывать хранилище. например: если я свяжу еще одну систему размером 1 ТБ, я хочу, чтобы доступное хранилище для MySQL db составляло 2 ТБ. то есть: распределены по двум системам.
Вариант балансировки нагрузки тоже был бы отличным. Т.е. Сервер MySQL на обеих системах должен иметь доступ к базе данных.
Как я могу этого добиться (предпочтительны решения с открытым исходным кодом).
Запускайте новый сервер MySQL каждый раз, когда вы почти полностью заполнены. Перепишите клиентское программное обеспечение, чтобы получить доступ к правильному серверу MySQL в зависимости от даты, в которой они нуждаются.
Конечно, вам нужны данные, которые можно разделить по отметке даты. Запросы, которые должны охватывать серверы, должны будут запросить каждый из них и объединить результаты. Присоединиться будет сложно. Однако, учитывая, что вам нужно бесконечное хранилище, вам придется пойти на компромисс в другом месте. Вы не можете иметь бесконечное хранилище и по-прежнему использовать MySQL.
Это отлично подходит для любой базы данных, в которой хранятся журналы или другие архивные данные, которые накапливаются, но не меняются. Такие данные также легко разделить по метке даты.
Это схема, которую Twitter использовал изначально. У них был один сервер MySQL для архивирования старых твитов; когда он заполнился, они запустили новый сервер. Поиск по запросу «Все, что твитнул пользователь X» отправлял запрос на каждый сервер, начиная с самого нового и заканчивая сервером, на котором хранился архив при создании учетной записи. Все старые серверы были настроены с репликами только для чтения; столько, сколько нужно для выполнения того количества запросов, которые им приходилось обрабатывать. Таким образом, система может масштабироваться в обоих направлениях: увеличивать масштаб (переход к следующему серверу для большего пространства) и горизонтальный масштаб (добавление дополнительных реплик для большей нагрузки).
Однако в конечном итоге вы обнаружите, что реляционная база данных - ужасный выбор для хранения журналов или других архивных данных, которые накапливаются, но не меняются. Вставка нескольких строк за один раз включает блокировку, которая замедляет процесс и является расточительной, если вы можете гарантировать, что все данные будут «записаны один раз».
Twitter в конечном итоге перешел на другую технологию хранения, и вы обнаружите, что хотите сделать то же самое. Вам нужно будет выбрать систему, рассчитанную на бесконечный рост за счет добавления новых машин. Затем система отслеживает, какие машины хранят какие данные, и даже если вы отправляете свои запросы на главный узел, она делает правильные действия, чтобы найти результаты. К таким системам относятся: MongoDB, Hbase, CouchDB и, кажется, Riak.
Если ваши данные не могут быть легко разделены, этот ответ вам не поможет. В этом случае вам нужно будет подумать о добавлении все большего объема хранилища в существующую систему. Одним из решений является добавление большого количества дисков в сеть SAN и подключение их к машине.
Я сделаю удар здесь и предположу, что вы на самом деле не заинтересованы в объединении хранилища, подключенного к нескольким различным физическим машинам, как указано в вашем вопросе, а просто хотите иметь возможность наращивать решение хранилища на одном хосте как ваши потребности в хранении растут.
Если это так, я предлагаю вам очень внимательно посмотреть на ZFS. Он разработан конкретно чтобы иметь возможность справляться с подобными ситуациями (среди прочего), и это файловая система общего назначения.
Там есть реализация Linux что, к сожалению, известно, что все еще испытывает икоту при определенных сценариях использования, или, если вы предпочитаете стабильную работу, вы можете разместить файлы, например, хост FreeBSD и совместно использовать их через NFS или SMB, или даже просто запустить базу данных в системе FreeBSD. Я не вижу, чтобы вы указывали ОС, но ваше упоминание MySQL и предпочтение решений с открытым исходным кодом действительно указывает на * nix. Главное предостережение заключается в том, что вы действительно хотите перейти на 64-разрядную версию и иметь много оперативной памяти, чтобы ZFS была действительно счастлива, но сегодня это не должно вызывать столько беспокойства, как это было раньше.
В ZFS вы работаете с так называемыми zpools, которые в основном похожи на то, что вы иначе могли бы назвать файловыми системами. Каждый zpool состоит из одного или нескольких vdev, каждый из которых, в свою очередь, состоит из одного или нескольких физических (или логических) устройств. На всем zpool вы можете создать то, что в терминологии ZFS называется файловыми системами (отдельно монтируемые иерархии). Добавляя дополнительные физические устройства к новому или существующему vdev, файловая система автоматически делает доступной и будет использовать полученную дополнительную емкость хранилища (если таковая имеется; например, если вы добавляете зеркальное устройство к vdev, дополнительное пространство для хранения не увеличивается, хотя вы получить избыточность). Добавление устройств - это полностью прозрачная онлайн-операция; следовательно, если само устройство хранения поддерживает «горячую» замену, можно создать решение для хранения, которое не будет иметь простоев во время увеличения емкости.
Вы можете рассмотреть возможность использования LVM в качестве файловой системы, но это подразумевает изменение вашей файловой системы, что может иметь решающее значение. хорошее объяснение здесь: https://wiki.ubuntu.com/Lvm
Если вы буквально получаете гигабайты в час в непрерывном, нескончаемом потоке, тогда выбор дизайна ограничен. Вы можете поставить в очередь все новые данные на одном компьютере, который передает их в базу данных MySQL. Таким образом, вы можете отключить базу данных MySQL для обслуживания: для добавления дисков, подключения к новым сетям SAN и так далее.
Машина очереди предоставит вам столько времени на обслуживание, сколько она может хранить данные, но помните, что при повторном подключении к серверу MySQL ей потребуется наверстать упущенное. Например, вы можете обнаружить, что если машина очереди используется для хранения 4 часов невыполненной работы, может потребоваться 8 часов, чтобы очистить эту невыполненную работу на сервере MySQL; теперь он выполняет вдвое больше INSERT.
Совет: если вы создадите такую машину очереди, вам будет полезно настроить панель мониторинга, которая записывает, как долго пакеты ожидают, прежде чем они будут отправлены на сервер MySQL. Статистика по времени ожидания поможет вам управлять системой. Например, если вы построите график 7-дневных скользящих данных, значение 90 процентилей будет хорошим индикатором общего состояния здоровья. Когда это значение высокое, будьте бдительны. Что-то не так. Вы можете построить график 90 процентилей для каждой недели данных; это позволит вам увидеть, становитесь ли вы лучше или хуже со временем.