Добрый вечер!

Недавно здесь поднималась тема версионного изменения структуры БД. Среди готовых решений для миграции БД (для .NET-проектов) там упоминался проект ECM7.Migrator, одним из авторов которого я являюсь.

Вчера мы, наконец, отрелизили версию 2.0. Взять новую версию можно на страничке проекта в google code и в галерее пакетов nuget.

Типичная ситуация, стартует проект, под него берут самый простенький сервер, который трудится полгода, проект вырастает и просит большой и злобный сервер.

Обычно ставят на новую железку новую ОС, поднимают софт, настраивают, переносят контент, базы и прочее, меняют DNS и через двое суток выключают старый сервер. Казалось бы простая процедура, сотни раз её делал любой сисадмин. НО, в процессе как показывает практика что-то забывается и уже на боевом сервере нужно делать правки и настройки, тащить старые костыли и адаптировать их на новом месте.

Этот вариант иногда неизбежен, например когда сервера в разных датацентрах. Но если сервера (новый и старый) стоят в соседних стойках, то можно просто перенести ОС на новую железку а старую сразу погасить. О том как это сделать я и напишу небольшую статью-чеклист. Итак поехали!

Для тех, кто не в курсе, миграции — это способ внесения изменений в структуру БД.
Управлять изменениями можно по-разному, но все сводится к работе инструкциями для изменения стуктуры.

Почему миграции это делают наилучшим способом:
1. Автоматизация. Вы можете хранить инструкции в sql-файликах, накатывать их при необходимости. Но это становится дико неудобно, когда встает вопрос о переключении между разными ревизиями (версиями БД), для командной разработки, когда всем разработчикам надо накатить изменения, для развертывания тестового окружения.
2. Rollback (как продолжение первого пункта). Мы можем откатить любую миграцию и получить версию БД на любой момент. Чем это удобно, см. ниже.
3. Идентичность DEV и PROD версий БД. Это очень важно, по крайней мере для меня, быть уверенным в том, что версии DEV, PROD и TEST абсолютно одинаковы. Да, этого можно добиться и другими способами. Но когда именно миграции являются носителями информации о структуре БД, вместе с автоматизацией решать эту задачу становится намного удобнее и проще.

Не буду описывать базовые вещи, можно посмотреть:

• Док по миграциям доктрины 1.2
• Работа с миграциями в symfony
• Описание консольных команд для работы с миграциями в symfony

Когда БД проекта вырастает за пределы трех-пяти таблиц, продолжая при этом постоянно изменяться, на свет рождаются неудобства обмена изменениями между разработчиками. Проблема стара как мир, но инструмента удовлетворяющего мои требования я в ноябре 2009го найти не сумел.

Мои требования к инструменту очень просты:

• Как бы я не издевался над структурой данных в приложении, инструмент должен уметь изменить структуру в другой инсталляции приложения так, чтобы она была идентична моей.
• System requirements: PHP и MySQL — не более того.
• Бесплатность.
• Открытость.

Вот уже четвертый год я являюсь счастливым пользователем ОС Linux. Должен сказать, что до этого, начиная примерно с 1996 года, я был сначала просто пользователем, а потом и убежденным сторонником продуктов Microsoft. Я очень долгое время работал с их ОС, от DOS 6.22 до Windows XP/2003 Server. В сторону Linux я тогда смотрел со стойким недоверием. Но, признаюсь, вникать не хотел, а поверхностно Windows выглядела сильнее. Как говорил мой начальник, «не любил я все эти оккультные вещи с демонами и прочим». В силу специфики работы через мои руки прошли десятки, а то и сотни Windows-машин. Так что все, что я буду хаять тут, выстрадано на опыте :) Скажу также, что стандартные аргументы о безопасности и стабильности в моем случае не особо срабатывали. Умеючи администрировать Windows, можно добиться вполне приемлемой стабильности и безопасности. Windows падала у меня за 10 лет считанные разы. Да, конечно бывали BSODы, но тоже не сильно часто (kernel panic — линкусового аналога BSOD — на своих машинах, правда, не видел ни разу). Заражений вирусами на домашней машине я вспомнить вообще не могу. На работе, как и все, попали под Blaster. Но в целом, все было не так плохо, как об этом говорили.

