Download the PHP package krowinski/php-mysql-replication without Composer
On this page you can find all versions of the php package krowinski/php-mysql-replication. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download krowinski/php-mysql-replication
More information about krowinski/php-mysql-replication
Files in krowinski/php-mysql-replication
Package php-mysql-replication
Short Description Pure PHP Implementation of MySQL replication protocol. This allow you to receive event like insert, update, delete with their data and raw SQL queries.
License MIT
Informations about the package php-mysql-replication
php-mysql-replication
Pure PHP implementation of the MySQL replication protocol — stream insert, update and delete events (with data and raw SQL) straight from the binlog.
Based on the great work of https://github.com/noplay/python-mysql-replication and https://github.com/fengxiangyun/mysql-replication.
📖 Table of contents
- Installation
- Compatibility
- MySQL server settings
- Configuration
- Examples
- Benchmarks
- Similar projects
- FAQ
🚀 Installation
In your project:
or standalone:
✅ Compatibility (based on integration tests)
PHP
- php 8.2
- php 8.3
- php 8.4
- php 8.5
MySQL
- mysql 5.5
- mysql 5.6
- mysql 5.7
- mysql 8.0 (
mysql_native_passwordandcaching_sha2_passwordsupported) - mariadb 5.5
- mariadb 10.0
- mariadb 10.1
- probably percona versions as it's based on native mysql
⚙️ MySQL server settings
In your MySQL server configuration file you need to enable replication:
MySQL replication events explained: https://dev.mysql.com/doc/internals/en/event-meanings.html
MySQL user privileges:
🔧 Configuration
Use ConfigBuilder or ConfigFactory to create configuration.
| Option | Description |
|---|---|
user |
your mysql user (mandatory) |
ip / host |
your mysql host/ip (mandatory) |
password |
your mysql password (mandatory) |
port |
your mysql host port (default 3306) |
charset |
db connection charset (default utf8) |
gtid |
GTID marker(s) to start from (format 9b1c8d18-2a76-11e5-a26b-000c2976f3f3:1-177592) |
mariaDbGtid |
MariaDB GTID marker(s) to start from (format 1-1-3,0-1-88) |
slaveId |
script slave id for identification (default 666) (SHOW SLAVE HOSTS) |
binLogFileName |
bin log file name to start from |
binLogPosition |
bin log position to start from |
eventsOnly |
array to only listen on given events (full list in ConstEventType.php) |
eventsIgnore |
array of events to ignore (full list in ConstEventType.php) |
tablesOnly |
array to only listen on given tables (default all tables) |
databasesOnly |
array to only listen on given databases (default all databases) |
tablesIgnore |
array of tables to ignore (default none) |
databasesIgnore |
array of databases to ignore (default none) |
tablesRegex |
array of regex patterns to only listen on matching tables (default all tables) |
databasesRegex |
array of regex patterns to only listen on matching databases (default all databases) |
tableCacheSize |
some data is collected from the information schema; this data is cached |
custom |
if some params must be set in extended/implemented own classes |
heartbeatPeriod |
interval in seconds between replication heartbeats. Whenever the master's binary log is updated with an event, the waiting period for the next heartbeat is reset. Range 0–4294967 seconds with millisecond resolution (smallest nonzero value 0.001). Heartbeats are sent by the master only if there are no unsent events in the binary log for longer than this interval |
slaveUuid |
sets slave uuid for identification (default 0015d2b6-8a06-4e5e-8c07-206ef3fbd274) |
gtidAutoPosition |
enables GTID auto positioning, letting the master decide where to start streaming from based on the GTID set already processed (default false) |
semiSync |
opt in to semi-sync replication. If the master doesn't have rpl_semi_sync_master_enabled/rpl_semi_sync_source_enabled = ON, this is silently ignored and the connection falls back to async replication (default false) |
useTableMapMetadata |
read column names/unsigned flags/ENUM-SET literals/primary key from the TABLE_MAP_EVENT's optional metadata (requires binlog_row_metadata=FULL on the server), avoiding an information_schema query per table. Falls back to information_schema when that metadata isn't present. Set to false to always use information_schema, e.g. if you need COLLATION_NAME/CHARACTER_SET_NAME/COLUMN_COMMENT (default true) |
💡 Examples
All examples are available in the examples directory.
This example will dump all replication events to the console.
Remember to change the config for your user, host and password. The user should have replication privileges [
REPLICATION CLIENT,SELECT].
Test SQL events:
Output (depends on configuration, e.g. GTID off/on) — click to expand
📊 Benchmarks
Tested on VM:
🌍 Similar projects
❓ FAQ
1. Why and when do I need php-mysql-replication?
MySQL doesn't give you async calls out of the box. You'd usually need to build this yourself (event dispatching, adding to a queue system), and if your DB has many points of entry — web, backend, other microservices — it's not always cheap to add processing to all of them. Using the MySQL replication protocol, you can listen on write events and process them asynchronously (the best combo is to push items into a queue system like RabbitMQ, Redis or Kafka). Also useful for cache invalidation, search engine replication, real-time analytics and audits.
2. It's awesome! But what's the catch?
A lot of events may come through — e.g. if you update 1,000,000 records in table "bar" and need the one insert from table "foo", everything must be processed by the script first, and you'll need to wait for your data. This is normal and how it works. You can speed things up using [config options](#-configuration). Also, if the script crashes, you need to periodically save the binlog position (or GTID) so you can resume from it and avoid duplicates.
3. I need to process 1,000,000 records and it's taking forever!
As mentioned in point 1, use a queue system like RabbitMQ, Redis or Kafka — they let you process data across multiple scripts.
4. I have a problem / your script is missing something / I found a bug!
Create an [issue](https://github.com/krowinski/php-mysql-replication/issues) and I'll try to work on it in my free time :)
5. How much overhead does this give the MySQL server?
It works like any other MySQL slave and gives the same overhead.
6. Socket timeouts error
Best fix is to increase the DB configuration `net_read_timeout` and `net_write_timeout` to `3600`. (tx Bijimon)
7. Partial updates fix
Set `binlog_row_image=full` in `my.cnf` to fix receiving only partial updates.
8. No replication events when connected to a replica server
Set `log_slave_updates=on` in `my.cnf` to fix this (#71)(#66).
9. "Big" updates / inserts
The default MySQL setting generates one big blob stream, which requires more RAM/CPU. You can change this to a smaller stream using the [`binlog_row_event_max_size`](https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_binlog_row_event_max_size) variable to split into smaller chunks.
All versions of php-mysql-replication with dependencies
ext-bcmath Version *
ext-json Version *
ext-sockets Version *
doctrine/collections Version ^2.1
doctrine/dbal Version ^4.0
psr/log Version ^3.0
psr/simple-cache Version ^3.0
symfony/event-dispatcher Version ^6.0|^7.0|^8.0