Answers.Body: <p>Of course</p>
  <ul>
  <li>you ran this on a development copy of the site first, so you're not panicking, right?</li>
  <li>you took a backup before your production upgrade, and can roll back to that?</li>
  <li>you wished you had?</li>
  </ul>
  <h2>If you can, revert your database to a pre-upgrade backup</h2>
  <p>Then run this SQL on the CiviCRM database: <code>OPTIMIZE TABLE civicrm_action_schedule;</code></p>
  <p>Then repeat the upgrade.</p>
  <h2>If you didn't have a backup</h2>
  <p>Then run this SQL on the CiviCRM database: <code>OPTIMIZE TABLE civicrm_action_schedule;</code></p>
  <p>Then try to resume the upgrade procedure. If you're  on the command line you can use <code>cv upgrade:db</code> which will probably suggest you run <code>cv upgrade:db --retry</code>.</p>
  <p>Hopefully it runs through clean for you now.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-03-26T07:42:36.813Z
Answers.LastActivityDate: 2021-03-26T07:42:36.813Z
Answers.UserDisplayName: artfulrobot
Answers.Body: <p>This was <a href="https://lab.civicrm.org/dev/core/-/issues/2335" rel="nofollow noreferrer">reported</a> for 5.34 and there was <a href="https://github.com/civicrm/civicrm-core/pull/19458/commits/b267c4cfa7689340af80fa958d8dc3b94159ec5a" rel="nofollow noreferrer">PR</a> for the fix but was rejected in favour of environment issue.</p>
  <p>Solution was, Before upgrading to 5.34 or later to convert all the tables in civicrm to make
  ROW_FORMAT=DYNAMIC.</p>
  <p>Include the below config in mysql config file</p>
  <pre><code>innodb_large_prefix=true 
  innodb_file_format=barracuda 
  innodb_file_per_table=true
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-03-26T12:53:47.740Z
Answers.LastActivityDate: 2021-03-26T12:53:47.740Z
Answers.UserDisplayName: Pradeep Nayak
Answers.Body: <p>I do have a backup via drush ard.</p>
  <p>However I tried the second of artfulrobot's options, as the steps for the restore are a bit convoluted.</p>
  <blockquote>
  <p>drush civicrm-upgrade-db</p>
  </blockquote>
  <p>ran with no output.</p>
  <blockquote>
  <p>drush cache-clear civicrm</p>
  </blockquote>
  <p>It appears things are ok.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-03-28T21:52:04.470Z
Answers.LastActivityDate: 2021-03-28T21:52:04.470Z
Answers.UserDisplayName: Kenneth Baumann
Body: <p>While upgrading several of my sites to 5.35.1 (from 5.28 or later) I experienced a nasty database crash in the step called <em>core-issue#365 - Add created_date to civicrm_action_schedule</em></p>
  <pre><code>$Fatal Error Details = Array (
   [callback] =&gt; Array ( [0] =&gt; CRM_Core_Error [1] =&gt; exceptionHandler )
   [code] =&gt; -1
   [message] =&gt; DB Error: unknown error
   [mode] =&gt; 16
   [debug_info] =&gt;
     ALTER TABLE `civicrm_action_schedule`
     ADD COLUMN `created_date` timestamp NULL DEFAULT CURRENT_TIMESTAMP
                 COMMENT 'When was the schedule reminder created.'
     [nativecode=1118 ** Row size too large. The maximum row size for the used
     table type, not counting BLOBs, is 8126. This includes storage overhead,
     check the manual. You have to change some columns to TEXT or BLOBs]
  </code></pre>
  <p>What can I do?</p>
  <p>(Note in my case this is not related to <a href="https://civicrm.stackexchange.com/questions/17198/upgrade-fails-with-row-size-too-large-error">Upgrade fails with Row size too large error</a>)</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-03-26T09:21:26.213Z
Comments.Text: This is related to https://lab.civicrm.org/dev/core/-/issues/2335 and affects anyone upgrading to 5.34+
Comments.UserDisplayName: artfulrobot
Tags: <upgrade>
Title: Crash in upgrade to 5.35.1 on task core-issue#365 - Add created_date to civicrm_action_schedule
ThreadText: # Crash in upgrade to 5.35.1 on task core-issue#365 - Add created_date to civicrm_action_schedule
  
  (Asked by: username_0 on 2021-03-26)
  
  While upgrading several of my sites to 5.35.1 (from 5.28 or later) I experienced a nasty database crash in the step called core-issue#365 - Add created_date to civicrm_action_schedule
  $Fatal Error Details = Array (
   [callback] => Array ( [0] => CRM_Core_Error [1] => exceptionHandler )
   [code] => -1
   [message] => DB Error: unknown error
   [mode] => 16
   [debug_info] =>
     ALTER TABLE `civicrm_action_schedule`
     ADD COLUMN `created_date` timestamp NULL DEFAULT CURRENT_TIMESTAMP
                 COMMENT 'When was the schedule reminder created.'
     [nativecode=1118 ** Row size too large. The maximum row size for the used
     table type, not counting BLOBs, is 8126. This includes storage overhead,
     check the manual. You have to change some columns to TEXT or BLOBs]
  
  What can I do?
  (Note in my case this is not related to Upgrade fails with Row size too large error)
  
  **Tags:** upgrade
  
  > **Comments:**
  > **username_0**: This is related to https://lab.civicrm.org/dev/core/-/issues/2335 and affects anyone upgrading to 5.34+  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_0 on 2021-03-26. Score: 3
  
  Of course
  
  * you ran this on a development copy of the site first, so you're not panicking, right?
  * you took a backup before your production upgrade, and can roll back to that?
  * you wished you had?
  
  ## If you can, revert your database to a pre-upgrade backup
  
  Then run this SQL on the CiviCRM database: `OPTIMIZE TABLE civicrm_action_schedule;`
  
  Then repeat the upgrade.
  
  ## If you didn't have a backup
  
  Then run this SQL on the CiviCRM database: `OPTIMIZE TABLE civicrm_action_schedule;`
  
  Then try to resume the upgrade procedure. If you're on the command line you can use `cv upgrade:db` which will probably suggest you run `cv upgrade:db --retry`.
  
  Hopefully it runs through clean for you now.
  
  
  ---
  
  ### Answer by username_1 on 2021-03-26. Score: 2
  
  This was reported for 5.34 and there was PR for the fix but was rejected in favour of environment issue.
  Solution was, Before upgrading to 5.34 or later to convert all the tables in civicrm to make
  ROW_FORMAT=DYNAMIC.
  Include the below config in mysql config file
  innodb_large_prefix=true 
  innodb_file_format=barracuda 
  innodb_file_per_table=true
  
  
  ---
  
  ### Answer by username_2 on 2021-03-28. Score: 0
  
  I do have a backup via drush ard.
  
  However I tried the second of username_0's options, as the steps for the restore are a bit convoluted.
  
  > drush civicrm-upgrade-db
  
  ran with no output.
  
  > drush cache-clear civicrm
  
  It appears things are ok.
  
  
  ---
  
  