Thanks Jeff!
On Mon, Sep 18, 2017 at 9:31 AM, Jeff Jirsa wrote:
> Haven't tried out CDC, but the answer based on the design doc is yes - you
> have to manually dedup CDC at the consumer level
>
>
>
>
> --
> Jeff Jirsa
>
>
> On Sep 17, 2017, at 6:21 PM, Mi
eve it's used by many, if any. it certainly hasn't had enough
> attention to determine it production ready, nor has it been out long enough
> for many people to be in a version where cdc is available. FWIW I've never
> even seen any inquiries about using it.
>
> On 17
anyone?
On Wed, Sep 13, 2017 at 5:10 PM, Michael Fong wrote:
> Hi, all,
>
> We've noticed there is a new feature for streaming changed data other
> streaming service. Doc: http://cassandra.apache.org/doc/latest/operating/
> cdc.html
>
> We are evaluating the stabil
Hi, all,
We've noticed there is a new feature for streaming changed data other
streaming service. Doc: http://cassandra.apache.org/doc/latest/operating/cdc
.html
We are evaluating the stability (and maturity) of this feature, and
possibly integrate this with Kafka (associated w/ its connector). H
general way to recover
the mysteriously-deleted data when the timestamp meta is screwed up.
Thanks in advanced,
Regards,
Michael Fong
on-the-fly. We are
thinking to do a nodetool resetlocalschema to force the schema synchronization.
How safe is this method? Do we need to disable thrift/gossip protocol before
performing this function, and enable them back after resync completes?
Thanks in advance!
Sincerely,
Michael Fong
,
Michael Fong
storm begins.
Also, thanks for your tip on sharing the SOP on stopping an ode, here is what
we have for our stop procedure:
Disable thrift
Disable Binary
Wait 10s
Disable gossip
Drain
Kill
Any thought on this to be further improved?
Thanks!
Sincerely,
Michael Fong
From: Alain RODRIGUEZ
Hi,
Thanks for your recommendation.
I also opened a ticket to keep track @
https://issues.apache.org/jira/browse/CASSANDRA-11748
Hope this could brought someone's attention to take a look. Thanks.
Sincerely,
Michael Fong
-Original Message-
From: Michael Kjellman [mailto:m
Hi,
I have filed a jira ticket to keep tracked @
https://issues.apache.org/jira/browse/CASSANDRA-11624
Thanks!
Sincerely,
Michael Fong
From: Marcus Eriksson [mailto:krum...@gmail.com]
Sent: Wednesday, March 23, 2016 10:47 PM
To: user@cassandra.apache.org
Subject: Re: Effectiveness of Scrub
but need experts help on this.
I don't know if anyone has seen this before, or if there is anything wrong with
our migration flow though..
Thanks in advance.
Best regards,
Michael Fong
From: Michael Fong [mailto:michael.f...@ruckuswireless.com]
Sent: Thursday, April 21, 2016 6:
ation task for /192.168.88.34
DEBUG [OptionalTasks:1] 2016-04-19 11:19:18,337 MigrationManager.java (line
127) submitting migration task for /192.168.88.34
.
Has anyone experienced this scenario? Thanks in advanced!
Sincerely,
Michael Fong
From: Michael Fong [mailto:michael.f...@ruckuswireless
.8. Thanks in advance!
Sincerely,
Michael Fong
ol:273 ERROR - Transport
exception in re-opening client in release on
:{localhost(127.0.0.1):9160}
Has anyone had similar experience? The operating system is Ubuntu and kernel
version is 2.6.32.24. Thanks in advance!
Sincerely,
Michael fong
From: Alain RODRIGUEZ [mailto:arodr...@gmail.com
busy
compaction activities would cause this behavior, but we cannot reason why this
could happen logically. How come a compaction operation would stop the Gossip
thread to perform heartbeat check? Has anyone experienced this kind of behavior
before?
Thanks in advanced!
Sincerely,
Michael Fong
. :(
After going through the source code of C* 1.2.15, the serialized gossip
heartbeat message (SYN/ACK/ACK2) seem to contain 1. Cluster name, 2.
Partitioner name in the payload. Perhaps I could grep the gossip heartbeat
packet by filtering this criteria?
Sincerely,
Michael Fong
From: sean_r_dur
Hi, all,
We are trying to reason the possible scenarios when a C*(v1.x) cluster
connection keeps flapping in production. (Two node cluster, each node keeps
marking the other node DOWN but came back UP within seconds; multiple times a
day) We have checked the load on the cluster i- very light a
(sstables))
return null;
...
If it is true, would this flow - marking corrupted sstable in blacklist, defeat
the original purpose of scrub operation? Thanks in advanced!
Sincerely,
Michael Fong
18 matches
Mail list logo