On 12/04/2018 9:47 AM, tango ward wrote:
Hi Mike,

Thanks for the advice.

May I ask as well, on Django side, since we have already an existing system, how should I adjust the fields that are existing from the dump file to the Django? Should I just add fields in models.py?

Treat that as a separate task. You can do it before the migration or after. I would preferdo it afterwards because I am more comfortable with Postgres. And I suspect Postgres will be a better fit with Django.

However, I'm not sure what you mean exactly by adjusting fields. Your last question above indicates you want to change the schema in an existing Django project. You need to consider when the fields need to be changed in the context of real-world pressures from your production system users. It might need to be sooner rather than later and that may force adjustments prior to the move to Postgres.

If there are problems with the existing MySQL system it would be best to fix them before switching.

The bottom line is that preparations and testing for the move has to happen in parallel with ongoing support and maintenance and possibly ongoing development of the production system. When you are ready to switch and happy that it will go like clockwork the actual switch can be scheduled as a definable task in the ongoing workflow. All developers will have to switch at the same time - or prior if they can have access to your completed scripts for their personal development databases.



On Thu, Apr 12, 2018 at 6:42 AM, Mike Dewhirst <mi...@dewhirst.com.au <mailto:mi...@dewhirst.com.au>> wrote:

    On 11/04/2018 11:40 PM, tango ward wrote:

        Hi there,

        This will be my first time to migrate a database in my first
        programming job. I checked the dump file today and load it in
        MySQL benchmark to view the ERD. The database that I need to
        migrate has 48 tables and has existing data already.

        I would like to know what are the things that I need to do
        first. I'm gonna test the migration first in my local machine
        before bringing it to live production. I am currently reading

        Any suggestions will be highly appreciated.

    1. Do the migration locally

    2. Devise some repeatable automated success tests to prove the
    migration works

    3. Set up a new VM as an exact duplicate production machine
    running MySQL. Use your hosts file to put its IP address somewhere
    else than the DNS points to. Beware that ACLs often use IP
    addresses rather than host names.

    4. Do the migrations and run the tests on the duplicate machine.
    Debug as necessary.

    5. Announce to users that the system is going down for planned

    6. Remove your hosts file adjustment so your system is back to
    looking at the real production machine

    7. Take production off-line and do a pre-migration dump or backup
    from which you can restore if things go wrong

    8. Do the migration, run the tests then restore service

    I have done such things in the distant past but not recently. I
    may have forgotten something but in my opinion items 5 and 7 above
    are super critical.

    Good luck


-- You received this message because you are subscribed to the
        Google Groups "Django users" group.
        To unsubscribe from this group and stop receiving emails from
        it, send an email to django-users+unsubscr...@googlegroups.com
        To post to this group, send email to
        Visit this group at
        To view this discussion on the web visit
        For more options, visit https://groups.google.com/d/optout

You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to