Why am I getting this error for xadd.
Redis: 6.2
127.0.0.1:6379> xadd hello 1658902141-* key val
(error) ERR Invalid stream ID specified as stream command argument
127.0.0.1:6379> xadd hello 1658902141000-* key val
(error) ERR Invalid stream ID specified as stream command argument
127.0.0.1:6379> XADD mystream 1526919030474-* message " World!"
(error) ERR Invalid stream ID specified as stream command argument
Event id with timestamp-* format, is a new feature of Redis-7.0. You should check your Redis version. If it's an older version, you cannot use this feature.
If you want to achieve the goal, i.e. fix timestamp, while increase the counter, you have to do it on client side. Or use '*' as ID, to make Redis automatically generating id with an increasing timestamp.
Related
after set myKey as key in Redis with foobar value
I want to get the BITCOUNT of myKey.
this command in Redis-CLI giving me an error: BITCOUNT myKey 2 3 BYTE
(error) ERR syntax error
how can I solve this?
BYTE argument is fairly new and (will be) added in Redis 7.0. So far, only 7.0.0rc3 is released but no GA.
I assume you are using a pre Redis 7 version?
When I directly run the below GET command in my redis cloud,
GET 1000:125:1603875000
I am getting error
WRONGTYPE Operation against a key holding the wrong kind of value redis
When I check
type 1000:125:1603875000
gives me
Hash
But if I execute SET before Get, like this
SET 1000:125:1603875000 11
I get "11" on executing GET command.
Why does the string is considered as Hash? How can I execute GET with the specified string.
That's because when you RUN 'SET 1000:125:1603875000' to 11, you are overwriting the initial '1000:125:1603875000' which was a hash and once you set '1000:125:1603875000' as '11' you can run a GET command to get the value of the key.
To get the value of a redis hash you can run HGETALL to get all the values in the hash or HGET KEYNAME to get a specific key of the hash.
To illustrate the use of these commands:
127.0.0.1:6379> HSET employee name Ankit
(integer) 1
127.0.0.1:6379> GET employee
(error) WRONGTYPE Operation against a key holding the wrong kind of value
127.0.0.1:6379> HGETALL employee
1) "name"
2) "Ankit"
127.0.0.1:6379> HGET employee name
"Ankit"
127.0.0.1:6379> SET employee Ankit
OK
127.0.0.1:6379> GET employee
"Ankit"
127.0.0.1:6379>
I need to see when the key is saved lastly.
But its returning an error for the command
redis-cli lastsave "mykey"
(error) ERR wrong number of arguments for 'lastsave' command
Read the docs - LASTSAVE accepts 0 arguments and reports the last time that the entire database was persisted.
Calling XREAD after XDEL will not block on the stream, but return immediately. Expected behavior is for XREAD to block again.
127.0.0.1:6379> XADD my-stream * field1 string1
"1554300150697-0"
127.0.0.1:6379> XREAD BLOCK 5000 STREAMS my-stream 1554300150697-0
(nil)
(5.07s)
127.0.0.1:6379> XADD my-stream * field2 string2
"1554300285984-0"
127.0.0.1:6379> XREAD BLOCK 5000 STREAMS my-stream 1554300150697-0
1) 1) "my-stream"
2) 1) 1) "1554300285984-0"
2) 1) "field2"
2) "string2"
127.0.0.1:6379> XDEL my-stream 1554300285984-0
(integer) 1
127.0.0.1:6379> XLEN my-stream
(integer) 1
127.0.0.1:6379> XREAD BLOCK 5000 STREAMS my-stream 1554300150697-0
1) 1) "my-stream"
2) (empty list or set)
127.0.0.1:6379>
As you can see above, the first time XREAD is called it blocks for 5s - expected.
The second call to XREAD returns immediately, giving the new entry - expected.
The third call to XREAD return immediately with (empty list or set) - not expected!
Expected: The command should block for 5s.
I'm not sure if this is a bug or if there's something that I'm missing out. Please advise.
Thank you
It looks like you're running into this known bug.
See the second comment in particular, which points out that the partial fix supplied does not fix the issue you're running into:
It's not an entire fix for the blocking issue, since it only fixes the blocking behaviour for empty streams.
If the stream still contains some entries, but none with a larger ID than requested by the last-received-id parameter, then the request is still answered synchronously with an empty result list.
Looking through 5.0.4's source code I've found a way to (re)set ->last_id member through an undocumented command: XSETID
Although in the source code https://github.com/antirez/redis/blob/f72f4ea311d31f7ce209218a96afb97490971d39/src/t_stream.c#L1837 it says the syntax is XSETID <stream> <groupname> <id>, it's in fact XSETID <stream> <id>(there's an open issue on this one: https://github.com/antirez/redis/issues/5519 but I hope they'd add a new command for groups, like XGROUPSETID, and let this one as it is), which was exactly what I was looking for, so doing:
XSETID my-stream 1554300150697-0
would make:
127.0.0.1:6379> XREAD BLOCK 5000 STREAMS my-stream 1554300150697-0
(nil)
(5.08s)
127.0.0.1:6379>
to work as expected - it will block.
For anyone using this solution(which is more like a workaround in my opinion): Please use it with caution because in a high throughput machine/system/environment Redis could generate/add a new my-stream entry with the same ID as the deleted one 1554300285984-0 leading to possible duplicate data on client's side.
I've created a Redis stream:
XADD mystream * foo bar
And I've associated it with a consumer group:
XGROUP CREATE mystream mygroup $
Now I want to delete it, so that Redis acts as though the stream had never existed. How do I delete it?
I've tried using XTRIM:
XTRIM mystream MAXLEN 0
This successfully puts the length of the stream to zero. But it doesn't fully delete the stream, as attempts to XREADGROUP still succeed and do not return the typical error when this method is called without the group existing:
XREADGROUP GROUP mygroup myconsumer COUNT 1 STREAMS mystream >
Actual output:
(nil)
Expected output:
NOGROUP No such key 'mystream' or consumer group 'mygroup' in XREADGROUP with GROUP option
Just use the DEL command:
DEL mystream
Pretty straightforward answer, right away from the first search online.
Just execute:
DEL stream_name
XTRIM only removes the data within the stream, but does not delete the stream itself or any groups associated to it.