This manual consists of three parts,
INSTALLATION,
TUTORIAL,
COMMAND REFENENCE,
and FILE FORMATS.
For design documentation and background knowledge,
please refer to the URLs listed in the SEE ALSO section.

The tutorial explains how to create a microblog service (like twitter) running on four database shards. Incline (by itself) does not support adding database nodes without stopping the service. If you are interested in such feature, please refer to the documentation of Pacific after reading this tutorial.

At least four tables are needed to create a microblog service on database shards. Instead of a single table representing follower <=> followee relationship, each user needs to have a list of followers (or list of following users) to him / her on his / her database shard. Also, each user need to have his / her `timeline' table on his / her shard (or else the service would not scale out). The example below is a minimal schema on MySQL. All shards should have the same schema applied. Two tables, `following' and `tweet' will be modified by the application. `Follower' and `timeline' tables will be automatically kept (eventually) in sync by incline with the former two tables.

To keep `follower' and `timeline' tables in sync with the other two, replication rules should be defined. The example below show the definition corresponding to the table schema above.

The first hash defines how the `follower' tables should be kept synchronized to the `following' tables. `Following_id' and `user_id' columns of `following' tables are mapped to `user_id' and `follower_id' columns of `follower' tables, and `follower' tables are sharded using the `user_id' column.

The second hash defines how the `timeline' tables should be constructed from the `follower' tables and `tweet' tables. In addition to the definitions of `pk_columns' and `shard-key', `merge' property of the hash defines how the two source tables should be merged (using INNER JOIN).

Another definition file is required when using incline for synchronizing database shards. The following example represents a distributed database with four shards using range partitioning. First node with the IP address 10.1.1.1 handles ids from 0 to 9999, second node (10.1.1.2) handles 10000 to 19999, third (10.1.1.1.3) handles 20000 to 29999, fourth (10.1.1.4) handles ids equal to or greater than 3000.

The next step is to install triggers and to create queue tables using the definitions files. The following commands create queue tables and installs triggers on the database running on 10.1.1.1. The commands should be applied to all of the database shards.

You should automatically restart the forwarder when it exits (it exits under certain conditions, for example, when it loses connection to the attached shard, or when the shard definition is being updated).

Reads the definition files and forwards the data from the specified database node to other nodes (only works if --mode is set to either `queue-table' or `shard'). The process will stop when connection to the specified database closes or when the shard definition file is being updated.

The mode is for running incline on a single database node. All updates are queued into the queue tables generated by the `create-queue' command. The queued updates are applied by the `forward' command.

The mode is for running incline on multiple database nodes (shards). Updates that should be applied to the same shard are applied synchronously. Other updates are pushed into the queue tables generated by the `create-queue' command. The queued updates are applied to other nodes by the `forward' command.

The definition consists of an array. Each element represents a single replication definition as a hash: between one `destination' table and more than one `source' tables. The hash may contain following keys.

maps columns of source tables(s) to the columns of the destination table consisting the primary key. Source column should include the name of the table when using multiple source tables (like: "src_table_a.column").

The node definitions in nodes or map should be a hash or a array of hashes with following key-value pairs. When using arrays of hashes, incline will only use the first element of the array. Other elements in the array may be used by other middlewares such as Pacific, for example for defining slave database nodes.