TSM Bug Fixes/Go 1.4.3 #5331
TSM Bug Fixes/Go 1.4.3 #5331
Conversation
We were closing the cursor when we read the last block which caused the internal state to be cleared. In a group by query, we seeked multiple times so depending on the group by interval and how the data was laid out in the blocks, we woudl close the cursor and the last block would get skipped. Fixes #5193
|
👍 |
| @@ -7,7 +7,7 @@ if [ $fmtcount -gt 0 ]; then | |||
| fi | |||
|
|
|||
| # Due to the way composites work, vet will fail for some of our tests so we ignore it | |||
|
@rossmcdonald Can you take a look and make sure I didn't miss anything from the packaging side? |
data engine config var is ignored now and you can only create tsm1 shards. Exists shards will work as is until they are migrated to tsm1 shards.
|
+1, looks good to me! |
|
Hi, But it looks like it hasn't yet been updated, firstly the date is still 11th Jan and secondly its still using go 1.5 2016/01/12 09:36:16 InfluxDB starting, version 0.10.0-nightly-72c6a51, branch master, commit 72c6a51, built 2016-01-11T05:00:46+0000 Should I just be more patient :-)? |
|
@ivanscattergood I'm looking into why that build is failing. In the meantime you should be able to use this one: https://s3-us-west-1.amazonaws.com/influxdb-nightly/influxdb-nightly.x86_64.rpm |
|
Hi Ross, It works well in our dev environment, but when I promoted it to UAT then I got this error on startup: [tsm1wal] 2016/01/13 05:56:35 tsm1 WAL writing to /var/lib/influxdb/wal/open_access_db/detail/63 goroutine 80 [running]: Here is the output of an ls on that directory: [root@RBC-visual-edge pe]# ls -ltra /var/lib/influxdb/wal/open_access_db/detail/63 |
|
@rossmcdonald I have tried removing the whole WAL directory, but that didn't help . I have reverted to 0.9.6.1 in UAT and all is well. I'll try the nightly version with a fresh DB on Friday as this will give the users a couple of days of data to look at on Monday. |
|
@ivanscattergood the normal nightly build should be back to normal as of tonight's build (we're rebuilding now), and compiled with Go 1.4.3 going forward. definitely let us know if you see that same issue after starting with a fresh database. thanks! |
|
The file at https://s3.amazonaws.com/influxdb/influxdb-nightly-1.x86_64.rpm appears to be built from 72c6a51 still? |
|
@KiNgMaR The link is now: https://s3.amazonaws.com/influxdb/influxdb-nightly.x86_64.rpm We'll be getting this fixed on the Downloads page later today. |
|
@rossmcdonald please, can you explain why have you changed the link? |
|
@zstyblik Sure, the build.py script doesn't include the package iteration (the '-1' in influxdb-nightly-1) in the package filename since a package iteration for a nightly isn't very meaningful. Also this is to match the naming of the nightly 'deb' packages as well. |
|
@rossmcdonald I'd be good to think about people on the other side of the wall, eg. with automated builds, too. |
|
Hi, Just thought I'd let you know I have now moved to the 0.10.0-beta1 release in DEV and UAT, and everything is looking good. +1 |
This PR fixes #5193 #5283 and #5217 .
#5193 was caused by the tsm cursor getting closed prematurely causing future seeks to return no data.
#5283 appears to be a go 1.5.2 related bug as switching back to 1.4.3 did not produce the same panic.
#5217 is related to the performance degradation from using go 1.5.2. This PR switches the builds to 1.4.3.
This also changes the default storage engine to
tsm1and removes the ability to configure other engines. Existingb1andbz1shards will load and work as is, but should to be converted totsm1at some point using the migration tool.