Answers.Body: <p>IMO the only way to answer this with confidence is empirically: request a trial upgrade in the proposed new hosting environment (or equivalent), and test whether the system upgrades then functions as expected. Most effectively done when you have <a href="https://github.com/fuzionnz/civicrm-codeception" rel="nofollow">some tests</a> that you can run on your newly upgraded site to ensure things function.</p>
  
  <p>Fuzion host on MySQL 5.5 and 5.6, so I can't speak to what you should expect on MySQL 5.7. (This is not because we don't approve of 5.7, we just have had no reason as of today to move there.) </p>
  
  <p>You might also see variation between Percona / MariaDB / MySQL, or between various OS or distribution packages ... Your best bet is to try it and see! Just not in production ;)</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-08-11T19:58:34.803Z
Answers.Text: So, Chris, are you inferring that CiviCRM has not been vetted against MySQL 5.7 at all, and we don't know what is going to happen?  Scary then that CiviHosting is doing this for all (production) sites.
Answers.UserDisplayName: DaveD
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-08-11T20:04:58.567Z
Answers.Text: I want to be clear I'm not saying that! Sorry if it was unclear. I can only speak for Fuzion (and other sites I've explored). We (Fuzion) have not run it on MySQL 5.7, and even if we had, our MySQL 5.7 might not be yours. Hopefully someone who has tested on 5.7 can answer, but even then _their_ MySQL 5.7 might not match yours either, which is why I recommend _testing what will actually happen_ in order to be assured of outcomes. This applies to many things :)
Answers.UserDisplayName: Chris Burgess
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-08-11T20:10:45.363Z
Answers.Text: NB: Looks like CiviCRM's testing may be running a [node on Ubuntu Xenial (16.04)](https://test.civicrm.org/computer/test-ubu1604-1/) which could be using MySQL 5.7 (based on [civi-download-tools](https://github.com/civicrm/civicrm-buildkit/blob/master/bin/civi-download-tools) + [launchpad entry for mysql-server on Xenial](https://launchpad.net/ubuntu/xenial/+package/mysql-server). I am [not certain if that node is working though.](https://test.civicrm.org/computer/test-ubu1604-1/builds)
Answers.UserDisplayName: Chris Burgess
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-08-11T19:11:24.517Z
Answers.LastActivityDate: 2016-08-11T19:11:24.517Z
Answers.UserDisplayName: Chris Burgess
Answers.Body: <p>I'm aware of 2 issues.</p>
  
  <p>There is a lock length issue, but it is a different one: <a href="https://issues.civicrm.org/jira/browse/CRM-17846" rel="nofollow">https://issues.civicrm.org/jira/browse/CRM-17846</a>.
  You may need to backport that patch.</p>
  
  <p>Additionally there is <a href="https://issues.civicrm.org/jira/browse/CRM-18439" rel="nofollow">https://issues.civicrm.org/jira/browse/CRM-18439</a>. While it is patched for core 4.7.10, self-developed queries might violate that restriction. You do get away with disabling the default SQL mode only_full_group_by.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-08-12T08:54:32.820Z
