Upgrade order when PHP/DB/ES need upgrades

When I do an upgrade that also requires a PHP, Database and/or Elastic Search upgrade I am always a bit confused about what order we do this in.

Do I upgrade PHP, DB and ES and THEN Sugar

or do I upgrade Sugar and THEN PHP, DB, ES?

thank you,

FrancescaS

Parents
  • Hi Francesca Shiekh 

    Two or more consecutive versions of SugarCRM frequently supports the same version of PHP, Web Server and Database, but not exactly the same version of Elastic Search.

    On upgrading a SugarCRM instance the Upgrade patch validates PHP and Elastic Search versions but never, as far I know, Web Server and Database versions. So you must make sure source and destination versions of SugarCRM are supported by the same PHP version, eventually you can upgrade PHP to a version compatible only by the destination SugarCRM version after upgrading SugarCRM. Regarding Elastic Search you must upgrade it to the version compatible to the destination SugarCRM version before upgrading SugarCRM itself.

    I hope it helps you

    André Lopes
    Lampada Global
    Skype: andre.lampada
  • I agree with André Lopes,

    Basically you would need to be on a supported platform during the upgrade (not only before and after).

    As a rule of thumb I recommend to decouple as much as possible the infrastructure upgrades from the application upgrades, by completing them on a different timeframe.

    As first step I highly recommend to stop cron from running and wait for it to complete its current runs.

    I would then upgrade all possible infrastructure elements (for a 7.9 to 8 upgrade PHP and MySQL) to the highest version supported by both the source and destination version.

    For the Elasticsearch version update required from 7.9 to 8 (from 1.7.5 to 5.4 5.6), due to multiple upgrade steps required, configuration differences and changes in mapping structure, I suggest to create a new independent ES 5.4 5.6 stack, and eventually abandon the 1.7.5 stack.

    Once the infrastructure is up and running, to upgrade the application, I would disable Elastic for the instance and change the configuration to point to the new stack, just before upgrading Sugar through config_override.php (i.e.: $sugar_config['full_text_engine']['Elastic']['host'] = 'sugar-elasticsearch56';)

    After the upgrade is successful, re-enable Elastic and issue a full reindex.

    Finally re-enable cron.

    You could disable Elastic by changing the following setting on the config database table to '1', and then set it back to '0' to re-enable it:

    mysql> select * from config where name like '%fts%';

    +----------+----------+-------+----------+

    | category | name     | value | platform |

    +----------+----------+-------+----------+

    | info     | fts_down | 0     |          |

    +----------+----------+-------+----------+

    1 row in set (0.00 sec)

    To help out with this testing process on the SugarDockerized stack I've created a transitional stack with both Elasticsearch versions (https://github.com/esimonetti/SugarDockerized/tree/master/stacks/sugar79upgrade).

    Additionally to facilitate and speed up the full Elastic reindexing I've produced a small CLI POC script that can help with full re-indexing without waiting for the scheduler: Sugar CLI command to run index processing without waiting for the scheduler · GitHub  

    Hope this helps you Francesca Shiekh

    EDITS:

    I've updated the comment, reflecting Matt Marum's feedback. I've also added the stopping/starting cron as it is an important detail that can't be missed.

    --

    Enrico Simonetti

    Sugar veteran (from 2007)

    www.naonis.tech


    Feel free to reach out for consulting regarding:

    • API Integration and Automation Services
    • Sugar Architecture
    • Sugar Performance Optimisation
    • Sugar Consulting, Best Practices and Technical Training
    • AWS and Sugar Technical Help
    • CTO-as-a-service
    • Solutions-as-a-service
    • and more!

    All active SugarCRM certifications

    Actively working remotely with customers based in APAC and in the United States

Reply
  • I agree with André Lopes,

    Basically you would need to be on a supported platform during the upgrade (not only before and after).

    As a rule of thumb I recommend to decouple as much as possible the infrastructure upgrades from the application upgrades, by completing them on a different timeframe.

    As first step I highly recommend to stop cron from running and wait for it to complete its current runs.

    I would then upgrade all possible infrastructure elements (for a 7.9 to 8 upgrade PHP and MySQL) to the highest version supported by both the source and destination version.

    For the Elasticsearch version update required from 7.9 to 8 (from 1.7.5 to 5.4 5.6), due to multiple upgrade steps required, configuration differences and changes in mapping structure, I suggest to create a new independent ES 5.4 5.6 stack, and eventually abandon the 1.7.5 stack.

    Once the infrastructure is up and running, to upgrade the application, I would disable Elastic for the instance and change the configuration to point to the new stack, just before upgrading Sugar through config_override.php (i.e.: $sugar_config['full_text_engine']['Elastic']['host'] = 'sugar-elasticsearch56';)

    After the upgrade is successful, re-enable Elastic and issue a full reindex.

    Finally re-enable cron.

    You could disable Elastic by changing the following setting on the config database table to '1', and then set it back to '0' to re-enable it:

    mysql> select * from config where name like '%fts%';

    +----------+----------+-------+----------+

    | category | name     | value | platform |

    +----------+----------+-------+----------+

    | info     | fts_down | 0     |          |

    +----------+----------+-------+----------+

    1 row in set (0.00 sec)

    To help out with this testing process on the SugarDockerized stack I've created a transitional stack with both Elasticsearch versions (https://github.com/esimonetti/SugarDockerized/tree/master/stacks/sugar79upgrade).

    Additionally to facilitate and speed up the full Elastic reindexing I've produced a small CLI POC script that can help with full re-indexing without waiting for the scheduler: Sugar CLI command to run index processing without waiting for the scheduler · GitHub  

    Hope this helps you Francesca Shiekh

    EDITS:

    I've updated the comment, reflecting Matt Marum's feedback. I've also added the stopping/starting cron as it is an important detail that can't be missed.

    --

    Enrico Simonetti

    Sugar veteran (from 2007)

    www.naonis.tech


    Feel free to reach out for consulting regarding:

    • API Integration and Automation Services
    • Sugar Architecture
    • Sugar Performance Optimisation
    • Sugar Consulting, Best Practices and Technical Training
    • AWS and Sugar Technical Help
    • CTO-as-a-service
    • Solutions-as-a-service
    • and more!

    All active SugarCRM certifications

    Actively working remotely with customers based in APAC and in the United States

Children
  • I think most of Enrico's advice is sound. But I'd add that for 8.0 upgrade we will be supporting Elasticsearch 5.6. So rather than setup an ES 5.4 stack, I'd use ES 5.6 since 5.4 reaches end of life this November. I agree that it's probably easier to setup a new ES 5.x stack than to follow multi-step upgrade process for existing ES 1.7.x deployment. Either that or you could drop all indices on ES 1.7.x prior to upgrading it in place to 5.x. But I suppose that could be riskier if you don't have a fallback ES environment if Sugar upgrade to 8 goes haywire.

    I'm not sure it's necessary to disable ES prior to upgrade. I don't think we test this scenario in Product team.

    App Ecosystem @ SugarCRM