Replace urls in repo pointing to master branch to main

Signed-off-by: Rohit Nayak <rohit@planetscale.com>

GOVERNANCE.md

@@ -59,7 +59,7 @@ New committers can be nominated by any existing committer. Once they have been n
 
 Nominees may decline their appointment as a committer. However, this is unusual, as the project does not expect any specific time or resource commitment from its community members. The intention behind the role of committer is to allow people to contribute to the project more easily, not to tie them in to the project in any formal way.
 
-It is important to recognise that commitership is a privilege, not a right. That privilege must be earned and once earned it can be removed by the PMC for conduct inconsistent with the [Guiding Principles](https://github.com/vitessio/vitess/blob/master/GUIDING_PRINCIPLES.md) or if they drop below a level of commitment and engagement required to be a Committer, as determined by the PMC. The PMC also reserves the right to remove a person for any other reason inconsistent with the goals of Vitess.
+It is important to recognise that commitership is a privilege, not a right. That privilege must be earned and once earned it can be removed by the PMC for conduct inconsistent with the [Guiding Principles](https://github.com/vitessio/vitess/blob/main/GUIDING_PRINCIPLES.md) or if they drop below a level of commitment and engagement required to be a Committer, as determined by the PMC. The PMC also reserves the right to remove a person for any other reason inconsistent with the goals of Vitess.
 
 A committer who shows an above-average level of contribution to the project, particularly with respect to its strategic direction and long-term health, may be nominated to become a member of the PMC. This role is described below.
 
@@ -83,7 +83,7 @@ Membership of the PMC is by invitation from the existing PMC members. A nominati
 
 The number of PMC members should be limited to 7. This number is chosen to ensure that sufficient points of view are represented, while preserving the efficiency of the decision making process.
 
-The PMC is responsible for maintaining the [Guiding Principles](https://github.com/vitessio/vitess/blob/master/GUIDING_PRINCIPLES.md) and the code of conduct. It is also responsible for ensuring that those rules and principles are followed.
+The PMC is responsible for maintaining the [Guiding Principles](https://github.com/vitessio/vitess/blob/main/GUIDING_PRINCIPLES.md) and the code of conduct. It is also responsible for ensuring that those rules and principles are followed.
 
 ## PMC Chair
 
@@ -106,7 +106,7 @@ The Slack channel list is the most appropriate place for a contributor to ask fo
 
 Decisions about the future of the project are made by the PMC. New proposals and ideas can be brought to the PMC’s attention through the Slack channel or by filing an issue. If necessary, the PMC will seek input from others to come to the final decision.
 
-The PMC’s decision is itself governed by the project’s [Guiding Principles](https://github.com/vitessio/vitess/blob/master/GUIDING_PRINCIPLES.md), which shall be used to reach consensus. If a consensus cannot be reached, a simple majority voting process will be used to reach resolution. In case of a tie, the PMC chair has the casting vote.
+The PMC’s decision is itself governed by the project’s [Guiding Principles](https://github.com/vitessio/vitess/blob/main/GUIDING_PRINCIPLES.md), which shall be used to reach consensus. If a consensus cannot be reached, a simple majority voting process will be used to reach resolution. In case of a tie, the PMC chair has the casting vote.
 
 # Credits
 The contents of this document are based on http://oss-watch.ac.uk/resources/meritocraticgovernancemodel by Ross Gardler and Gabriel Hanganu.

GUIDING_PRINCIPLES.md

@@ -24,4 +24,4 @@ Vitess is driven by high technical standards, and these must be maintained. It i
 * Diversity
 * Inclusiveness
 * Openness
-* Adherence to the [Code of Conduct](https://github.com/vitessio/vitess/blob/master/CODE_OF_CONDUCT.md)
+* Adherence to the [Code of Conduct](https://github.com/vitessio/vitess/blob/main/CODE_OF_CONDUCT.md)

README.md

@@ -22,10 +22,10 @@ since 2011, and has grown to encompass tens of thousands of MySQL nodes.
 For more about Vitess, please visit [vitess.io](https://vitess.io).
 
 Vitess has a growing community. You can view the list of adopters
-[here](https://github.com/vitessio/vitess/blob/master/ADOPTERS.md).
+[here](https://github.com/vitessio/vitess/blob/main/ADOPTERS.md).
 
 ## Reporting a Problem, Issue, or Bug
-To report a problem, the best way to get attention is to create a GitHub [issue](.https://github.com/vitessio/vitess/issues ) using proper severity level based on this [guide](https://github.com/vitessio/vitess/blob/master/SEVERITY.md). 
+To report a problem, the best way to get attention is to create a GitHub [issue](.https://github.com/vitessio/vitess/issues ) using proper severity level based on this [guide](https://github.com/vitessio/vitess/blob/main/SEVERITY.md). 
 
 For topics that are better discussed live, please join the [Vitess Slack](https://vitess.io/slack) workspace.
 You may post any questions on the #general channel or join some of the special-interest channels.

SECURITY.md

@@ -33,11 +33,11 @@ score >= 4; see below). If the fix relies on another upstream project's disclosu
 will adjust the process as well. We will work with the upstream project to fit their timeline and
 best protect our users.
 
-#### Policy for master-only vulnerabilities
+#### Policy for main-only vulnerabilities
 
-If a security vulnerability affects master, but not a currently supported branch, then the following process will apply:
+If a security vulnerability affects main, but not a currently supported branch, then the following process will apply:
 
-* The fix will land in master.
+* The fix will land in main.
 * A courtesy notice will be posted in #developers on Vitess Slack.
 
 #### Policy for unsupported releases

doc/DockerBuild.md

@@ -1,10 +1,10 @@
-By default, the [Helm Charts](https://github.com/vitessio/vitess/tree/master/helm)
+By default, the [Helm Charts](https://github.com/vitessio/vitess/tree/main/helm)
 point to the `vitess/lite` image on [Docker Hub](https://hub.docker.com/u/vitess/).
 
 We created the `lite` image as a stripped down version of our main image `base` such that Kubernetes pods can start faster.
 The `lite` image does not change very often and is updated manually by the Vitess team with every release.
 In contrast, the `base` image is updated automatically after every push to the GitHub master branch.
-For more information on the different images we provide, please read the [`docker/README.md`](https://github.com/vitessio/vitess/tree/master/docker) file.
+For more information on the different images we provide, please read the [`docker/README.md`](https://github.com/vitessio/vitess/tree/main/docker) file.
 
 If your goal is run the latest Vitess code, the simplest solution is to use the bigger `base` image instead of `lite`.
 
@@ -22,9 +22,9 @@ Then you can run our build script for the `lite` image which extracts the Vitess
 
 1.  Go to your `src/vitess.io/vitess` directory.
 
-1.  Usually, you won't need to [build your own bootstrap image](https://github.com/vitessio/vitess/blob/master/docker/bootstrap/README.md)
-    unless you edit [bootstrap.sh](https://github.com/vitessio/vitess/blob/master/bootstrap.sh)
-    or [vendor.json](https://github.com/vitessio/vitess/blob/master/vendor/vendor.json),
+1.  Usually, you won't need to [build your own bootstrap image](https://github.com/vitessio/vitess/blob/main/docker/bootstrap/README.md)
+    unless you edit [bootstrap.sh](https://github.com/vitessio/vitess/blob/main/bootstrap.sh)
+    or [vendor.json](https://github.com/vitessio/vitess/blob/main/vendor/vendor.json),
     for example to add new dependencies. If you do need it then build the
     bootstrap image, otherwise pull the image using one of the following
     commands depending on the MySQL flavor you want:

doc/LifeOfAQuery.md

@@ -11,7 +11,7 @@ Life of A Query
 
 A query means a request for information from database and it involves four components in the case of Vitess, including the client application, VtGate, VtTablet and MySQL instance. This doc explains the interaction which happens between and within components.
 
-![](https://raw.githubusercontent.com/vitessio/vitess/master/doc/life_of_a_query.png)
+![](https://raw.githubusercontent.com/vitessio/vitess/main/doc/life_of_a_query.png)
 
 At a very high level, as the graph shows, first the client sends a query to VtGate. VtGate then resolves the query and routes it to the right VtTablets. For each VtTablet that receives the query, it does necessary validations and passes the query to the underlying MySQL instance. After gathering results from MySQL, VtTablet sends the response back to VtGate. Once VtGate receives responses from all VtTablets, it sends the combined result to the client. In the presence of VtTablet errors, VtGate will retry the query if errors are recoverable and it only fails the query if either errors are unrecoverable or the maximum number of retries has been reached.
 
@@ -19,13 +19,13 @@ At a very high level, as the graph shows, first the client sends a query to VtGa
 
 A client application first sends an rpc with an embedded sql query to VtGate. VtGate's rpc server unmarshals this rpc request, calls the appropriate VtGate method and return its result back to client.
 
-![](https://raw.githubusercontent.com/vitessio/vitess/master/doc/life_of_a_query_client_to_vtgate.png)
+![](https://raw.githubusercontent.com/vitessio/vitess/main/doc/life_of_a_query_client_to_vtgate.png)
 
 VtGate keeps an in-memory table that stores all available rpc methods for each service, e.g. VtGate uses "VTGate" as its service name and most of its methods defined in [go/vt/vtgate/vtgate.go](../go/vt/vtgate/vtgate.go) are used to serve rpc request.
 
 ## From VtGate to VtTablet
 
-![](https://raw.githubusercontent.com/vitessio/vitess/master/doc/life_of_a_query_vtgate_to_vttablet.png)
+![](https://raw.githubusercontent.com/vitessio/vitess/main/doc/life_of_a_query_vtgate_to_vttablet.png)
 
 After receiving an rpc call from the client and one of its Execute* method being invoked, VtGate needs to figure out which shards should receive the query and send it to each of them. In addition, VtGate talks to the topo server to get necessary information to create a VtTablet connection for each shard. At this point, VtGate is able to send the query to the right VtTablets in parallel. VtGate also does retry if timeout happens or some VtTablets return recoverable errors.
 
@@ -35,13 +35,13 @@ A ShardConn object represents a load balanced connection to a group of VtTablets
 
 ## From VtTablet to MySQL
 
-![](https://raw.githubusercontent.com/vitessio/vitess/master/doc/life_of_a_query_vttablet_to_mysql.png)
+![](https://raw.githubusercontent.com/vitessio/vitess/main/doc/life_of_a_query_vttablet_to_mysql.png)
 
 Once VtTablet received an rpc call from VtGate, it does a few checks before passing the query to MySQL. First, it validates the current VtTablet state including the session id, then generates a query plan and applies predefined query rules and does ACL checks. It also checks whether the query hits the row cache and returns the result immediately if so. In addition, VtTablet consolidates duplicate queries from executing simultaneously and shares results between them. At this point, VtTablet has no way but pass the query down to MySQL layer and wait for the result.
 
 ## Putting it all together
 
-![](https://raw.githubusercontent.com/vitessio/vitess/master/doc/life_of_a_query_all.png)
+![](https://raw.githubusercontent.com/vitessio/vitess/main/doc/life_of_a_query_all.png)
 
 ## TopoServer
 

doc/ReplicatoinLagBasedThrottlingOfTransactions.md

@@ -21,11 +21,11 @@ A boolean flag controlling whether the replication-lag-based throttling is enabl
 
 * *tx-throttler-config*
 
-A text-format representation of the  [throttlerdata.Configuration](https://github.com/vitessio/vitess/blob/master/proto/throttlerdata.proto) protocol buffer 
+A text-format representation of the  [throttlerdata.Configuration](https://github.com/vitessio/vitess/blob/main/proto/throttlerdata.proto) protocol buffer 
 that contains configuration options for the throttler. 
 The most important fields in that message are *target_replication_lag_sec* and 
 *max_replication_lag_sec* that specify the desired limits on the replication lag. See the comments in the protocol definition file for more details.
-If this is not specified a [default](https://github.com/vitessio/vitess/tree/master/go/vt/vttablet/tabletserver/tabletenv/config.go) configuration will be used.
+If this is not specified a [default](https://github.com/vitessio/vitess/tree/main/go/vt/vttablet/tabletserver/tabletenv/config.go) configuration will be used.
 
 * *tx-throttler-healthcheck-cells*
 

doc/TwoPhaseCommitDesign.md

@@ -106,7 +106,7 @@ For #1 and #2, the Rollback workflow is initiated. For #3, the commit is resumed
 
 The following diagram illustrates the life-cycle of a Vitess transaction.
 
-![](https://raw.githubusercontent.com/vitessio/vitess/master/doc/TxLifecycle.png)
+![](https://raw.githubusercontent.com/vitessio/vitess/main/doc/TxLifecycle.png)
 
 A transaction generally starts off as a single DB transaction. It becomes a distributed transaction as soon as more than one VTTablet is affected. If the app issues a rollback, then all participants are simply rolled back. If a BEC is issued, then all transactions are individually committed. These actions are the same irrespective of single or distributed transactions.
 
@@ -132,7 +132,7 @@ In order to make 2PC work, the following pieces of functionality have to be buil
 
 The diagram below show how the various components interact.
 
-![](https://raw.githubusercontent.com/vitessio/vitess/master/doc/TxInteractions.png)
+![](https://raw.githubusercontent.com/vitessio/vitess/main/doc/TxInteractions.png)
 
 The detailed design explains all the functionalities and interactions.
 

doc/V3HighLevelDesign.md

@@ -6,7 +6,7 @@ The goal of this document is to describe the guiding principles that will be use
 
 ### Prerequisites
 
-Before reading this doc you must be familiar with [vindexes](https://github.com/vitessio/vitess/blob/master/doc/V3VindexDesign.md), which is used as foundation for the arguments presented here.
+Before reading this doc you must be familiar with [vindexes](https://github.com/vitessio/vitess/blob/main/doc/V3VindexDesign.md), which is used as foundation for the arguments presented here.
 
 # Background
 
@@ -1194,7 +1194,7 @@ The overall strategy is as follows:
 
 In order to align ourselves with our priorities, we’ll start off with a limited set of primitives, and then we can expand from there.
 
-VTGate already has `Route` and `RouteMerge` as primitives. To this list, let’s add `Join` and `LeftJoin`. Using these primitives, we should be able to cover priorities 1-3 (mentioned in the [Prioritization](https://github.com/vitessio/vitess/blob/master/doc/V3HighLevelDesign.md#prioritization) section). So, any constructs that will require VTGate to do additional work will not be supported. Here’s a recap of what each primitive must do:
+VTGate already has `Route` and `RouteMerge` as primitives. To this list, let’s add `Join` and `LeftJoin`. Using these primitives, we should be able to cover priorities 1-3 (mentioned in the [Prioritization](https://github.com/vitessio/vitess/blob/main/doc/V3HighLevelDesign.md#prioritization) section). So, any constructs that will require VTGate to do additional work will not be supported. Here’s a recap of what each primitive must do:
 
 * `Route`: Sends a query to a single shard or unsharded keyspace.
 * `RouteMerge`: Sends a (mostly) identical query to multiple shards and returns the combined results in no particular order.

doc/VTGateSubqueries.md

@@ -2,7 +2,7 @@
 
 # Introduction
 
-This document builds on top of [The V3 high level design](https://github.com/vitessio/vitess/blob/master/doc/V3HighLevelDesign.md). It discusses implementation of subquery support in greater detail.
+This document builds on top of [The V3 high level design](https://github.com/vitessio/vitess/blob/main/doc/V3HighLevelDesign.md). It discusses implementation of subquery support in greater detail.
 
 
 

doc/VTGateV3Features.md

@@ -34,7 +34,7 @@ there are some additional benefits:
   underneath without changing much of the app.
 
 The
-[V3 design](https://github.com/vitessio/vitess/blob/master/doc/V3VindexDesign.md)
+[V3 design](https://github.com/vitessio/vitess/blob/main/doc/V3VindexDesign.md)
 is quite elaborate. If necessary, it will allow you to plug in custom indexes
 and sharding schemes. However, it comes equipped with some pre-cooked recipes
 that satisfy the immediate needs of the real-world:

doc/VindexAsTable.md

@@ -10,7 +10,7 @@ One can think of a vindex as a table that looks like this:
 create my_vdx(id int, keyspace_id varbinary(255)) // id can be of any type.
 ```
 
-Looking at the vindex interface defined [here](https://github.com/vitessio/vitess/blob/master/go/vt/vtgate/vindexes/vindex.go), we can come up with SQL syntax that represents them:
+Looking at the vindex interface defined [here](https://github.com/vitessio/vitess/blob/main/go/vt/vtgate/vindexes/vindex.go), we can come up with SQL syntax that represents them:
 * Map: `select id, keyspace_id from my_vdx where id = :id`.
 * Create: `insert into my_vdx values(:id, :keyspace_id)`.
 * Delete: `delete from my_vdx where id = :id and keyspace_id :keyspace_id`.

doc/Vision.md

@@ -70,4 +70,4 @@ data is stored only once, and fetched only if needed.
 
 The following diagram illustrates where vitess fits in the spectrum of storage solutions:
 
-![Spectrum](https://raw.github.com/vitessio/vitess/master/doc/VitessSpectrum.png)
+![Spectrum](https://raw.github.com/vitessio/vitess/main/doc/VitessSpectrum.png)

doc/internal/ReleaseInstructions.md

@@ -13,7 +13,7 @@ backward-incompatible way -- for example, when removing deprecated interfaces.
 
 Our public API includes (but is not limited to):
 
-*   The VTGate [RPC interfaces](https://github.com/vitessio/vitess/tree/master/proto).
+*   The VTGate [RPC interfaces](https://github.com/vitessio/vitess/tree/main/proto).
 *   The interfaces exposed by the VTGate client library in each language.
 
 Care must also be taken when changing the format of any data stored by a live

doc/releasenotes/8_0_0_release_notes.md

@@ -107,7 +107,7 @@ If a scatter query is attempting to collect and process too many rows in memory
 
 
 ### Set Statement Support
-Set statement support is added in Vitess. There are [some system variables](https://github.com/vitessio/vitess/blob/master/go/vt/sysvars/sysvars.go#L147,L190) which are disabled by default and can be enabled using flag `-enable_system_settings` on VTGate.These system variables are set on the backing MySQL instance, and will force the connection to be dedicated instead of part of the connection pool.
+Set statement support is added in Vitess. There are [some system variables](https://github.com/vitessio/vitess/blob/main/go/vt/sysvars/sysvars.go#L147,L190) which are disabled by default and can be enabled using flag `-enable_system_settings` on VTGate.These system variables are set on the backing MySQL instance, and will force the connection to be dedicated instead of part of the connection pool.
 
 * Disabled passthrough system variables by default. #6859
 * Allow switching workload between OLAP and OLTP #4086 #6691

doc/releasenotes/9_0_0_release_notes.md

@@ -100,7 +100,7 @@ Vitess 9.0 is not compatible with the previous release of the Vitess Kubernetes
 
 ### Set Statement Support 
 
-Set statement support has been added in Vitess. There are [some system variables](https://github.com/vitessio/vitess/blob/master/go/vt/sysvars/sysvars.go#L147,L190) which are disabled by default and can be enabled using flag `-enable_system_settings` on VTGate. These system variables are set on the mysql server. Because they change the mysql session, using them leads to the Vitess connection no longer using the connection pool and forcing dedicated connections.
+Set statement support has been added in Vitess. There are [some system variables](https://github.com/vitessio/vitess/blob/main/go/vt/sysvars/sysvars.go#L147,L190) which are disabled by default and can be enabled using flag `-enable_system_settings` on VTGate. These system variables are set on the mysql server. Because they change the mysql session, using them leads to the Vitess connection no longer using the connection pool and forcing dedicated connections.
 
 
 ### VReplication

docker/README.md

@@ -13,25 +13,10 @@ The structure of this directory and our Dockerfile files is guided by the follow
 
 * The configuration of each Vitess image is in the directory `docker/<image>/`.
 * Configurations for other images e.g. our internal tool Keytar (see below), can be in a different location.
-* Images with more complex build steps have a `build.sh` script e.g. see [lite/build.sh](https://github.com/vitessio/vitess/blob/master/docker/lite/build.sh).
-* Tags are used to provide (stable) versions e.g. see tag `v2.0` for the image [vitess/lite](https://hub.docker.com/r/vitess/lite/tags).
-* Where applicable, we provide a `latest` tag to reference the latest build of an image.
-
-## Images
-
-Our list of images can be grouped into:
-
-* published Vitess code
-* dependencies for our Kubernetes tutorial
-* internally used tools
-
-### Vitess
-
-| Image | How (When) Updated | Description |
-| --- | --- | --- |
-| **bootstrap** | manual (after incompatible changes are made to [bootstrap.sh](https://github.com/vitessio/vitess/blob/master/bootstrap.sh) or [vendor/vendor.json](https://github.com/vitessio/vitess/blob/master/vendor/vendor.json) | Basis for all Vitess images. It is a snapshot of the checked out repository after running `./bootstrap.sh`. Used to cache dependencies. Avoids lengthy recompilation of dependencies if they did not change. Our internal test runner [`test.go`](https://github.com/vitessio/vitess/blob/master/test.go) uses it to test the code against different MySQL versions. |
-| **base** | automatic (after every GitHub push to the master branch) | Contains all Vitess server binaries. Snapshot after running `make build`. |
-| **root** | automatic (after every GitHub push to the master branch) | Same as **base** but with the default user set to "root". Required for Kubernetes. |
+* Images with more complex build steps have a `build.sh` script e.g. see [lite/build.sh](https://github.com/vitessio/vitess/blob/main/docker/lite/build.sh).
+* Tags are used to provide (stable) versions e.g. see tag `v2.0` for the image [vitess/lite](https://hub.docker.com/r/vitess/lite/tags).Vhttps://github.com/vitessio/vitess/blob/main/test.go) uses it to test the code against different MySQL versions. |
+| **base** | automatic (after every GitHub push to the main branch) | Contains all Vitess server binaries. Snapshot after running `make build`. |
+| **root** | automatic (after every GitHub push to the main branch) | Same as **base** but with the default user set to "root". Required for Kubernetes. |
 | **lite** | manual (updated with every Vitess release) | Stripped down version of **base** e.g. source code and build dependencies are removed. Default image in our Kubernetes templates for minimized startup time. |
 
 All these Vitess images include a specific MySQL/MariaDB version ("flavor").

docker/bootstrap/README.md

@@ -15,7 +15,7 @@ The `vitess/bootstrap` image comes in different flavors:
 **NOTE: Unlike the base image that builds Vitess itself, this bootstrap image
 will NOT be rebuilt automatically on every push to the Vitess master branch.**
 
-To build a new bootstrap image, use the [build.sh](https://github.com/vitessio/vitess/blob/master/docker/bootstrap/build.sh)
+To build a new bootstrap image, use the [build.sh](https://github.com/vitessio/vitess/blob/main/docker/bootstrap/build.sh)
 script.
 
 First build the `common` image, then any flavors you want. For example:

go/vt/vitessdriver/doc.go

@@ -38,7 +38,7 @@ Using this SQL driver is as simple as:
     // Use "db" via the Golang sql interface.
   }
 
-For a full example, please see: https://github.com/vitessio/vitess/blob/master/test/client.go
+For a full example, please see: https://github.com/vitessio/vitess/blob/main/test/client.go
 
 The full example is based on our tutorial for running Vitess locally: https://vitess.io/docs/get-started/local/
 
@@ -61,21 +61,21 @@ The driver uses the V3 API which doesn't require you to specify routing
 information. You just send the query as if Vitess was a regular database.
 VTGate analyzes the query and uses additional metadata called VSchema
 to perform the necessary routing. See the vtgate v3 Features doc for an overview:
-https://github.com/vitessio/vitess/blob/master/doc/VTGateV3Features.md
+https://github.com/vitessio/vitess/blob/main/doc/VTGateV3Features.md
 
 As of 12/2015, the VSchema creation is not documented yet as we are in the
 process of simplifying the VSchema definition and the overall process for
 creating one.
 If you want to create your own VSchema, we recommend to have a
 look at the VSchema from the vtgate v3 demo:
-https://github.com/vitessio/vitess/blob/master/examples/demo/schema
+https://github.com/vitessio/vitess/blob/main/examples/demo/schema
 
 (The demo itself is interactive and can be run by executing "./run.py" in the
 "examples/demo/" directory.)
 
 The vtgate v3 design doc, which we will also update and simplify in the future,
 contains more details on the VSchema:
-https://github.com/vitessio/vitess/blob/master/doc/V3VindexDesign.md
+https://github.com/vitessio/vitess/blob/main/doc/V3VindexDesign.md
 
 
 Isolation levels

helm/vitess/README.md

@@ -391,7 +391,7 @@ metadata:
 data:
   extra.cnf: |-
     early-plugin-load=keyring_vault=keyring_vault.so
-    # this includes default rpl plugins, see https://github.com/vitessio/vitess/blob/master/config/mycnf/master_mysql57.cnf for details
+    # this includes default rpl plugins, see https://github.com/vitessio/vitess/blob/main/config/mycnf/master_mysql57.cnf for details
     plugin-load=rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so;keyring_udf=keyring_udf.so
     keyring_vault_config=/vt/usersecrets/vttablet-vault/vault.conf # load keyring configuration from secret
     innodb_encrypt_tables=ON # encrypt all tables by default

java/README.md

@@ -5,7 +5,7 @@ This subdirectory contains all Vitess Java code.
 It is split in the following subdirectories (Maven modules):
 
 * **client:** Our Java client library.
-  * See [VTGateConn.java](https://github.com/vitessio/vitess/blob/master/java/client/src/main/java/io/vitess/client/VTGateConn.java) and [VTGateBlockingConn.java](https://github.com/vitessio/vitess/blob/master/java/client/src/main/java/io/vitess/client/VTGateBlockingConn.java) for the API.
+  * See [VTGateConn.java](https://github.com/vitessio/vitess/blob/main/java/client/src/main/java/io/vitess/client/VTGateConn.java) and [VTGateBlockingConn.java](https://github.com/vitessio/vitess/blob/main/java/client/src/main/java/io/vitess/client/VTGateBlockingConn.java) for the API.
   * Note: The library is agnostic of the underlying RPC system and only defines an interface for that.
   * In open-source, the library must always be used together with the code in `grpc-client`.
 * **grpc-client:** Implements the client's RPC interface for gRPC.

java/client/src/main/java/io/vitess/client/Proto.java

@@ -66,7 +66,7 @@ public class Proto {
    *
    * <p>
    * Errors returned by Vitess are documented in the
-   * <a href="https://github.com/vitessio/vitess/blob/master/proto/vtrpc.proto">vtrpc proto</a>.
+   * <a href="https://github.com/vitessio/vitess/blob/main/proto/vtrpc.proto">vtrpc proto</a>.
    */
   public static void checkError(RPCError error) throws SQLException {
     if (error != null) {

java/client/src/main/java/io/vitess/client/RpcClient.java

@@ -38,7 +38,7 @@ public interface RpcClient extends Closeable {
    * Sends a single query using the VTGate V3 API.
    *
    * <p>See the
-   * <a href="https://github.com/vitessio/vitess/blob/master/proto/vtgateservice.proto">proto</a>
+   * <a href="https://github.com/vitessio/vitess/blob/main/proto/vtgateservice.proto">proto</a>
    * definition for canonical documentation on this VTGate API.
    */
   ListenableFuture<ExecuteResponse> execute(Context ctx, ExecuteRequest request)
@@ -48,7 +48,7 @@ public interface RpcClient extends Closeable {
    * Sends a list of queries using the VTGate V3 API.
    *
    * <p>See the
-   * <a href="https://github.com/vitessio/vitess/blob/master/proto/vtgateservice.proto">proto</a>
+   * <a href="https://github.com/vitessio/vitess/blob/main/proto/vtgateservice.proto">proto</a>
    * definition for canonical documentation on this VTGate API.
    */
   ListenableFuture<Vtgate.ExecuteBatchResponse> executeBatch(Context ctx,
@@ -64,7 +64,7 @@ public interface RpcClient extends Closeable {
    * received from the server.
    *
    * <p>See the
-   * <a href="https://github.com/vitessio/vitess/blob/master/proto/vtgateservice.proto">proto</a>
+   * <a href="https://github.com/vitessio/vitess/blob/main/proto/vtgateservice.proto">proto</a>
    * definition for canonical documentation on this VTGate API.
    */
   StreamIterator<QueryResult> streamExecute(Context ctx, StreamExecuteRequest request)
@@ -76,7 +76,7 @@ public interface RpcClient extends Closeable {
    * Stream begins at the specified VGTID.
    *
    * <p>See the
-   * <a href="https://github.com/vitessio/vitess/blob/master/proto/vtgateservice.proto">proto</a>
+   * <a href="https://github.com/vitessio/vitess/blob/main/proto/vtgateservice.proto">proto</a>
    * definition for canonical documentation on this VTGate API.
    */
   StreamIterator<VStreamResponse> getVStream(

java/pom.xml

@@ -44,14 +44,14 @@
   <licenses>
     <license>
       <name>Apache Version 2.0</name>
-      <url>https://github.com/vitessio/vitess/blob/master/LICENSE</url>
+      <url>https://github.com/vitessio/vitess/blob/main/LICENSE</url>
       <distribution>manual</distribution>
     </license>
   </licenses>
   <scm>
     <connection>scm:git:git@github.com:vitessio/vitess.git</connection>
     <developerConnection>scm:git:git@github.com:vitessio/vitess.git</developerConnection>
-    <url>https://github.com/vitessio/vitess/tree/master</url>
+    <url>https://github.com/vitessio/vitess/tree/main</url>
   </scm>
   <issueManagement>
     <system>GitHub</system>