Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 13FE6101FC for ; Mon, 9 Sep 2013 15:08:29 +0000 (UTC) Received: (qmail 61987 invoked by uid 500); 9 Sep 2013 15:08:26 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 61953 invoked by uid 500); 9 Sep 2013 15:08:24 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 61945 invoked by uid 99); 9 Sep 2013 15:08:24 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Sep 2013 15:08:24 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of alex.heneveld@cloudsoftcorp.com designates 209.85.212.177 as permitted sender) Received: from [209.85.212.177] (HELO mail-wi0-f177.google.com) (209.85.212.177) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Sep 2013 15:08:19 +0000 Received: by mail-wi0-f177.google.com with SMTP id cb5so3530878wib.10 for ; Mon, 09 Sep 2013 08:07:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudsoftcorp.com; s=google; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=3rI++NyoJsAU+kR7QPlwl+F4vK8GsZtF64l+Zt0RUc0=; b=HIQvwPIjiwWh8K8qYw1u5JDcmurFEYZcOiHudWIdHxN2qpjwIwRZ3yulEIkB9XCG00 YWJUaCOQkOHd8paCDhSAXwEDZSR79eQKZL8iPUWOtxHWcPQ5/a07xav5fKGOsxAWKABt IBb5C501K2iIsfX0Cl9L8jP7EpjgiGyBbVnVM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=3rI++NyoJsAU+kR7QPlwl+F4vK8GsZtF64l+Zt0RUc0=; b=ObDvChKH9QITFWRMeRSQiddQNa6srQhA9gPHiWIR7eSvf6/s4ZmyZ+Tu1VafOlCTDk JFEcaSrm43dDdH+IPFjWkxwiR0zjhWPulJAvJQ3BHHezEHfdYOpAy7+waCMhVvuwP54c weT+Pyci9E1pcm80q3uMeGox4N40nxctGnR04700rC1Cl4xQI6EZ+lcg6Na4rZsMuYqT xVX0TZwWpakZtDgx7hPwCJIbDoawtrxxrm7nB/pbH9JOah1iNl+vlzSI5O1YHsScqhh/ 12LrSDx0U0SeSvzzpVdDExfNZ8N4X45sUSf7XBb0zaBrpcol6QwkokhGenmflDKJVeQq ldpw== X-Gm-Message-State: ALoCoQkHaRHOh+UCsuKUtzXIu6ah5jApl+LGMCNhRbu4eOgrQQuoUOna4rSh7Mix86xuZO30I39Z X-Received: by 10.180.183.108 with SMTP id el12mr8713141wic.55.1378739277623; Mon, 09 Sep 2013 08:07:57 -0700 (PDT) Received: from almacretin.local (fluency-gw1.summerhall.co.uk. [91.240.174.34]) by mx.google.com with ESMTPSA id li9sm5941646wic.4.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Sep 2013 08:07:56 -0700 (PDT) Message-ID: <522DE44A.50602@CloudsoftCorp.com> Date: Mon, 09 Sep 2013 16:07:54 +0100 From: Alex Heneveld User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: user@cassandra.apache.org Subject: SchemaDisagreementError when launching a new Cassandra (1.2.2) cluster ? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Hi folks, I'm occasionally seeing SchemaDisagreementError on the boot of a *new* cluster. I'm hoping someone can explain what I'm doing wrong, or help me track down the bug if it is one. The problem occurs in about 1 in 4 launches when I start a 2-node cluster, where the two machines are configured identically with both nodes as the seeds (apart from the listen_address being different). On the problematic launches, describing schema versions immediately after start shows that the two nodes have different schemas (reported at both nodes) and any attempt to work with the nodes returns the SDE. This is before I attempt to do anything to the cluster. After ~60s the nodes reconcile their differences, report a single schema used at both nodes, and I can use the cluster without problems. Key points: * The problem usually fixes itself 60s after startup (almost exactly, I poll every second) * The problem is intermittent occurring on between 10% and 50% of launches (failure rates seem higher at peak cloud times -- so possibly linked to background CPU/network/storage contention) * For the problem period (the initial 60s), peer size is reported as 2, and both nodes report the same schema versions map containing two schemas each with one of the nodes against them (after 60s the map contains one schema with both nodes) * In some of the problematic launches, it takes ~120s to reconcile, where for the first 60s the nodes do not seem to see each other at all (each reports peer size 1, and a a single schema used by only one node (itself)), then for the next 60s the problem is as described above (disagreeing schemas); again the 60s/120s seems meaningfully precise * The problem occurs whether the two nodes are launched simultaneously or are launched with a delay between the two I have a workaround, which is to use just one node to seed this initial set. When the set of seeds is cardinality 1, the problem does not occur. However the advice is to use 2 seeds and have them be the same across the cluster -- so I'd like to get to the bottom of this! I'd also like to be sure that any subsequent nodes added to the cluster aren't going to cause the same problem when we start using it! I am running Cassandra 1.2.2 running in Amazon, using Brooklyn (brooklyn.io) to start and manage it. I can share test cases, cassandra.yaml, logs, etc -- but am starting with the above summary in case anyone can point me in the right direction from that. Thanks, Alex