Many binlog use cases rely on standards such as the index file. MaxScale does not create an index file on disk, it should.
The index file is a text file that lists the current binary log files.
In MariaDB Server, all binary log files share a common basename, which is defined by either the log_bin or log_basename options. To distinguish between log files, the basename is suffixed with sequential numbers using a .NNNNNN format. The basename can be queried at run-time by checking the log_bin_basename system variable.
By default, the index file created by MariaDB Server shares the same basename as the binary log files, but it has a suffix of .index. This file name can be changed by defining the log_bin_index system variable.
The default binary log file-naming basename is "HOSTNAME-bin". With the default basename, the binary log has files with names like this:
Basically, the index file just needs to be written when a binary log is expired (remove the file from the top of the index) or when a new binary log is written (append to the index).
Additionally, an option should be created to allow setting permissions for all binlogs/index files, ie binlog_umask=0644
Possible binlogrouter use cases:
- binlog forwarding from environments such as RDS where files are not accessible, for CDC type products such as GoldenGate and others.
- PITR - binlog streaming to a central node running maxscale
- hundreds of slaves, avoiding master context switching
- moving replication through restricted firewalls, ie maxscale proxies from hundreds of database servers from one environment to slaves in another.
- failover of slaves from one master to another, maxscale keeps a continuous connection so slaves never stop
Theoretically, you could put a maxscale on medium type of ec2 and have like 20 binlog routers with ports 4000-4020, each doing their own thing for different apps.