Answers.LastActivityDate: 2016-08-12T08:54:32.820Z
Answers.UserDisplayName: Thomas Schüttler
Answers.Body: <p>CiviHosting has posted <a href="https://civihosting.com/civicrm-bug-mysql-57" rel="nofollow">this message</a> on their website:</p>
  
  <blockquote>
    <p><strong>CiviCRM Bug With MySQL 5.7</strong></p>
    
    <p>As you can read in MySQL's site:</p>
    
    <p>MySQL 5.7.5 and later enforces a maximum length on lock names of 64
    characters. Previously, no limit was enforced.</p>
    
    <p>The problem is that CiviCRM sometimes generates "lock names" longer
    than 64 characters. When that happens, CiviCRM will not work at all
    with MySQL 5.7.</p>
    
    <p>The fix is here:</p>
    
    <p><a href="https://issues.civicrm.org/jira/browse/CRM-17846" rel="nofollow">https://issues.civicrm.org/jira/browse/CRM-17846</a></p>
    
    <p>and so CiviCRM 4.7.7 and later versions and also CiviCRM 4.6.16 and
    later "LTS" versions have this fix.</p>
    
    <p>(Please note that this issue
    <a href="https://issues.civicrm.org/jira/browse/CRM-18439" rel="nofollow">https://issues.civicrm.org/jira/browse/CRM-18439</a> is not relevant at
    all--our servers do not have this problem of
    sql_mode=only_full_group_by".)</p>
  </blockquote>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-08-12T10:59:21.127Z
Answers.LastActivityDate: 2016-08-12T10:59:21.127Z
Answers.UserDisplayName: William Mortada
Answers.Body: <p>All affected CiviCRM installs on CiviHosting's servers were patched following the MySQL upgrade. Sometimes there are conflicts between server-side software security and functionality of <strong>old</strong> CiviCRM versions and a judgment call must be made to determine what is most important.</p>
  
  <p>CiviHosting's policy is to put security first, always.</p>
  
  <p>CiviCRM users are always encouraged to keep their installs up to date.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-04-27T15:04:11.780Z
Answers.LastActivityDate: 2017-04-27T15:04:11.780Z
Answers.UserDisplayName: Hershel
Body: <p>CiviHosting has sent a notice to all their customers that they are upgrading all their servers to MySQL 5.7, despite their acknowledgement that CiviCRM prior to version 4.7.7 "may fail". They plan on performing this upgrade in one week, August 17. </p>
  
  <p>For those customers that are not able to upgrade to a compatible CiviCRM version at this time (due to various customizations),  what are the various issues that can be expected? </p>
  
  <p>I know of the lock name length issue (<a href="https://civicrm.stackexchange.com/questions/12489/when-upgrading-from-4-7-7-to-4-7-8-i-get-error-specified-key-was-too-long">When upgrading from 4.7.7 to 4.7.8 I get error &quot;Specified key was too long&quot;</a>) which appears to be an upgrade process issue.  (Does this problem extend back to prior to 4.7?)</p>
  
  <p>What else is there to be concerned with, particularly with versions 4.4.x, 4.5.x, and 4.6,x?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-08-11T19:14:37.610Z
Comments.Text: NB: the linked "key too long" question was observed on OSX.
Comments.UserDisplayName: Chris Burgess
Tags: <mysql>
Title: CiviHosting and MySQL 5.7
ThreadText: # CiviHosting and MySQL 5.7
  
  (Asked by: username_0 on 2016-08-11)
  
  CiviHosting has sent a notice to all their customers that they are upgrading all their servers to MySQL 5.7, despite their acknowledgement that CiviCRM prior to version 4.7.7 "may fail". They plan on performing this upgrade in one week, August 17.
  
  For those customers that are not able to upgrade to a compatible CiviCRM version at this time (due to various customizations), what are the various issues that can be expected?
  
  I know of the lock name length issue ([When upgrading from 4.7.7 to 4.7.8 I get error "Specified key was too long"](https://civicrm.stackexchange.com/questions/12489/when-upgrading-from-4-7-7-to-4-7-8-i-get-error-specified-key-was-too-long)) which appears to be an upgrade process issue. (Does this problem extend back to prior to 4.7?)
  
  What else is there to be concerned with, particularly with versions 4.4.x, 4.5.x, and 4.6,x?
  
  **Tags:** mysql
  
  > **Comments:**
  > **username_1**: NB: the linked "key too long" question was observed on OSX.  
  
  ---
  
  ## 4 answers
  
  ### Answer by username_1 on 2016-08-11. Score: 1
  
  IMO the only way to answer this with confidence is empirically: request a trial upgrade in the proposed new hosting environment (or equivalent), and test whether the system upgrades then functions as expected. Most effectively done when you have [some tests](https://github.com/fuzionnz/civicrm-codeception) that you can run on your newly upgraded site to ensure things function.
  
  Fuzion host on MySQL 5.5 and 5.6, so I can't speak to what you should expect on MySQL 5.7. (This is not because we don't approve of 5.7, we just have had no reason as of today to move there.)
  
  You might also see variation between Percona / MariaDB / MySQL, or between various OS or distribution packages ... Your best bet is to try it and see! Just not in production ;)
  
  > **Comments:**
  > **username_0**: So, username_1, are you inferring that CiviCRM has not been vetted against MySQL 5.7 at all, and we don't know what is going to happen?  Scary then that CiviHosting is doing this for all (production) sites.  
  > **username_1**: I want to be clear I'm not saying that! Sorry if it was unclear. I can only speak for Fuzion (and other sites I've explored). We (Fuzion) have not run it on MySQL 5.7, and even if we had, our MySQL 5.7 might not be yours. Hopefully someone who has tested on 5.7 can answer, but even then _their_ MySQL 5.7 might not match yours either, which is why I recommend _testing what will actually happen_ in order to be assured of outcomes. This applies to many things :)  
  > **username_1**: NB: Looks like CiviCRM's testing may be running a [node on Ubuntu Xenial (16.04)](https://test.civicrm.org/computer/test-ubu1604-1/) which could be using MySQL 5.7 (based on [civi-download-tools](https://github.com/civicrm/civicrm-buildkit/blob/master/bin/civi-download-tools) + [launchpad entry for mysql-server on Xenial](https://launchpad.net/ubuntu/xenial/+package/mysql-server). I am [not certain if that node is working though.](https://test.civicrm.org/computer/test-ubu1604-1/builds)  
  
  ---
  
  ### Answer by username_2 on 2016-08-12. Score: 1
  
  I'm aware of 2 issues.
  
  There is a lock length issue, but it is a different one: <https://issues.civicrm.org/jira/browse/CRM-17846>.
  You may need to backport that patch.
  
  Additionally there is <https://issues.civicrm.org/jira/browse/CRM-18439>. While it is patched for core 4.7.10, self-developed queries might violate that restriction. You do get away with disabling the default SQL mode only\_full\_group\_by.
  
  
  ---
  
  ### Answer by username_3 on 2016-08-12. Score: 0
  
  CiviHosting has posted [this message](https://civihosting.com/civicrm-bug-mysql-57) on their website:
  
  > **CiviCRM Bug With MySQL 5.7**
  >
  > As you can read in MySQL's site:
  >
  > MySQL 5.7.5 and later enforces a maximum length on lock names of 64
  > characters. Previously, no limit was enforced.
  >
  > The problem is that CiviCRM sometimes generates "lock names" longer
  > than 64 characters. When that happens, CiviCRM will not work at all
  > with MySQL 5.7.
  >
  > The fix is here:
  >
  > <https://issues.civicrm.org/jira/browse/CRM-17846>
  >
  > and so CiviCRM 4.7.7 and later versions and also CiviCRM 4.6.16 and
  > later "LTS" versions have this fix.
  >
  > (Please note that this issue
  > <https://issues.civicrm.org/jira/browse/CRM-18439> is not relevant at
  > all--our servers do not have this problem of
  > sql\_mode=only\_full\_group\_by".)
  
  
  ---
  
  ### Answer by username_4 on 2017-04-27. Score: 0
  
  All affected CiviCRM installs on CiviHosting's servers were patched following the MySQL upgrade. Sometimes there are conflicts between server-side software security and functionality of **old** CiviCRM versions and a judgment call must be made to determine what is most important.
  
  CiviHosting's policy is to put security first, always.
  
  CiviCRM users are always encouraged to keep their installs up to date.
  
  
  ---
  
  