Я здесь впервые. Недавно я стал системным администратором в компании, и мое недавнее задание - создавать более удобные среды разработки для наших разработчиков. До сих пор наши разработчики подключались к нашему удаленному компьютеру, копировали производственный код, выполняли восстановление производственной базы данных и исправляли настройки apache vhost, а затем начинали разработку. Большая часть разработки происходит с помощью шпатлевки, что чрезвычайно утомительно.
Совсем недавно я узнал о Vagrant и был им поражен. Поэтому я быстро установил простой стек LAMP, который могут использовать наши разработчики. Однако моя самая большая сложность на данном этапе - это как настроить prod db, например, среду mysql. Наша база данных имеет размер около 7 ГБ, и нет смысла загружать ее, а затем запускать на вашей бродячей виртуальной машине.
Я уверен, что это обычная проблема, с которой раньше сталкивались многие системные администраторы. Как мне настроить производственную базу данных разработчиков начиная с Vagrant, не передавая этот массивный дамп данных.
В основном есть среда разработки. В прошлый раз, когда я работал с БОЛЬШИМИ базами данных (а если серьезно, 7 ГБ - это КРОШЕЧНО), комплект разработчика был около 10000 ГБ. Мы использовали один из трех серверов, которые у нас были - резервный на случай реальных катастроф - в качестве модуля разработки, готового к уничтожению, если операционному отделу это понадобится.
Сейчас я работаю над более мелкими вещами (всего около 300 ГБ на базу данных), и серьезно, у нас есть центральный пул SQL-серверов разработки, которые используют разработчики.
Вам нужна подходящая среда для разработки и тестирования - и даже с такой небольшой базой данных, как ваша, это немного проблематично. Подождите, пока у вас не будет хотя бы МАЛЕНЬКИЕ БД. 7 ГБ все еще крошечный.
Мы решили эту проблему. Мы начали использовать реактивные брюки, инструмент шардинга MySQL с открытым исходным кодом от tumblr. Отсюда мы поняли, что нам не нужна немедленная синхронизация на определенный момент времени, которую обеспечивают реактивные брюки, поэтому мы дополнительно оптимизировали ночное резервное копирование продукции, хранящейся в виде файла. Мы сжимаем этот файл с помощью lzop, а затем отправляем его на машины разработки через netcat. Время от начала до конца для БД 20 ГБ? 4 минуты. Помощь SSD.
Наши разработчики используют меньший набор данных, чем тот, который находится в производстве. Все таблицы одинаковы, но данные не являются копией набора оперативных данных. Это будет зависеть от ваших потребностей, но для нас это отличный способ работы.
В то время как ваша производственная БД составляет 7 ГБ - насколько она велика без данных о деятельности? (Данные о деятельности - это данные, которые добавляются пользователями или программами, тогда как справочные данные - это данные, которые необходимо отключить для других целей. Примером может служить запись адреса - название улицы и адрес - это данные о деятельности, поскольку они были добавлены. кем-то. Но тип адреса - это справочные данные - так как они должны были выбирать из "Дом", "Работа" или "Другое".)
Имея только схему и справочные данные, не должно быть слишком много для создания нового экземпляра с каждой средой. По какой-то причине, если это так, то в чем проблема с использованием разработчиками базы данных "Dev"?