Fay, it's normal to need to increase the max heap for sstableloader if you
have large data sets. Cheers!
On Wed, Aug 16, 2017 at 1:18 AM, Fay Hou [Storage Service] <
fay...@coupang.com> wrote:
> We do snapshot and sstableloader. with sstableloader, it is ok to have
> different configuration of
We do snapshot and sstableloader. with sstableloader, it is ok to have
different configuration of the "stand by" cluster (i.e. number of the
nodes).
however, there is a issue we ran into with the sstableloader
(java.lang.OutOfMemoryError:
GC overhead limit exceeded)
https://issues.apache.org/jira/
A slight variation to Ben Slater's idea is to build the second cluster
like-for-like and assigning the same tokens used by the original nodes. If
you restore the data onto the equivalent nodes with the same tokens, the
data will be accessible as normal. Cheers!
On Tue, Aug 8, 2017 at 7:08 AM, Robe
The most effective way to "divorce" it is to remove connectivity between
the datacentres. I would put in place firewall rules between the DC's to
stop them from communicating, and then rolling restart one of the DC's. You
should be left with 2 datacentres that see each other as down, and on each
on
For minimum disruption to your production cluster, restoring from backups
is probably the best option. However, there is no reason adding a DC,
building and then splitting shouldn’t work if done correct.
Cheers
Ben
On Tue, 8 Aug 2017 at 07:11 Robert Wille wrote:
> We need to make a copy of a cl
