On Mon, Jul 6, 2015 at 1:30 PM, John Wong wrote:
> But is there a problem with letting schema disagreement running for a long
> time?
>
It depends on what the nature of the desynch is, but generally speaking
there may be.
If you added a column or a columnfamily, and one node didn't get that
upd
Thanks. Yeah we typically restart the nodes in the minor version to force
resync.
But is there a problem with letting schema disagreement running for a long
time?
Thanks.
John
On Mon, Jul 6, 2015 at 2:29 PM, Robert Coli wrote:
>
>
> On Thu, Jul 2, 2015 at 9:31 PM, John Wong wrote:
>
>> Hi Gr
On Thu, Jul 2, 2015 at 9:31 PM, John Wong wrote:
> Hi Graham. Thanks. We are still running on 1.2.16, but we do plan to
> upgrade in the near future. The load on the cluster at the time was very
> very low. All nodes were responsive, except nothing was show up in the logs
> after certain time, wh
On Thu, Jul 2, 2015 at 11:01 PM, graham sanderson wrote:
> What version of C* are you running? Some versions of 2.0.x might
> occasionally fail to propagate schema changes in a timely fashion (though
> they would fix themselves eventually - in the order of a few minutes)
>
>
Hi Graham. Thanks. We
What version of C* are you running? Some versions of 2.0.x might occasionally
fail to propagate schema changes in a timely fashion (though they would fix
themselves eventually - in the order of a few minutes)
> On Jul 2, 2015, at 9:37 PM, John Wong wrote:
>
> Hi.
>
> Here is a schema disagree
Hi.
Here is a schema disagreement we encountered.
Schema versions:
b6467059-5897-3cc1-9ee2-73f31841b0b0: [10.0.1.100, 10.0.1.109]
c8971b2d-0949-3584-aa87-0050a4149bbd: [10.0.1.55, 10.0.1.16,
10.0.1.77]
c733920b-2a31-30f0-bca1-45a8c9130a2c: [10.0.1.221]
We deployed an appli
