Get Started With Percona Binary Log Server¶
This page shows a basic first run with local filesystem storage.
Transaction safety: The server writes to storage only at transaction boundary points. Stored binlog files do not contain half-written transactions. If the process stops (gracefully or not), the last visible data ends at the last flushed transaction and a new run resumes from there. See Core behavior for details.
Before starting, make sure the following requirements are met:
-
having access to a Percona Binary Log Server binary or Docker deployment (see Install Percona Binary Log Server)
-
having access to a MySQL server that exposes binary logs
-
having a MySQL account with REPLICATION SLAVE privilege
Create A Configuration File¶
Create a file named config.json with content similar to the following example:
{
"logger": {
"level": "info",
"file": "binsrv.log"
},
"connection": {
"host": "127.0.0.1",
"port": 3306,
"user": "rpl_user",
"password": "rpl_password",
"connect_timeout": 20,
"read_timeout": 60,
"write_timeout": 60
},
"replication": {
"server_id": 42,
"idle_time": 10,
"verify_checksum": true,
"mode": "position"
},
"storage": {
"backend": "file",
"uri": "file:///var/lib/binlog-server"
}
}
Run A One-Time Collection¶
Use fetch when a single archive run is needed:
./binlog_server fetch config.json
fetch reads all currently available binary log events from the source server, stores the data, then exits.
Run Continuous Collection¶
Use pull when ongoing collection is needed:
./binlog_server pull config.json
pull reads available binary log events, waits for new events, reconnects when needed, and continues until a user or service stops the process.
Next Steps¶
Use the following pages for deeper detail:
-
Core behavior — transaction-safe writes, metadata, resume, graceful shutdown
-
Operations — logging, monitoring, and alerting for production