-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Readonly schema check path should not use ConsistencyLevel.ALL #37
Comments
Can confirm this is still an issue. For context when running migrations against amazon keyspaces (managed cassandra) only LOCAL_QUORUM is supported. Therefore the
|
This is the offending method: public int getCurrentVersion(final MigrationType type) {
final Statement select = QueryBuilder.select().all().from(SCHEMA_VERSION_CF)
.where(QueryBuilder.eq(TYPE, type.name())).limit(1).setConsistencyLevel(ConsistencyLevel.ALL);
final ResultSet result = session.execute(select);
final Row row = result.one();
return row == null ? 0 : row.getInt(VERSION);
} |
Hi @jackmahoney, The reasoning behind ConsistencyLevel.ALL is that the cluster has to be up and in good state to run any schema changes. If that is not the case you can and will end up with schema inconsistency. This was done on purpose. |
Hi @mgobec , you are probably right about the reason behind using |
Closed by #39 |
In the read only path (when the schema is already up to date), the cassandra queries used to determine that should not use ConsistencyLevel.ALL, they should use QUORUM or LOCAL_QUORUM.
Use case:
We automatically do a schema migration during app startup and always use backward compatible changes so under normal conditions, the schema migration code works great when any one of our app instances is deployed/started.
However, when our second data center is offline for maintenance (a semi normal situation) or nodes are down for problem determination or maintenance or whatever, it's a fairly normal case to bounce our applications. For example, it could be application problem contributing to what's going on.
So the read only path where CassandraVersioner.getCurrentVersion() responds with an version corresponding to 'everything is up to date' for MigrationEngine.Migrator.migrate() fails. We will be putting in some manual code to work around this but we'd like to not do that.
Thanks!
The text was updated successfully, but these errors were encountered: