Upgrading to 6.3.3: any 5.3 or later goes straight there
-
hMailServer upgrades in place. The installer stops the service, replaces the program files in
Bin, upgrades the schema if needed, and restarts. Your data directory andhMailServer.INIare untouched.Any 5.3 through 6.2 goes straight to 6.3.3. There are no intermediate steps. The upgrade chain is continuous on MySQL/MariaDB, MS SQL, PostgreSQL and SQL Server Compact, and DBUpdater walks whichever steps your database still needs. 6.3.3 needs schema 6040. A 6.2.27 or 6.2.28 database sits at 6031 and is walked through 6.3.2's seven steps and 6.3.3's two. Older ones are walked the whole way. Path table: §18.2.
Nothing 6.3.0 added is on by default. The REST API, the Control Deck and the portal all need
RestApiPortset. A server upgraded without touching its settings behaves as 6.2.28 did, apart from the 6.3.3 delivery fix and the rebuilt webmail.Before you start
Back up the database, the data directory and
hMailServer.INI(chapter 15). Record your current version. Pick a quiet window; the service is down for a minute or two and senders retry.That backup is the rollback. The upgrade is one way: an older server refuses a newer database rather than misreading it. Rolling back means uninstalling 6.3.3, reinstalling your previous version and restoring the database from backup (§18.6).
The step that can fail
Two schema steps want a maintenance window on a large database. 6024 to 6025 rewrites
hm_messages.messageflagsfrom tinyint to smallint: a locking table rewrite on your largest table, on every backend except PostgreSQL. 6029 to 6030 adds seventeen FOREIGN KEY constraints with ON DELETE CASCADE and reads every child table once.6029 to 6030 is the one place an upgrade stops. It sweeps orphaned rows before adding those constraints, and that sweep ran children before parents, so pruning an orphaned account, fetch account or distribution list could re-orphan rows nothing revisits, and the constraint that followed was refused. The reordering fix shipped in 6.3.2 and is in 6.3.3. It fires only from a schema below 6030, only against a database that already holds orphaned rows, on all four backends. No installation has reported hitting it. When that step fails it fails loudly, in the database engine's own words, and rolls back rather than doing anything quietly. The database is where it was, the error names the constraint it could not add, and those orphaned rows have to go before the upgrade will pass.
On 6.3.1 or 6.3.2
6.3.2 could not upgrade a database older than its own schema; those attempts stopped with
The server has not loaded its configurationand changed nothing. The Control Panel's live update to 6.3.2 failed with installer exit code 5, because the Control Panel that started it held its files open. Both are fixed in 6.3.3, but the live-update helper is the one already installed. Close the Control Panel and run the installer by hand once.On Linux the package replaces the binary and its post-install step runs
hmailserver --upgrade-database. -
C chris pinned this topic
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login