Монгу используем 2.6.6
Восстанавливаю всегда в пустую базу.
noIndexRestore + потом руками — в чём смысл? А если я не знаю какие индексы надо создавать. Ковыряться в дампе и искать их?
А что насчёт автоматизации? Мне надо автоматически раскидывать дампы на разные окружения. И я не могу сделать нормальный restore.
А как же 3 вида админов: кто не делает бэкапы, кто делает и тот кто проверяет :)
Вставлю свои 5 копеек. Может кто-то сталкивался и подскажет как решать вопрос.
Дано: mongodb cluster: 3 config server, 4 shard, каждый shard это реплика из 3х серверов + арбитр.
Шардирования на уровне коллекций нет. У нас много мелких баз и они равномерно размазаны по шардам.
Кластер приложения. Рядом с каждой нодой стоит router.
Баг 1.
Как воспроизвести точно не знаю. Но сценарий такой:
1. Создаём базу main (допустим она попала на sh 001)
2. Пишем туда что-нибудь
3. Удаляем базу (да. нам иногда надо снести базу полностью чтоб просто её пересоздать)
4. Создаём её опять (для примера, она попадает на sh 002)
И вот теперь проблема: роутер через который это делали, знает что база на sh 002. а остальные роутеры видимо хранят кэш и думают что база на sh 001. Последствия катастрофические: пишем документ — ок. тут же читаем — даже базы нету. Или два процесса пишут свои данные в разные базы main.
Баг 2.
Я считаю его практически блокером: отсутствие нормального бэкапа. Да, я читал все мануалы, да, я знаю про mms. Сделать консистентный бэкап — та ещё задача. Но я не придираюсь. Я готов и на «хоть какой-нибудь бэкап кое-как».
Сценарий:
1. Для бэкапа максимально одновременно я блокирую по одному слэйву из каждого шарда на запись.
2. Делаю mongodump (отрабатывает успешно) со всех шардов.
Восстановление: делаю mongorestore — в 70% я получаю duplicate error при попытке построить индекс в конце восстановления. Пробовал и с oplog, и без. Кстати, индекс применяется ДО того как oplog накатывается. Возможно, этот oplog и исправил бы проблему.
Вывод: бэкап вы сделаете. А вот восстановить — как повезёт.
Тут есть ещё разные варианты: я тестировал бэкап через LVM + тянуть прямо с файлов, а не из процесса. Работает стабильнее. Вероятно придётся перейти на этот способ.
Баг 3.
Мутный баг. Иногда просто нельзя удалить коллекцию или базу. Помогает рестарт роутеров.
И это я только с позиции админа. С позицию девелопера я лучше промолчу.
В отличии от Супермена, Бэтмэну нужно потратить время на то, чтобы этот криптонит взять и ещё умудриться напасть на Супермена с ним.
Супермен же, в свою очередь, может держаться на расстоянии 100 км и при первом же намёке, что Бэт задумал что-то неладное, скинуть на него целую гору. В данном случае, Супермен — это НЕ сбалансированный персонаж. Имба. И всё тут.
Возможно вам поможет паттерн wrapped-cookbook: я его использую гораздо шире, чем даже описано в комьюнити.
Я считаю библиотечными все комьюнити кукбуки, т.к. они не знают конкретно моей инфраструктуры и для меня, по сути, представляют собой набор библиотечных методов.
Во врапере я меняю поведение кукбука так, как мне надо: переписываю аттрибуты, вызываю или не вызываю рецепты, дописываю своё.
После исправлений в комьюнити кукбуке я делаю:
Мне не понравился в базе capistrano, который очень сильно заточен под rails и я взял его модуль sshkit и сделал более generic библиотеку. Будет время — выложу на github. Идея проста: выполнять rake-таски на всех серверах как на одном (похож на python-овский fabric). Но, разумеется, ему нужен ssh.
Если у вас windows, то нужен хотя бы cygwin.
Но это всё слишком серьёзный подход. Возможно, и должен, вас заинтересует rundeck.
Эти вещи хорошо решают императивные задачи: что запустить, что сделать.
Configuration Management Systems (Chef, Puppet, Ansible) не всегда со старта могут быть полезны. Поверьте, я много работал, с тем же Chef-ом. Они требуют со старта много знаний, и могут потратить больше времени, чем принести пользы.
Ну и холивара, ради: Моё первое правило при работе с автоматизацией под Windows:
Изменения определены в xml — мерзость какая, xml совсем не дружелюбный для такого (ИМХО).
Проще уже было бы, если бы были plain-text-sql файлы.
Миграций может быть очень много и размеры их могут быть очень большими (есть реальный опыт).
Такие штуки лучше встраивать в приложение, а не в сборку: сервис поднялся и, если позволено, обновил базу.
Задача:
Имеется продукт, основная ветка.
Команда делает 5-6 вещей (баг фиксы, изменения поведения, новые фичи и т.д.) одновременно, тестят их по готовности и вместе (проверить финальную интеграцию).
На момент релиза (сроки которые могут, внезапно (с), меняться) нужно выпустить несколько фич:
какие-то ещё не доделаны, 5 готовы, но выпустить надо только 4, от последней отказались. Ещё 2 перенесли на следующий релиз.
Вопрос: как это сделать с SVN, чтобы разработчики не заплакали кровавыми слезами?
Git всегда проверяет целостность. commit id берётся из контрольных сумм объектов. К тому же, файлы в репозиторий добавляются не из рабочей копии, как можно сначала подумать, а из индекса. а эта область лежит целиком в папке .git. Эта папка в свою очередь является «собственностью» git-a. И если кто-то что-то там в ней будет менять вслед за git — ничего удивительного тут нет.
Git пишет «карта», программа перетирает «В*ЧНОСТЬ».
Естественно, git задаст резонный вопрос:
«Где карта, Билли!»
Кстати, вброшу ка я: jgit некорректно работает с git и там много багов. Это скорее всего основная проблема.
Сам лично словил тонну глюков, когда использова maven-jgitflow-plugin. Обновление jgit частично помогло. Было это 3 месяца назад. Как сейчас обстоят дела я не знаю.
Пользуюсь Chef.
По началу казалось, что разработка инфраструктуры с chef — это не просто долго, это вечность!
Когда побольше разобрался в нём — дела пошли куда быстрее.
Хотя, от этого он не перестаёт быть сложным и медленным (в плане разработки).
Однако, в защиту Chef могу сказать, что сообщество очень быстро адаптируется и меняется в лучшую сторону.
Появляется всё больше удобных инструментов, которые существенно ускоряют процесс разработки. Потихоньку вырабатываются best practice/chef patterns для работы с cookbooks. Качество community cookbooks (они же library cookbooks) быстро растёт. К моменту выхода chef 12 картина должна существенно улучшиться.
Мой «джентльменский набор» сейчас такой: Chef Zero, Test-Kitchen, Berkshelf, Docker (test kitchen driver for docker), chefspec, bats, serverspec.
Основная причина по которой остаюсь на Chef это orchestration: работа с кластерами, зависимости между серверами.
Конечно, есть тот же etcd который может частично решить проблему.
А вообще, Docker мне очень понравился, отличная идея, отличный проект. Подумываю над тем, чтобы серверами-болванками управлять через Chef, раскатывать проект через Docker (есть cookbook: github.com/bflad/chef-docker), настраивать опять же Chef-ом или каким-нибудь другим сервисом.
Очень негативно восприняли такие возможности.
Мол, ничего хорошего от этого ждать не приходится. Ща поменяет лишний курсор строчку где не надо и на проде всё ляжет…
Вообще, я даже смирился, пусть делают как хотят/как им удобнее.
Лично я испытываю настоящее наслаждение, когда немного подучил эту фишку и уже активно ею пользуюсь.
Что-то в скрипте/коде поменять можно в 5-10 нажатий на клаве, а не Find&Replace->Set Regexp Mode-> [write regexp -> replace one -> ctrl+z -> fix regexp].many-times -> replace-all with regexp.
По каким параметрам?
Вы сможете меня убедить перейти на hg?
Правда, без подтекста и намёка на холивар спрашиваю. Сколько раз хотел услышать внятные комментарии, где бы на пальцах объяснили.
И тот, и другой — хороши. Если у вас есть серьёзный опыт и там, и там — расскажите про «hg лучше git»
Восстанавливаю всегда в пустую базу.
noIndexRestore + потом руками — в чём смысл? А если я не знаю какие индексы надо создавать. Ковыряться в дампе и искать их?
А что насчёт автоматизации? Мне надо автоматически раскидывать дампы на разные окружения. И я не могу сделать нормальный restore.
А как же 3 вида админов: кто не делает бэкапы, кто делает и тот кто проверяет :)
Дано: mongodb cluster: 3 config server, 4 shard, каждый shard это реплика из 3х серверов + арбитр.
Шардирования на уровне коллекций нет. У нас много мелких баз и они равномерно размазаны по шардам.
Кластер приложения. Рядом с каждой нодой стоит router.
Баг 1.
Как воспроизвести точно не знаю. Но сценарий такой:
1. Создаём базу main (допустим она попала на sh 001)
2. Пишем туда что-нибудь
3. Удаляем базу (да. нам иногда надо снести базу полностью чтоб просто её пересоздать)
4. Создаём её опять (для примера, она попадает на sh 002)
И вот теперь проблема: роутер через который это делали, знает что база на sh 002. а остальные роутеры видимо хранят кэш и думают что база на sh 001. Последствия катастрофические: пишем документ — ок. тут же читаем — даже базы нету. Или два процесса пишут свои данные в разные базы main.
Баг 2.
Я считаю его практически блокером: отсутствие нормального бэкапа. Да, я читал все мануалы, да, я знаю про mms. Сделать консистентный бэкап — та ещё задача. Но я не придираюсь. Я готов и на «хоть какой-нибудь бэкап кое-как».
Сценарий:
1. Для бэкапа максимально одновременно я блокирую по одному слэйву из каждого шарда на запись.
2. Делаю mongodump (отрабатывает успешно) со всех шардов.
Восстановление: делаю mongorestore — в 70% я получаю duplicate error при попытке построить индекс в конце восстановления. Пробовал и с oplog, и без. Кстати, индекс применяется ДО того как oplog накатывается. Возможно, этот oplog и исправил бы проблему.
Вывод: бэкап вы сделаете. А вот восстановить — как повезёт.
Тут есть ещё разные варианты: я тестировал бэкап через LVM + тянуть прямо с файлов, а не из процесса. Работает стабильнее. Вероятно придётся перейти на этот способ.
Баг 3.
Мутный баг. Иногда просто нельзя удалить коллекцию или базу. Помогает рестарт роутеров.
И это я только с позиции админа. С позицию девелопера я лучше промолчу.
У вас там наверное трафик с этого сервера большой идёт. Каждый запуск chef-client перекачивает этот файл.
И мне не совсем понятен вопрос производительности? Какая разница 100, 1000, 10000? Точнее, она там есть, но тогда причём тут руби?
Нигде ничего не сломалось. ЧЯДНТ?
Супермен же, в свою очередь, может держаться на расстоянии 100 км и при первом же намёке, что Бэт задумал что-то неладное, скинуть на него целую гору. В данном случае, Супермен — это НЕ сбалансированный персонаж. Имба. И всё тут.
Я считаю библиотечными все комьюнити кукбуки, т.к. они не знают конкретно моей инфраструктуры и для меня, по сути, представляют собой набор библиотечных методов.
Во врапере я меняю поведение кукбука так, как мне надо: переписываю аттрибуты, вызываю или не вызываю рецепты, дописываю своё.
После исправлений в комьюнити кукбуке я делаю:
и смотрю, что получилось
Если у вас windows, то нужен хотя бы cygwin.
Но это всё слишком серьёзный подход. Возможно,
и должен,вас заинтересует rundeck.Эти вещи хорошо решают императивные задачи: что запустить, что сделать.
Configuration Management Systems (Chef, Puppet, Ansible) не всегда со старта могут быть полезны. Поверьте, я много работал, с тем же Chef-ом. Они требуют со старта много знаний, и могут потратить больше времени, чем принести пользы.
jsirex.livejournal.com/27049.html
Требует силы как настоящий 10-минутный спарринг на полную силу.
Вот, любимый мной, Dragonforce (играю, правда, не я; мне пока скилов не хватает) 200 bpm. 800 ударов в минуту.
Это ооочень сложно. А на 99% вообще нереально.
Проще уже было бы, если бы были plain-text-sql файлы.
Миграций может быть очень много и размеры их могут быть очень большими (есть реальный опыт).
Такие штуки лучше встраивать в приложение, а не в сборку: сервис поднялся и, если позволено, обновил базу.
Рекомендую посмотреть на dbmaintain.org/overview.html
Я его заливал на github, добавлял фазу preprocessing:
github.com/jsirex/dbmaintain/tree/preproccessing
Имеется продукт, основная ветка.
Команда делает 5-6 вещей (баг фиксы, изменения поведения, новые фичи и т.д.) одновременно, тестят их по готовности и вместе (проверить финальную интеграцию).
На момент релиза (сроки которые могут, внезапно (с), меняться) нужно выпустить несколько фич:
какие-то ещё не доделаны, 5 готовы, но выпустить надо только 4, от последней отказались. Ещё 2 перенесли на следующий релиз.
Вопрос: как это сделать с SVN, чтобы разработчики не заплакали кровавыми слезами?
Git пишет «карта», программа перетирает «В*ЧНОСТЬ».
Естественно, git задаст резонный вопрос:
«Где карта, Билли!»
Кстати, вброшу ка я: jgit некорректно работает с git и там много багов. Это скорее всего основная проблема.
Сам лично словил тонну глюков, когда использова maven-jgitflow-plugin. Обновление jgit частично помогло. Было это 3 месяца назад. Как сейчас обстоят дела я не знаю.
По началу казалось, что разработка инфраструктуры с chef — это не просто долго, это вечность!
Когда побольше разобрался в нём — дела пошли куда быстрее.
Хотя, от этого он не перестаёт быть сложным и медленным (в плане разработки).
Однако, в защиту Chef могу сказать, что сообщество очень быстро адаптируется и меняется в лучшую сторону.
Появляется всё больше удобных инструментов, которые существенно ускоряют процесс разработки. Потихоньку вырабатываются best practice/chef patterns для работы с cookbooks. Качество community cookbooks (они же library cookbooks) быстро растёт. К моменту выхода chef 12 картина должна существенно улучшиться.
Мой «джентльменский набор» сейчас такой: Chef Zero, Test-Kitchen, Berkshelf, Docker (test kitchen driver for docker), chefspec, bats, serverspec.
Основная причина по которой остаюсь на Chef это orchestration: работа с кластерами, зависимости между серверами.
Конечно, есть тот же etcd который может частично решить проблему.
А вообще, Docker мне очень понравился, отличная идея, отличный проект. Подумываю над тем, чтобы серверами-болванками управлять через Chef, раскатывать проект через Docker (есть cookbook: github.com/bflad/chef-docker), настраивать опять же Chef-ом или каким-нибудь другим сервисом.
Очень негативно восприняли такие возможности.
Мол, ничего хорошего от этого ждать не приходится. Ща поменяет лишний курсор строчку где не надо и на проде всё ляжет…
Вообще, я даже смирился, пусть делают как хотят/как им удобнее.
Лично я испытываю настоящее наслаждение, когда немного подучил эту фишку и уже активно ею пользуюсь.
Что-то в скрипте/коде поменять можно в 5-10 нажатий на клаве, а не Find&Replace->Set Regexp Mode-> [write regexp -> replace one -> ctrl+z -> fix regexp].many-times -> replace-all with regexp.
Вы сможете меня убедить перейти на hg?
Правда, без подтекста и намёка на холивар спрашиваю. Сколько раз хотел услышать внятные комментарии, где бы на пальцах объяснили.
И тот, и другой — хороши. Если у вас есть серьёзный опыт и там, и там — расскажите про «hg лучше git»