<commit_before># Makara: *A Read-Write splitting adaptor for Active Record*

## What?

Makara allows your Rails applications to use read-write splitting to share the load across multiple database servers. 

Read-Write splitting is the notion that if you have synchronized database, you can send all "write queries" (insert, update, delete) to a master database, and preform all of your "read queries" (select) from a number of slaves.  As most Rails applications are read-heavy, this scaling practice is very desirable.
 
## Features

* Read/Write splitting across multiple databases
* Failover upon slave errors/loss
* Automatic reconnection attempts to lost slaves
* Optional "sticky" connections to master and slaves
* Works with many database types (mysql, postgres, etc)

## What is a sticky connection?

Often times your application will write data and then quickly read it back (user registration is the classic example).  It it is possible that your application stack may preform faster than your database synchronization (especially across geographies).  In this case, you may opt to hold "sticky" connections to ensure that for the remainder of a request, your web-worker (Thin, Mongrel, Unicorn, etc) remains connected to the master of the slave it had been previously reading from to ensure a consistent experience. 

## Failover

If an error is raised while attempting a query on a slave, the query will be retried on another slave (or the master DB), and the slave with the error will be blacklisted.  Every so often, Makara will attempt to reconnect to these lost slaves.  This ensures the highest possible uptime for your application.<commit_msg>a moderatly useful readme<commit_after># Makara: *A Read-Write splitting adaptor for Active Record*

## What?

Makara allows your Rails applications to use read-write splitting to share the load across multiple database servers. 

Read-Write splitting is the notion that if you have synchronized database, you can send all "write queries" (insert, update, delete) to a master database, and preform all of your "read queries" (select) from a number of slaves.  As most Rails applications are read-heavy, this scaling practice is very desirable.
 
## Features

* Read/Write splitting across multiple databases
* Failover upon slave errors/loss
* Automatic reconnection attempts to lost slaves
* Optional "sticky" connections to master and slaves
* Works with many database types (mysql, postgres, etc)

## What is a sticky connection?

Often times your application will write data and then quickly read it back (user registration is the classic example).  It it is possible that your application stack may preform faster than your database synchronization (especially across geographies).  In this case, you may opt to hold "sticky" connections to ensure that for the remainder of a request, your web-worker (Thin, Mongrel, Unicorn, etc) remains connected to the node it had been previously reading from to ensure a consistent experience. 

## Failover

If an error is raised while attempting a query on a slave, the query will be retried on another slave (or the master DB), and the slave with the error will be blacklisted.  Every so often, Makara will attempt to reconnect to these lost slaves.  This ensures the highest possible uptime for your application.
{'fraction_non_alphanumeric': 0.045167118337850046, 'fraction_numerical': 0.0, 'mean_word_length': 4.737478411053541, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5668967', 'n_tokens_mistral': 783, 'n_tokens_neox': 758, 'n_words': 495}