Skip to content

Commit

Permalink
0.10 Release
Browse files Browse the repository at this point in the history
  • Loading branch information
jentfoo committed May 23, 2019
1 parent e1c650f commit 9a82fd3
Show file tree
Hide file tree
Showing 2 changed files with 9 additions and 7 deletions.
12 changes: 7 additions & 5 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
# AuroraArc [![Build status](https://badge.buildkite.com/eccfc05b1cb909831416e399fe015cc14aaae9631e19e5d101.svg)](https://buildkite.com/threadly/nightly-auroraarc)
This project is in extremely early phases (though may be usable). Unless interested in contributing, I would keep looking before bringing this into your projects.

The goal is to provide a fault tollerant, and high performance, driver for AWS's Aurora servers. The driver is designed to be small and light weight, with minimal external dependencies.
The goal is to provide a fault tolerant, and high performance, driver for AWS's Aurora servers. The driver is designed to be small and light weight, with minimal external dependencies.

Include the auroraArc driver into your project from maven central...

Expand All @@ -11,7 +11,7 @@ For MySQL:
<dependency>
<groupId>org.threadly</groupId>
<artifactId>auroraArc-mysql</artifactId>
<version>0.9</version>
<version>0.10</version>
</dependency>
```

Expand All @@ -21,18 +21,20 @@ For Postgresql:
<dependency>
<groupId>org.threadly</groupId>
<artifactId>auroraArc-psql</artifactId>
<version>0.8</version>
<version>0.10</version>
</dependency>
```

## How stable is it?

This is still a work in progress. Like most open source projects this project is use at your own risk. The 0.1 release will indicate a point of some initial stability, typically against JDBI / HikariCP / manual use. Use in other tools are more likely to uncover unexpected behavior. If there is a specific tooling configuration you would like tested or are curious about please open an issue.
Like most open source projects this project is use at your own risk. At this point we have reached a usable level of stability. A version 1.0 release will indicate that we feel it has reached API and functionality stability. There are still many basic improvements that I think are important to accomplish before that release.

At this point the driver is functionally stable. Stability improvements in the most recent months have been more edge cases with only incremental improvements. This driver has had extensive production usage now. At least one company has used this driver as their primary JDBC driver for most back end services for well over a year. This has allowed us to work out some even some uncommon condition improvements. This has been used and tested most extensively with JDBI + HikariCP or direct manual use. Use in other tools are more likely to uncover unexpected behavior. If there is a specific tooling configuration you would like tested or are curious about please open an issue.

## How it works
This project currently works by having each aurora "Connection" actually be a management layer which under the hood is selecting the connection to the actual aurora host to be used. The primary reason for this is we can then depend on the normal, and battle tested, MySQL jdbc connector (in the future we may allow any delegated driver to be used). Resulting in the primary concern of this driver to become when we can change the underline connection, and which connection to select to distribute load across the cluster evenly.

The driver aims to faciliate taking advantages of Aurora's low secondary read slave's latency by allowing the connection to be directed to a random (but healthy) secondary server when the connection is set to be `read only`. In conditions where no healthy secondary server is available, the primary will be used for these read only requests.
The driver aims to facilitate taking advantages of Aurora's low secondary read slave's latency by allowing the connection to be directed to a random (but healthy) secondary server when the connection is set to be `read only`. In conditions where no healthy secondary server is available, the primary will be used for these read only requests.

One of the most significant advantages to Aurora is how fast failovers can be. Supporting this in the best way possible was a primary motivation in building this driver. Our drivers aurora connections are able to share a common view of the cluster. Meaning that failover events are recognized quickly, maybe from the cluster monitoring itself, or as one connection has issues, it can initiate checks to try and minimize failures. We also do best effort attempts, for example if the master server has gone down without a clear replacement yet we will attempt to leverage the secondary servers to and maintain what we can for read only actions.

Expand Down
4 changes: 2 additions & 2 deletions gradle.properties
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
group = org.threadly
version = 0.10-SNAPSHOT
version = 0.10

threadlyVersion = 5.36
threadlyVersion = 5.37
mysqlVersion = 8.0.16
psqlVersion = 42.2.5

Expand Down

0 comments on commit 9a82fd3

Please sign in to comment.