When MariadB Server RPM packages are installed for the first time, a system user (mysql) and group (mysql) are created. (Quite likely the same thing happens with the deb packages also.) These user and group are created without a fixed user ID (UID) or group id (GID), therefore the system assigns them the first available ones. For stand-alone server installations as well as for replicated clusters (sync, async) this does not create any issue; however, it does create a problem for sharded clusters where shared storage must be used - for example, ColumnStore has a component named StorageManager which must, by design, mandates the use of shared storage on all nodes. If the MariaDB server packages are not installed at the very same time on identical OS instances, this creates the real risk of some nodes being unable to join the cluster due to their UID and GID for the mysql user and group differing from the rest of the cluster. The latter scenario becomes ever more real if a new node has to be joined to an already existing cluster.
One possible way to address this is to always use a predefined UID and GID for the mysql system user. Normally, these "fixed" UID and GID are allocated by the Linux community, which is quite reluctant to give out new ones due to their scarcity. However, back in the MySQL times there were a fixed UID=27 and GID=27 allocated to the mysql system user and group - and these are still used both by Oracle MySQL in their packaging and by some external packagers of MariaDB (e.g., on Fedora Linux).
We therefore suggest that MariaDB adopts these fixed UID and GID for its system user. As the user is created only when an RPM package is installed for the first time, the change will not affect any existing installation. It should also not interfere with the rare cases where MariaDB server must co-habitate with MySQL client libraries, or when MariaDB should replace MySQL in-place.