Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • Devin Gleason Lambert 27 posts 89 karma points
    Apr 29, 2016 @ 14:35
    Devin Gleason Lambert
    0

    Manually triggering db upgrade

    I am in the process of upgrading from 6.1.1. to 7.4.3 and I am doing it in a separate branch in TFS and a clone of our db as of about a week ago. my question is, once I am done migrating all the code, and am happy with the state of the upgrade, can I take a current clone of the db and remigrate just the db and refresh the indexes and umbraco.config and I can use this as the new prod db.

    Thoughts?

    Thanks Again, Devin

  • Sebastiaan Janssen 5044 posts 15475 karma points MVP admin hq
    Apr 29, 2016 @ 19:45
    Sebastiaan Janssen
    0

    Yes, you should be able to; make sure to set the version in your web.config back to 6.1.1 and make sure that the umbracoMigrations table does not have version 7.4.3 in it (but that table doesn't exist on 6.1.1 so that should not be a problem).

    For a more detailed look into how upgrades work, give the first half of this blog post a read: https://cultiv.nl/blog/how-to-diagnose-umbraco-upgrade-problems.

  • Sebastiaan Janssen 5044 posts 15475 karma points MVP admin hq
    Apr 29, 2016 @ 19:52
    Sebastiaan Janssen
    0

    Whoops, wrong article, I meant to link to the one about migrations, although if you do have trouble upgrading, that post is also a good read:

    https://cultiv.nl/blog/using-umbraco-migrations-to-deploy-changes/

  • Nicholas Westby 2054 posts 7100 karma points c-trib
    Apr 29, 2016 @ 19:57
    Nicholas Westby
    0

    It is not clear to me exactly what you are doing, but I don't think you need to tinker with the umbracoMigrations table.

    If you are taking what you have and replacing your prod DB, the migrations are already done and you are all set.

    If you are taking the code you have and running it against your prod DB, the migrations will automatically run and you are all set.

  • Devin Gleason Lambert 27 posts 89 karma points
    May 02, 2016 @ 15:12
    Devin Gleason Lambert
    0

    Thanks for the replies, I didn't see them till just now, I thought I was signed up for email alerts.

    Devin

  • Devin Gleason Lambert 27 posts 89 karma points
    May 02, 2016 @ 15:26
    Devin Gleason Lambert
    0

    Nicholas,

    I have a backup/copy of my DB as of a week ago, I used it in my trial run to see how the upgrade would go. As I approach a stable environment, and want to actually push U7 to production, I need to get an updated copy of the DB that can be migrated to be U7 friendly. In other words, I need to backup prod DB again and then run the migration then push the new website and new DB to replace the old DB and old website.

    Make Sense? Devin

  • Nicholas Westby 2054 posts 7100 karma points c-trib
    May 03, 2016 @ 04:26
    Nicholas Westby
    0

    Makes sense now. The latest versions of Umbraco store all the migration info in the database. You should be OK if you backup your prod DB, let the migration run locally, then restore the prod DB back to production (along with the website files).

  • Sebastiaan Janssen 5044 posts 15475 karma points MVP admin hq
    May 03, 2016 @ 06:49
    Sebastiaan Janssen
    0

    Although I'm not entirely sure why you would take such an approach, the site would be offline less time if you just push the files to live and then let the upgrade installer do it's work to upgrade your database.

    FYI: we might in the future run code that for instance updates caches on disk, so you would miss out on that upgrade step in the live environment. This doesn't apply right now but keep in mind that in the future it might be required that you run the upgrade installer on each environment to make sure all your environments are in a consistent state.

  • Devin Gleason Lambert 27 posts 89 karma points
    May 03, 2016 @ 15:35
    Devin Gleason Lambert
    0

    Well more importantly, what would happen if the migration failed, I'd be dead in the water.

    I don't get your second statement, are you saying there will be a portion of the upgrade that makes changes that needs to be run on production?

    Devin

  • Nicholas Westby 2054 posts 7100 karma points c-trib
    May 03, 2016 @ 16:19
    Nicholas Westby
    0

    I often do what you are describing (backup prod, upgrade locally, restore prod) to be sure nothing goes wrong.

    An alternative I sometimes do with lower traffic and lower risk sites is backup the database first, perform the upgrade (against the live database), then if anything goes wrong (uncommon) restore the old database backup from before the upgrade. I usually do that when installing plugins though (i.e., I'm usually on the safer side for Umbraco upgrades).

  • Sebastiaan Janssen 5044 posts 15475 karma points MVP admin hq
    May 03, 2016 @ 16:20
    Sebastiaan Janssen
    0

    note:

    we might in the future

  • Devin Gleason Lambert 27 posts 89 karma points
    May 03, 2016 @ 18:22
    Devin Gleason Lambert
    0

    Well ultimately my deployment for this will consist of something like, pushing to staging, swapping a copy of a fresh prod db in running, the upgrade, and swapping staging and prod

    Devin

  • Devin Gleason Lambert 27 posts 89 karma points
    May 24, 2016 @ 11:45
    Devin Gleason Lambert
    0

    Just one more thing I'd like to add, the above method of updating the connection string and changing umbracoConfigurationStatus value to the previous version works. Just don't forget to make sure your umbraco user in sql has the db_owner role.

    Devin

Please Sign in or register to post replies

Write your reply to:

Draft