From b997ebb4cd7c48e247af5fc5a8087cfe0a57b749 Mon Sep 17 00:00:00 2001 From: sougou Date: Mon, 30 Nov 2015 17:54:51 -0800 Subject: [PATCH] Update VTGateV3Features.md --- doc/VTGateV3Features.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/doc/VTGateV3Features.md b/doc/VTGateV3Features.md index effe1c4ec9..216ddd0ea3 100644 --- a/doc/VTGateV3Features.md +++ b/doc/VTGateV3Features.md @@ -28,7 +28,9 @@ If the application already has a well-distributed sharding key, you just have to #### Hashed sharding key If the application's sharding key is a monotonically increasing number, then you may not get well-balanced shards. In such cases, you can ask V3 to route queries based on the hash of the main sharding key. -Vitess's filtered replication currently requires that the hash value be physically present as a column in each table. To satisfy this need, you still need to create a column to store this hash value. However, V3 will take care of populating this on your behalf. *We will soon be removing this restriction once we change filtered replication to also perform the same hashing.* +Vitess's filtered replication currently requires that the hash value be physically present as a column in each table. To satisfy this need, you still need to create a column to store this hash value. However, V3 will take care of populating this on your behalf. + +*We will soon be removing this restriction once we change filtered replication to also perform the same hashing.* #### Auto-increment columns When a table gets sharded, you are no longer able to use MySQL's auto increment functionality. V3 allows you to designate a table in an unsharded database as the source of auto-increment ids. Once you've specified this, V3 will transparently use generated values from this table to keep the auto-increment going. The auto-increment can column can in turn be a basic or hashed sharding key. If it's a hashed sharding key, the newly generated value will be hashed before the query is routed.