You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+34-2Lines changed: 34 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -22,15 +22,16 @@ Or install it yourself as:
22
22
$ gem install mysql2-aurora
23
23
24
24
## Usage
25
-
This gem extends Mysql2::Client. You can use `aurora_max_retry`option.
25
+
This gem extends Mysql2::Client. You can use `aurora_max_retry`and `aurora_disconnect_on_readonly` options.
26
26
27
27
```ruby
28
28
Mysql2::Client.new(
29
29
host:'localhost',
30
30
username:'root',
31
31
password:'change_me',
32
32
reconnect:true,
33
-
aurora_max_retry:5
33
+
aurora_max_retry:5,
34
+
aurora_disconnect_on_readonly:true
34
35
)
35
36
```
36
37
@@ -44,8 +45,39 @@ development:
44
45
password: change_me
45
46
reconnect: true
46
47
aurora_max_retry: 5
48
+
aurora_disconnect_on_readonly: true
49
+
47
50
```
48
51
52
+
There are essentially two methods for handling and RDS Aurora failover. When there is an Aurora RDS failover event the primary writable server can change it's role to become a read_only replica. This can happen without active database connections droppping.
53
+
This leaves the connection in a state where writes will fail, but the application belives it's connected to a writeable server. Writes will now perpetually fail until the database connection is closed and re-established connecting back to the new primary.
54
+
55
+
To provide automatic recovery from this method you can use either a graceful retry, or an immediate disconnection option.
56
+
57
+
### Retry
58
+
59
+
Setting aurora_max_retry, mysql2 will not disconnect and automatically attempt re-connection to the database when a read_only error message is encountered.
60
+
This has the benefit that to the application the error is transparent and the query will be re-run against the new primary when the connection succeeds.
61
+
62
+
It is however not safe to use with transactions
63
+
64
+
Consider:
65
+
66
+
* Transaction is started on the primary server A
67
+
* Failover event occurs, A is now readonly
68
+
* Application issues a write statement, read_only exception is thrown
69
+
* mysql2-aurora gem handles this by reconnecting transparently to the new primary B
70
+
* Aplication continues issuing writes however on a new connection in auto-commit mode, no new transaction was started
71
+
72
+
The application remains un-aware it is now operating outside of a transaction, this can leave data in an inconcistent state, and issuing a ROLLBACK, or COMMIT will not have the expected outcome.
73
+
74
+
### Immediate disconnect
75
+
76
+
Setting aurora_disconnect_on_readonly to true, will cause mysql2 to close the connection to the database on read_only exception. The original exception will be thrown up the stack to the application.
77
+
With the database connection disconnected, the next statement will hit the disconnected error and the application can handle this as it would normally when been disconnected from the database.
78
+
79
+
This is safe with transactions.
80
+
49
81
## Contributing
50
82
51
83
Bug reports and pull requests are welcome on GitHub at https://github.com/alfa-jpn/mysql2-aurora.
context'When aurora_disconnect_on_readonly is true'do
56
+
let(:aurora_disconnect_on_readonly){true}
57
+
58
+
before:eachdo
59
+
allow(client).toreceive(:warn)
60
+
allow(client.client).toreceive(:query).and_raise(Mysql2::Error,'ERROR 1290 (HY000): The MySQL server is running with the --read-only option so it cannot execute this statement')
0 commit comments