In my application logs I've seen that, by default, after running create/alter table statements, cassandra driver seems to do processing to bring schema into agreement for up to 10 seconds.
Can I (and should I) set a consistency level for example 'quorum' while executing DDL statements like 'Create Table .. IF NOT EXISTS' to make sure my table gets created and propagated to all nodes?
On
Changing the Consistency Level does not affect how long the cluster takes to come into agreement. If this is taking 10 seconds on your cluster your client may simply be hitting the default timeout instead of fully waiting for all nodes to come into agreement. Check the Java Driver docs for more information on this process.
Outside of your application you can check the schema state with nodetool describecluster. This will show you if a particular node is not accepting changes to the schema. Here's some more information on resolving schema disagreements from an Operators perspective.
Schema changes (data definition) in Cassandra since 1.1+ are done via gossip. Since it uses Gossip, it is a separate read/write path than your typical data manipulation requests (SELECT, DELETE, INSERT, etc), and hence has no tunable consistency for such operations, since gossip doesn't operate with tunable consistency. From the article I linked, you can see that schema changes are passively announced in the cluster, and furthermore you can get schema disagreement/resolution when you have nodes that were unreachable when the schema change was made.
How often are you modifying your schema? As you can see schema changes, while vastly improved from what it used to be, is still a very expensive operation as every node has to become consistent. Frequent schema changes in Cassandra should be avoided (aka dynamic columns) for this reason. I would be curious to hear how often and why the schema is being change, perhaps you could remodel to avoid dynamic columns/tables to avoid expensive schema changes in Cassandra.