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);
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
Instances using PostgreSQL can expect the upgrade process to take up to a few minutes, increasing with database size (~4 minutes on a 12M