| 2013-03-07 14:58:20 |
Evan |
bug |
|
|
added bug |
| 2013-03-07 15:02:52 |
Evan |
description |
In a number of places we're now retrying counter mutations. This was seen as being better than failing hard and the client sending all the data again, causing disruption to column families beyond the counter-based CF that was being incremented.
This is actually okay so long as we do two things:
1) Keep an equal number of columns somewhere else in the database. For example, we have DayBuckets and DayBucketsCount, the latter being the length of each row in DayBuckets.
2) We periodically repair the potentially-overcounted column families by processing the columns from #1 into the counters. |
In a number of places we're now retrying counter mutations. This was seen as being better than failing hard and the client sending all the data again, causing disruption to column families beyond the counter-based CF that was being incremented.
This is actually okay so long as we do two things:
1) Keep an equal number of columns somewhere else in the database. For example, we have DayBuckets and DayBucketsCount, the latter being the length of each row in DayBuckets.
2) We periodically repair the potentially-overcounted column families by processing the columns from #1 into the counters.
Fixing this will address one of the two causes of OOPSes on daisy.ubuntu.com at present, a MaximumRetryException ("Retried 1 times. Last failure was TTransportException: TSocket read 0 bytes"). The other cause is reports with signatures larger than 65535, which is fixed in daisy trunk. |
|
| 2013-03-07 15:03:15 |
Evan |
daisy: importance |
Undecided |
High |
|
| 2013-03-07 15:03:15 |
Evan |
daisy: status |
New |
Confirmed |
|
| 2013-03-07 15:05:22 |
Evan |
description |
In a number of places we're now retrying counter mutations. This was seen as being better than failing hard and the client sending all the data again, causing disruption to column families beyond the counter-based CF that was being incremented.
This is actually okay so long as we do two things:
1) Keep an equal number of columns somewhere else in the database. For example, we have DayBuckets and DayBucketsCount, the latter being the length of each row in DayBuckets.
2) We periodically repair the potentially-overcounted column families by processing the columns from #1 into the counters.
Fixing this will address one of the two causes of OOPSes on daisy.ubuntu.com at present, a MaximumRetryException ("Retried 1 times. Last failure was TTransportException: TSocket read 0 bytes"). The other cause is reports with signatures larger than 65535, which is fixed in daisy trunk. |
In a number of places we're now retrying counter mutations. This was seen as being better than failing hard and the client sending all the data again, causing disruption to column families beyond the counter-based CF that was being incremented.
This is actually okay so long as we do two things:
1) Keep an equal number of columns somewhere else in the database. For example, we have DayBuckets and DayBucketsCount, the latter being the length of each row in DayBuckets.
2) We periodically repair the potentially-overcounted column families by processing the columns from #1 into the counters.
Fixing this will address one of the two causes of OOPSes on daisy.ubuntu.com at present, a MaximumRetryException ("Retried 1 times. Last failure was TTransportException: TSocket read 0 bytes"). The other cause is reports with signatures larger than 65535, which is fixed in daisy trunk.
Ebay talks a bit about the repair approach in their Cassandra data modelling blog series:
http://www.ebaytechblog.com/2012/08/14/cassandra-data-modeling-best-practices-part-2/ |
|
| 2013-03-07 15:46:59 |
Brian Murray |
bug |
|
|
added subscriber Brian Murray |
| 2013-04-01 23:52:00 |
Haw Loeung |
bug |
|
|
added subscriber Haw Loeung |
| 2014-09-19 16:55:04 |
Haw Loeung |
removed subscriber Haw Loeung |
|
|
|
