eavily rely on Kafka for real-time data
>> processing and messaging. However, like any technology, Kafka is
>> susceptible to occasional outages which can disrupt our operations and
>> impact our services. To mitigate the impact of such outages and ensure
>> continuity, we ar
act our services. To mitigate the impact of
such outages and ensure continuity, we are exploring the
possibility of leveraging Cassandra as a backup solution.
Our proposed approach involves storing messages in Cassandra
during Kafka outages. Subsequently, we plan to implement a
messaging. However, like any technology, Kafka is
> susceptible to occasional outages which can disrupt our operations and
> impact our services. To mitigate the impact of such outages and ensure
> continuity, we are exploring the possibility of leveraging Cassandra as a
> backup solution
Subject: Re: Requesting Feedback for Cassandra as a backup solution.
EXTERNAL EMAIL - USE CAUTION when clicking links or attachments
Hi Gowtham,
On the face of it, it sounds like you are planning to use Cassandra for a
queue-like application, which is a well documented anti-pattern. If that&#
e any technology, Kafka is
susceptible to occasional outages which can disrupt our operations and
impact our services. To mitigate the impact of such outages and ensure
continuity, we are exploring the possibility of leveraging Cassandra
as a backup solution.
Our proposed approach involves storing mes
ceptible to occasional outages which can disrupt our operations and
>> impact our services. To mitigate the impact of such outages and ensure
>> continuity, we are exploring the possibility of leveraging Cassandra as a
>> backup solution.
>>
>> Our proposed approach inv
processing and messaging. However, like any technology, Kafka is
> susceptible to occasional outages which can disrupt our operations and
> impact our services. To mitigate the impact of such outages and ensure
> continuity, we are exploring the possibility of leveraging Cassandra as a
&g
, Kafka is susceptible to
occasional outages which can disrupt our operations and impact our
services. To mitigate the impact of such outages and ensure continuity, we
are exploring the possibility of leveraging Cassandra as a backup solution.
Our proposed approach involves storing messages in
I want to discuss the question asked by Rene last year again.
http://www.mail-archive.com/user%40cassandra.apache.org/msg28465.html
Is the following a good backup solution.
Create two data-centers:
- A live data-center with multiple nodes (commodity hardware) (6 nodes with
replication factor of
On Thu, Apr 25, 2013 at 3:04 PM, Daning Wang wrote:
> What is the cassandra solution for remote backup besides multi-center? I
> hope I can do incremental backup to remote database center.
Your semi-automated options which do not involve replicating to a
remote cluster include :
1) tablesnap/ta
Hi Guys,
What is the cassandra solution for remote backup besides multi-center? I
hope I can do incremental backup to remote database center.
Thanks,
Daning
IMHO this is a bad idea.
* You secondary DC will have no redundancy, when you restart it you will be
relying on HH and nodetool repair.
* If your secondary DC machine fails so does the singe copy of your backup.
* There will be additional management overhead for managing an unbalanced DC.
* R
On Mon, Mar 18, 2013 at 7:33 AM, Rene Kochen
wrote:
> Hi Aaron,
>
> Thank you for your answer!
>
> My idea was to do the snapshots in the backup DC only. That way the backup
> procedure will not affect the live DC. However I'm afraid that a
> point-in-time recovery via the snapshots in the second
Hi Aaron,
Thank you for your answer!
My idea was to do the snapshots in the backup DC only. That way the backup
procedure will not affect the live DC. However I'm afraid that a
point-in-time recovery via the snapshots in the second DC (first restore
backup on backup DC and then repair live DC) wi
On Fri, Mar 15, 2013 at 10:35 AM, Rene Kochen
wrote:
> Hi Aaron,
>
> We have many deployments, but typically:
>
> - Live cluster of six nodes, replication factor = 3.
> - A node processes more reads than writes (approximately 100 get_slices
> per/second, narrow rows).
> - Data per node is about 50
Hi Aaron,
We have many deployments, but typically:
- Live cluster of six nodes, replication factor = 3.
- A node processes more reads than writes (approximately 100 get_slices
per/second, narrow rows).
- Data per node is about 50 to 100 GBytes.
- We should recover within 4 hours.
The idea is to
You can consider using a WAN optimization appliance such as a Riverbed
Steelhead to significantly speed up your transfers, though that will cost. It
is a common approach to speed up inter-datacenter transfers. Steelheads for the
AWS EC2 cloud are also available.
(Disclaimer: I used to write so
On Fri, Mar 15, 2013 at 3:12 AM, Rene Kochen
wrote:
> Thank you. I have a high bandwidth connection. But that also means that
> regular repairs on the backup data-center will take a long time.
Honestly, at this point I don't think anyone can provide you any good
feedback based on facts because
the data is going from one data centre to
> another, unless you have a high bandwidth connection between data centres
> or you have a small amount of data.
>
> Jabbar Azam
> On 14 Mar 2013 14:31, "Rene Kochen" wrote:
>
>> Hi all,
>>
>> Is the follo
:31, "Rene Kochen" wrote:
> Hi all,
>
> Is the following a good backup solution.
>
> Create two data-centers:
>
> - A live data-center with multiple nodes (commodity hardware). Clients
> connect to this cluster with LOCAL_QUORUM.
> - A backup data-center with 1
Hi all,
Is the following a good backup solution.
Create two data-centers:
- A live data-center with multiple nodes (commodity hardware). Clients
connect to this cluster with LOCAL_QUORUM.
- A backup data-center with 1 node (with fast SSDs). Clients do not connect
to this cluster. Cluster only
21 matches
Mail list logo