На закате моей эпохи Windows я работал .Net программистом. Тогда я уже прочитал «Running Linux» и еще какую-то книгу по общей архитектуре Unix-систем. Они потрясли мое мировоззрение :) Я увидел на сколько стройнее и правильнее можно делать вещи. Увидел на сколько корявыми и костылистыми являются некоторые решения Microsoft. В общем, морально я уже был готов. Но в 2005 году Mono все еще было неработоспособной штукой. Помнится, я даже качал с сайта проекта LiveCD с Mono Develop. Но среда рухнула с грохотом при попытке изменить размер какого-то фрейма. Такое средство разработки меня не устраивало. С Linux пришлось отложить до лучших времен. А времена настали, когда я поменял работу, предав .Net в пользу Java. Уж тут то привязок к операционной системе было по минимуму. Так что сам Бог велел. К тому же у меня дома появился отдельный ноутбук, на котором я мог безболезненно для остального человечества экспериментировать. За месяц я настроил до устраивающего меня состояния Kubuntu 6.10. С тех пор я все сильнее раздражался с каждым разом, когда мне приходилось общаться с Windows XP на компьютере жены.

Итак, не холивара ради, а пользы для, посмотрим, что же получает IT-специалист от использования Linux?

В процессе обсуждения онлайн миграций с Щорсом, родились 2 видео с онлайн миграцией OpenVZ контейнеров между нодами.

В первом видео мигрирует контейнер в котором запущен nginx, к нему идут запросы из ab в два потока на /status, запросы пишутся в лог, т.е. размер занятого места динамически изменяется.



Во втором мигрирует контейнер в котором происходит копирование таблицы внутри mysql'я (select into blabla2 select * from blabla1), размер базы 350мб, 850к записей.



Основная хост машина — core quad q6600 с вистой, внутри запущены VMware виртуалки, а в них уже Linux с OpenVZ.

3е — из виртуалки на vmware в виртуалку hyper-v, разные физические машины, через свитч длинк 100мбит

Эта статья для тех кто хочет перейти с с файловой системы Ext3 на Ext4, при этом сохранить все свои файлы и каталоги. Постараюсь описать наиболее общие ошибки возникающие в процессе миграции с Ext3 на Ext4, не устанавливая систему заново.

Основания для перехода.

Объяснение преимуществ и недостатком Ext4 выходит за рамки этой статьи (воспользуйтесь поиском по хабру — тут это есть). Если вы не страдаете от ограничений накладываемых Ext3 и не готовы рискнуть и просто так перейти на Ext4 то очень хорошо подумайте, а нужно ли это вам? ;) С другой стороны, перейдя на Ext4 вы можете почувствовать прирост производительности вашей файловой системы и увеличить её надёжность, при этом не понеся никаких накладных расходов ;)

Привет всем.
Извините что сюда пишу, но я просто в тупике и не знаю что делать, гугль и знакомые мегашаманы разводят руками:
— есть Windows 2003 Server 32 bit.
— с него надо перенести всех пользователей с паролями на Windows 2003 Server 64 bit.
— Pointdev Ideal Migration переносит пользователей, но без паролей.

Вариантом решения было бы:
— просто перенести всех пользователей
— расшифровать их пароли и вбить руками.

Windows-шаманы помогите!

upd Спустя месяц. Решением было SamInside. x64 решили снести и поставить нормальную.

Сегодня (13 июля 2007) ровно три года с момента релиза PHP5. За эти три года он (PHP5) приобрел множество улучшений по сравнению с PHP4. PHP5 быстрый, стабильный, а поскольку на подходе уже PHP6, то 4-я ветка PHP больше не будет развиваться.

Команда разработчиков PHP объявляет, что поддержка PHP4 продлится только до конца текущего года. После 31 декабря 2007 больше не будет выходить релизов PHP4.4. «Мы будем продолжать выпускать фиксы безопасности "от случая к случаю" до 8 августа 2008 года. Пожалуйста, используйте время до конца года, чтобы сделать ваши приложения совместимыми с PHP5.»

В качестве документации по миграции с PHP4 на PHP5 разработчики предлагают ознакомиться со следующим документом: http://www.php.net/manual/en/migration5.…

via http://www.php.net

P.S.: Хостеры волнуются? (: