A distributed MySQL binlog storage system built on Raft
Clone or download
Latest commit e1253c9 Jan 3, 2019
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
LICENSES first commit Dec 30, 2018
api first commit Dec 30, 2018
cmd/kingbus first commit Dec 30, 2018
config refactor code Dec 30, 2018
docs modify logo Dec 30, 2018
etc first commit Dec 30, 2018
log first commit Dec 30, 2018
mysql refactor code Dec 30, 2018
raft add go report card Dec 30, 2018
server refactor code Dec 30, 2018
storage refactor code Dec 30, 2018
tools refactor code Dec 30, 2018
utils first commit Dec 30, 2018
vendor first commit Dec 30, 2018
.gitignore first commit Dec 30, 2018
.travis.yml modify logo Dec 30, 2018
Dockerfile first commit Dec 30, 2018
LICENSE first commit Dec 30, 2018
Makefile first commit Dec 30, 2018
README.md fixed kingbus Jan 3, 2019
README_ZH.md Update README_ZH.md Jan 2, 2019
docker-compose.yml first commit Dec 30, 2018

README.md

Go Report Card Build Status

What is kingbus? 中文

Kingbus is a distributed MySQL binlog store based on raft. Kingbus can act as a slave to the real master and as a master to the slaves in the same way as an intermediate MySQL master does. Kingbus has the following key features:

  • MySQL replication protocol compatibility, pull the binlog files from the master through gtid mode, and push the binlog file to slave through gtid mode in the same way.

  • Geo-Replication, kingbus uses Raft to support Geo-Replication. The binlog data written to the cluster is guaranteed to be consistent between multiple nodes, and the order of binlog event is exactly the same as that on the master.

  • High availability, your mysql binlog replication is always on and continuously available with kingbus.

Why need kingbus?

In a traditional MySQL replication setup a single master server is created and a set of slaves of MySQL servers are configured to pull the binlog files from the master, putting a lot of load on the master.

  • Introducing a layer between the master server and the slave servers can reduce the load on the master by only serving kingbus instead of all the slaves.

  • The slaves will only need to be aware of kingbus and not the real master server. Removing the requirement for the slaves to have knowledge of the master also simplifies the process of replacing a failed master within a replication environment.

  • Kingbus allows us to horizontally scale our slaves without fear of overloading the network interface of the master

  • Kingbus can also be used to avoide deep nested replication on remote sites, with kingbus you don't need e deeply nested replication.

  • The size of the binlog storage space on the Master can be reduced, and store the binlog in kingbus.

  • Support MYSQL database heterogeneous log based replication. Other heterogeneous replication components can be connected to the kingbus, such as canal.

For more usage scenarios of binlog server, please refer to the booking blog or binlog server at Facebook.

Quick start

Read the Quick Start

Documentation

1.Kingbus management API introduction

2.Start a kingbus cluster with docker-compose

License

Kingbus is under the Apache 2.0 license. See the LICENSES file for details.

Acknowledgments

  • Thanks etcd for providing raft library.

  • Thanks go-mysql for providing mysql replication protocol parser.