diff --git a/config/mycnf/default-fast.cnf b/config/mycnf/default-fast.cnf index 833c259595d..53f38151431 100644 --- a/config/mycnf/default-fast.cnf +++ b/config/mycnf/default-fast.cnf @@ -61,5 +61,5 @@ tmpdir = {{.TmpDir}} tmp_table_size = 32M transaction-isolation = REPEATABLE-READ # READ-COMMITTED would be better, but mysql 5.1 disables this with statement based replication -# READ-UNCOMMTTED might be better +# READ-UNCOMMITTED might be better lower_case_table_names = 1 diff --git a/config/mycnf/default.cnf b/config/mycnf/default.cnf index ddd40998f9b..1b2031bd0ec 100644 --- a/config/mycnf/default.cnf +++ b/config/mycnf/default.cnf @@ -61,5 +61,5 @@ tmpdir = {{.TmpDir}} tmp_table_size = 32M transaction-isolation = REPEATABLE-READ # READ-COMMITTED would be better, but mysql 5.1 disables this with statement based replication -# READ-UNCOMMTTED might be better +# READ-UNCOMMITTED might be better lower_case_table_names = 1 diff --git a/doc/ReplicationGraph.md b/doc/ReplicationGraph.md index 8dc81767a92..17baa238ad9 100644 --- a/doc/ReplicationGraph.md +++ b/doc/ReplicationGraph.md @@ -1,7 +1,7 @@ # Replication Graph The replication graph contains the mysql replication information for a shard. Currently, we only support one layer -of replication (a single master wiht multiple slaves), but the design doesn't preclude us from supporting +of replication (a single master with multiple slaves), but the design doesn't preclude us from supporting hierarchical replication later on. ## Master @@ -14,7 +14,7 @@ When creating a master (using 'vtctl InitTablet ... master'), we make sure Maste The slaves are added to the ShardReplication object present on each local topology server. So for slaves, the replication graph is colocated in the same cell as the tablets themselves. This makes disaster recovery much easier: -when loosing a data center, the replication graph for other data centers is not lost. +when losing a data center, the replication graph for other data centers is not lost. When creating a slave (using 'vtctl InitTablet ... replica' for instance), we get the master record (if not specified) from the MasterAlias of the Shard. We then add an entry in the ReplicationLinks list of the ShardReplication object for the tablet’s cell (we create ShardReplication if it doesn’t exist yet). diff --git a/doc/Tools.md b/doc/Tools.md index 601d4605dd3..e2c24093c19 100644 --- a/doc/Tools.md +++ b/doc/Tools.md @@ -56,7 +56,7 @@ This is useful for trouble-shooting, or to get a good high level picture of all the servers and their current state. ### vtworker -vtworker is meant to host long-running processes. It supports a plugin infrastructure, and offers libraries to easily pick tablets to use. We have developped: +vtworker is meant to host long-running processes. It supports a plugin infrastructure, and offers libraries to easily pick tablets to use. We have developed: - resharding differ jobs: meant to check data integrity during shard splits and joins. - vertical split differ jobs: meant to check data integrity during vertical splits and joins. diff --git a/doc/ZookeeperData.md b/doc/ZookeeperData.md index f0442b3d8df..a5437ece079 100644 --- a/doc/ZookeeperData.md +++ b/doc/ZookeeperData.md @@ -71,7 +71,7 @@ type Shard struct { } // SourceShard represents a data source for filtered replication -// accross shards. When this is used in a destination shard, the master +// across shards. When this is used in a destination shard, the master // of that shard will run filtered replication. type SourceShard struct { // Uid is the unique ID for this SourceShard object. diff --git a/go/cmd/vtworker/split_clone.go b/go/cmd/vtworker/split_clone.go index 782bb4a464c..59f1cf32149 100644 --- a/go/cmd/vtworker/split_clone.go +++ b/go/cmd/vtworker/split_clone.go @@ -71,7 +71,7 @@ const splitCloneHTML2 = `
  • populateBlpCheckpoint: creates (if necessary) and populates the blp_checkpoint table in the destination. Required for filtered replication to start.
  • dontStartBinlogPlayer: (requires populateBlpCheckpoint) will setup, but not start binlog replication on the destination. The flag has to be manually cleared from the _vt.blp_checkpoint table.
  • skipAutoIncrement(TTT): we won't add the AUTO_INCREMENT back to that table.
    • -
  • skipSetSourceShards: we won't set SourceShards on the destination shards, disabling filtered replication. Usefull for worker tests.
    • +
  • skipSetSourceShards: we won't set SourceShards on the destination shards, disabling filtered replication. Useful for worker tests.

    • The following flags are also supported, but their use is very strongly discouraged:

    The following flags are also supported, but their use is very strongly discouraged: