MySQL Fabric Features and Benefits

Feature Benefit
High Availability
Built on MySQL Replication MySQL Replication is a very mature technology, used by leading web properties and businesses to both scale their databases as well as provide data redundancy. MySQL Replication is a core foundation for the HA provided by MySQL Fabric.
Server Monitoring The state of the MySQL Servers is monitored by MySQL Fabric so that queries and transactions can always be delivered to a viable server. As well as performing its own checks on the servers, MySQL Fabric also receives data from the Fabric-aware MySQL connectors which identify when an application is no longer able to access a server.
Automated Failover If MySQL Fabric detects that a Master has failed then it will automatically promote one of its slaves to be the new master - this allows both reads and writes to continue.
Transparent Failover The application does not need to make any changes in order for transactions to be sent to the new master; this is all encapsulated within MySQL Fabric’s logic.
Semi-Synchronous Replication By using MySQL Semi-Synchronous replication, the administrator can ensure that no committed changes are lost in the event that the master fails.
Geographic Redundancy Geographic redundancy can be achieved by forming HA Groups from MySQL Servers in different data centers. Because MySQL Fabric’s state store is stored in a MySQL Database, that too can be replicated to a remote site.
Linearly scale out both reads and writes Scaling reads is a fairly simple proposition – simply add more read slaves. Scaling writes is more complex and the most widely adopted approach is to partition the rows from a table into different shards where those shards can be stored on different MySQL Servers. MySQL Fabric automates this approach.
User-Selected shard keys By selecting which table columns to use as shard keys, the user is able to ensure that data is evenly distributed between shards and that data that needs to be queried together is co-located for greatest efficiency – for example, all data for a specific subscriber can be stored in the same shard regardless of how many tables their data is spread over.
Shard Functions MySQL Fabric maps the shard key to the shard which stores the associated data. The shard mapping can be based on RANGES (in which case, the user configures the range for each shard) or a HASH function.
Shard Groups Each shard is stored either on a single MySQL Server or in a HA-Group if High Availability is required.
Shard Move If a server needs retiring or is now too small to serve its assigned shard then MySQL Fabric can move the shard to a new server or group of servers. This is completely transparent to the application.
Shard Split If the shard grows too large (or the transaction rate grows too high) for a single server or group of servers then MySQL Fabric can split the shard with the resulting new shard being stored on a new server or group of servers. This is completely transparent to the application.
Load balance reads Automatically load balances queries across the available slaves within a shard (and optionally the master). The user can also assign weights to servers to best exploit heterogeneous pools.
Launch Without Sharding MySQL Fabric is designed to provide High-Availability without sharding – simply create a single HA Group with a master and a single slave. Sharding can then be added when the business needs it and can afford the extra resources.
Evolving Technologies MySQL Fabric currently works with MySQL asynchronous and semisynchronous replication but it has been architected to work with other MySQL technologies and these will be included as MySQL evolves.
Application Transparency As the topology and underlying technologies evolve, the application is protected. Because of the abstraction provided by MySQL Fabric, application developers can focus on adding value to the business though innovative new features rather then keeping up with the changes being made to the underlying database infrastructure.
Conflict & Deadlock Free By containing transactions within a shard and applying standard InnoDB row-based locking, conflicts and deadlock scenarios are avoided.
MySQL Fabric-Aware Connectors
Encapsulated Server Topology and State MySQL Fabric-Aware connectors have knowledge of what servers form part of the farm and what their current states are and they will route transactions and queries accordingly. Because of this, the application does not need to have any knowledge of this information and most importantly, it does not need to be updated when the topology or state information changes. This is key to making the application access to the database simple and maintainable.
Shard Routing The connectors will automatically route queries and transaction to the correct shard based on a shard key provided by the application – notably, the shard key is independent of the server farm topology or the number or size of the shards. Typically the shard key will be a column that already exists and is meaningful to the application – such as a user-id – rather than something that is added to make sharding work.
Writes Sent to Master As well as identifying the correct shard, the connector ensures that writes are sent to the MySQL Master for that shard.
Load Balancing of Reads Typically there will be multiple slaves for each shard. The connector will load balance all of the reads across all of a shard’s slaves.
Failover Transparent to the Application When a slave is promoted to be the new master for a shard then the connector will fetch the updated routing information and ensure that any subsequent writes are sent to the new master.
Resharding Transparent to the Application In the event that a shard is moved to a new server (or pool of servers) or a shard gets too big and is split, the connector will retrieve the updated routing information and ensure that all transactions and queries continue to be routed to the correct server.
Automatic Failure Detection The connectors are constantly communicating with the servers in the managed pool and so are in an unrivaled position to detect when a MySQL Server becomes unavailable. When a MySQL Fabric-Aware connector suspects a failed server, it informs the MySQL Fabric process which combines this information with data from other sources in determining whether to initiate a failover.
System-Wide Coordination
Control of Entire Server Farm A single MySQL Fabric instance has a view of all of the MySQL Servers – both what data each one stores and their current state. When a change is needed (such as a shard split or the promotion of a slave), MySQL Fabric coordinates the entire process.
Global Data There is typically an amount of data that can be most efficiently used if it is held in every server (for example, department information in an employees database) and is joined with sharded data. This data can be provisioned in a Global Group and then replicated to every server/shard in the farm.
Centralized Schema Changes A common schema can be maintained across all shards by performing all schema changes on the Global Group – they will then be replicated to all servers in the farm.
Simple and Efficient Architecture
No Proxies The traditional way to automate routing of transactions and queries to MySQL Servers within a group is by sending them all to a proxy process and then having the proxy perform some analysis and then forward the request to the correct server. This adds latency to each operation and the proxy can also represent a single point of failure or a performance bottleneck. MySQL Fabric avoids this through the use of MySQL Fabric-Aware connectors.
No Agents MySQL Fabric accesses each of the MySQL Servers directly with no need for additional, agent processes.
Meta Data Held in MySQL Use standard MySQL tools (for example mysqldump or MySQL Enterprise Backup)
Extensible Framework Existing services can easily be extended and new ones added – whether by Oracle or you.
Single Source MySQL Fabric has been built by the same expert team responsible for the MySQL Server and MySQL Replication. Get Oracle Premier Support for the entire stack from the people that wrote the code.
Safety & Compatibility for Applications
InnoDB No need to switch to a niche storage engine; stick with the popular and proven InnoDB. This minimizes the changes that need to be made to an application to make it perform with MySQL Fabric.
ACID Perform writes within transactions to ensure full ACID behavior; no need to put your data consistency at risk.
Familiar Tooling Continue to use your favorite MySQL tools with the servers being managed by MySQL Fabric – whether it be MySQL Enterprise Monitor, MySQL WorkBench, MySQL Enterprise Backup, mysqldump, etc. etc.
Reuse MySQL Skills DBAs, developers and Dev-Ops will find that they can continue to exploit their skills when using the servers that are being managed by MySQL Fabric.
Open Source MySQL Fabric is Open Source (licensed under the GPLv2 license) and so developers are free to examine the code base to further understanding or to make changes.
Open APIs to Meta Data All of MySQL Fabric’s information on topology, mappings and status can be read or updated from the command line or through an XML/RPC API (it can also be accessed directly from the state store using SQL). If it makes sense for your application to access this data (for example if you have to use a Fabric-unaware connector) then go ahead!
Connectors MySQL are starting off with MySQL Fabric-Aware Connectors for PHP, Python and Java; further connectors will be brought into the fold. If you are involved with community-sourced MySQL connectors (or you have your own proprietary connector) then we encourage you to use the provided APIs to make them Fabric-Aware.