Description:
8.0.3 enables binlogs by default. To do this you need a server_id so the defaults for 8.0.3 change the default server_id from 0 to 1.
server_id is supposed to be unique (if you ever use replication) and we already have a server_uuid value which mysqld 5.6+ auto-generates if it's missing (and stores in auto.cnf to make the value persistent).
My suggestion therefore is to make replication auto-setup easier and if server_id is not defined by the user to auto-generate it based on some server_uuid bits. server_id is 32-bits so you have quite a lot of randomness and part of the uuid generation is if I'm not mistaken using time. So getting a good mix of this should ensure while _less_ random than server_uuid you should be able to generate (if needed) a pretty unique value which will be persistent and thus makes life for the DBA simpler.
If someone wants to maintain their own server_id generation that won't change anything but if they stop doing this mysqld will provide something that's likely to be good enough.
How to repeat:
n/a
Suggested fix:
So please rather than enabling binlogs and setting server_id to 1 which will need fixing once you want to add another server into a [group] replication topology auto-generate a value based on an already known "should be unique" value server_uuid.
This will:
* make user's lives easier (one thing less to configure)
* your life easier (you shouldn't have to worry much about server_id generation
* make setting up replication easier than it is now and require less manual configuration settings while at the same time allowing existing setups to work unchanged.