"I want to have binlog identical to the master."
Why would you want this? The binlogs are already not identical between these two instances, even besides the last two, because the filenames and sizes are different.
Binlogs start new files if FLUSH LOGS
is run, or if MySQL Server restarts, or the file reaches the max binlog size. The number of files and their sizes are bound to be out of sync between the source instance and its replicas. I would guess in this case that restoring the snapshot caused two restarts.
It's not a problem for binlog files to have different sizes. As long as they contain the same changes, they can be stored in few files or many files, and they don't have to be the same.
To apply changes in binlogs, you must have a contiguous set of changes since the last snapshot. If you were to purge the last two files, you could never use the binlogs for replication or point-in-time recovery, at least not past mysql-bin-changelog.603813.
Purging the binlog files older than the latest snapshot is common and recommended, but not the newest binlog files. In fact, PURGE BINARY LOGS
will never remove the latest binlog file, because the MySQL Server is still using it.
One solution for you is to set the expire_logs_days
in the parameter group to a modest value such as 2 or 3, then wait that number of days for the current set of binlogs to expire. After that, the small binlog files will be gone.