Answers.Body: <p>In my specific case - upgrading from 2.0.2551 to 2.1.2570 - the issue was caused by there being millions of rows in the <code>craft_entryversions</code> table. One of the migrations in the update needed to loop through every row in that table and do something to it and therefore it took ages.</p>
  
  <p>Simply emptying that table solved the upgrade process for me.</p>
  
  <p><strong>Caveats</strong></p>
  
  <p>Obviously this deletes all your entry versions...so, each entry will just exist at its last known 'live' state. This wasn't a problem for me - but might be for you. </p>
  
  <p>Its worth noting that this shouldn't affect any drafts users might have made as they are stored in a separate <code>craft_entrydrafts</code> table.</p>
  
  <p>Thanks to Fred Carlsen for helping me think aloud...</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-09-24T15:25:37.160Z
Answers.LastActivityDate: 2014-09-24T15:25:37.160Z
Answers.UserDisplayName: Josh Angell
Body: <p>I am trying to upgrade a site from 2.0.2551 to 2.1.2570. I have ~18k entries and ~28 elements. The upgrade process seems to want to save all the elements again as far as I can tell, is there any way to avoid this or make it quicker? Is there some magical SQL I might play with to do it all?</p>
  
  <p>At present I've had it sat for 14 hours before I gave up...</p>
  
  <p>Incidentally I can legitimately reduce the number of entries to about ~3k and the elements to ~11k as I can just re-import those from an API service - I have tried this and it still takes an awfully long time.</p>
  
  <p>Any advice or previous similar situations you people have run in to would be most helpful :)</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-09-24T11:09:27.943Z
Comments.Text: What about editing the ResaveAllElementsTask/ResaveElementTask and add a limit/offset, and then do it in batches?
Comments.UserDisplayName: Fred Carlsen
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-09-24T13:14:49.090Z
Comments.Text: Yeah I thought about something like that but surely it'll still take the same amount of time in total?
Comments.UserDisplayName: Josh Angell
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-09-24T13:18:28.367Z
Comments.Text: I don't know. Actually 14 hours for "only 18k entries" makes me believe there is something else going on. Does it stall/error out, or do you see that it just takes an awful amount of time to resave every single element? How long does 1 element take? Is it still running?
Comments.UserDisplayName: Fred Carlsen
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-09-24T13:20:29.800Z
Comments.Text: Well I can't see much to be honest - just that from running top mysql is doing things...I see a drop in cpu once a second or so at the moment, and mostly about 2 out of 4 cores are in the red. I'm doing this on an iMac.
Comments.UserDisplayName: Josh Angell
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-09-24T13:21:04.913Z
Comments.Text: Try a batch of 200, and see if that helps. If it runs very quickly (let's say 1 minute), you would only spend 100 minutes resaving about 20000 entries.
Comments.UserDisplayName: Fred Carlsen
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-09-24T13:21:07.977Z
Comments.Text: Equally there is nothing in the logs...
Comments.UserDisplayName: Josh Angell
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-09-24T13:21:51.467Z
Comments.Text: Ok - I'll be back in a bit when I've done that.
Comments.UserDisplayName: Josh Angell
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-09-24T13:58:27.177Z
Comments.Text: Oh dear. All I needed to do was more thoroughly read through the migration scripts added in the 2.1 release. One of them loops over all the entry versions  (~2.6m in my db)...I just truncated that table and it went in a few seconds! No harm done apparently either. Thanks for your suggestions - helped me think about it more logically!
Comments.UserDisplayName: Josh Angell
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-09-24T14:37:36.700Z
Comments.Text: Mind adding that as the official answer, @joshangell?
Comments.UserDisplayName: Brad Bell
Tags: <upgrades><updating><manual-updates>
Title: How to manage a large database when upgrading from 2.0 to 2.1
ThreadText: # How to manage a large database when upgrading from 2.0 to 2.1
  
  (Asked by: username_0 on 2014-09-24)
  
  I am trying to upgrade a site from 2.0.2551 to 2.1.2570. I have ~18k entries and ~28 elements. The upgrade process seems to want to save all the elements again as far as I can tell, is there any way to avoid this or make it quicker? Is there some magical SQL I might play with to do it all?
  
  At present I've had it sat for 14 hours before I gave up...
  
  Incidentally I can legitimately reduce the number of entries to about ~3k and the elements to ~11k as I can just re-import those from an API service - I have tried this and it still takes an awfully long time.
  
  Any advice or previous similar situations you people have run in to would be most helpful :)
  
  **Tags:** upgrades, updating, manual-updates
  
  > **Comments:**
  > **username_1**: What about editing the ResaveAllElementsTask/ResaveElementTask and add a limit/offset, and then do it in batches?  
  > **username_0**: Yeah I thought about something like that but surely it'll still take the same amount of time in total?  
  > **username_1**: I don't know. Actually 14 hours for "only 18k entries" makes me believe there is something else going on. Does it stall/error out, or do you see that it just takes an awful amount of time to resave every single element? How long does 1 element take? Is it still running?  
  > **username_0**: Well I can't see much to be honest - just that from running top mysql is doing things...I see a drop in cpu once a second or so at the moment, and mostly about 2 out of 4 cores are in the red. I'm doing this on an iMac.  
  > **username_1**: Try a batch of 200, and see if that helps. If it runs very quickly (let's say 1 minute), you would only spend 100 minutes resaving about 20000 entries.  
  > **username_0**: Equally there is nothing in the logs...  
  > **username_0**: Ok - I'll be back in a bit when I've done that.  
  > **username_0**: Oh dear. All I needed to do was more thoroughly read through the migration scripts added in the 2.1 release. One of them loops over all the entry versions  (~2.6m in my db)...I just truncated that table and it went in a few seconds! No harm done apparently either. Thanks for your suggestions - helped me think about it more logically!  
  > **username_2**: Mind adding that as the official answer, @username_0?  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2014-09-24. Score: 5 | Accepted answer
  
  In my specific case - upgrading from 2.0.2551 to 2.1.2570 - the issue was caused by there being millions of rows in the `craft_entryversions` table. One of the migrations in the update needed to loop through every row in that table and do something to it and therefore it took ages.
  
  Simply emptying that table solved the upgrade process for me.
  
  **Caveats**
  
  Obviously this deletes all your entry versions...so, each entry will just exist at its last known 'live' state. This wasn't a problem for me - but might be for you.
  
  Its worth noting that this shouldn't affect any drafts users might have made as they are stored in a separate `craft_entrydrafts` table.
  
  Thanks to username_1 username_1 for helping me think aloud...
  
  
  ---
  
  