Due to the introduction of new features (Shared Channels and Folded Reply Threads) the performance of the migration process for the 5.35 release has been noticeably affected. Depending on the size, type and version of the database, longer than usual upgrade times should be expected. These can vary from a couple of minutes (average case) to hours (worst case, MySQL only). A moderate to significant spike in database CPU usage should also be expected during this process.
Worst affected instances are those running on MySQL and having a considerable database size (several millions of rows in Posts
table). These installations can expect a worst-case upgrade duration in the order of hours. (1 minute per ~200k Posts
rows). This is due to the addition of a column to the Posts
table that on such versions causes a complete table rebuild (with indexes).
In cases where such prolonged downtime is not acceptable, an online (manual) migration of the Posts
table prior to upgrading is recommended. This means altering the table as such:
ALTER TABLE Posts ADD RemoteId VARCHAR(26);
Note
Simply running the query prior to the upgrade can save some downtime but
it would still cause full table locking. This means that the Posts
table would be read-only for the whole duration of the query execution (no posts can be created nor modified). This applies to High-Availability installations as well.
In such cases, an online, lock-free migration is recommended (e.g. using an external tool like pt-online-schema-change
.
Instances using PostgreSQL can expect the upgrade process to take up to a few minutes, increasing with database size (~4 minutes on a 12M Posts
, 5M ChannelMembers
, 250K Channels
installation).
@streamer45
Thanx for the info, It is not a HA setup. So asynchronously means: run the statement during MM is still running - MM might get a little bit slower during the run but usually it is still fully functional? So finally it just saves you a long startup time when running the new version for the first time?