Style guide fixitday

Author: Amruta-Ranade

v2.1/cluster-setup-troubleshooting.md

@@ -119,11 +119,11 @@ Proceed through the following steps until you locate the source of the issue wit
 
 **Next step**: If you successfully completed these steps, try [securing your deployment](manual-deployment.html) (*troubleshooting docs for this coming soon*) or reviewing our other [support resources](support-resources.html).
 
-## Troubleshooting Information
+## Troubleshooting information
 
 Use the information below to resolve issues you encounter when trying to start or scale your cluster.
 
-### Networking Troubleshooting
+### Networking troubleshooting
 
 Most networking-related issues are caused by one of two issues:
 
@@ -145,7 +145,7 @@ However, to efficiently troubleshoot the issue, it's important to understand whe
 
 Again, firewalls or hostname issues can cause any of these steps to fail.
 
-### Node Won't Join Cluster
+### Node won't join cluster
 
 When joining a node to a cluster, you might receive one of the following errors:
 
@@ -183,7 +183,7 @@ node belongs to cluster {"cluster hash"} but is attempting to connect to a gossi
 
 **Explanation**: When starting a node, the directory you choose to store the data in also contains metadata identifying the cluster the data came from. This causes conflicts when you've already started a node on the server, have quit `cockroach`, and then tried to join another cluster. Because the existing directory's cluster ID doesn't match the new cluster ID, the node cannot join it.
 
-### Replication Error in a Multi-Node Cluster
+### Replication error in a multi-node cluster
 
 If data is not being replicated to some nodes in the cluster, we recommend checking out the following:
 

v2.1/collate.md

@@ -31,6 +31,7 @@ Collated strings are used as normal strings in SQL, but have a `COLLATE` clause
 
 - **Column syntax**: `STRING COLLATE <collation>`. For example:
 
+    {% include copy-clipboard.html %}
     ~~~ sql
     > CREATE TABLE foo (a STRING COLLATE en PRIMARY KEY);
     ~~~
@@ -39,6 +40,7 @@ Collated strings are used as normal strings in SQL, but have a `COLLATE` clause
 
 - **Value syntax**: `<STRING value> COLLATE <collation>`. For example:
 
+    {% include copy-clipboard.html %}
     ~~~ sql
     > INSERT INTO foo VALUES ('dog' COLLATE en);
     ~~~
@@ -51,18 +53,21 @@ You can set a default collation for all values in a `STRING` column.
 
 For example, you can set a column's default collation to German (`de`):
 
+{% include copy-clipboard.html %}
 ~~~ sql
 > CREATE TABLE de_names (name STRING COLLATE de PRIMARY KEY);
 ~~~
 
 When inserting values into this column, you must specify the collation for every value:
 
+{% include copy-clipboard.html %}
 ~~~ sql
 > INSERT INTO de_names VALUES ('Backhaus' COLLATE de), ('Bär' COLLATE de), ('Baz' COLLATE de);
 ~~~
 
 The sort will now honor the `de` collation that treats *ä* as *a* in alphabetic sorting:
 
+{% include copy-clipboard.html %}
 ~~~ sql
 > SELECT * FROM de_names ORDER BY name;
 ~~~
@@ -82,6 +87,7 @@ You can sort a column using a specific collation instead of its default.
 
 For example, you receive different results if you order results by German (`de`) and Swedish (`sv`) collations:
 
+{% include copy-clipboard.html %}
 ~~~ sql
 > SELECT * FROM de_names ORDER BY name COLLATE sv;
 ~~~
@@ -99,6 +105,7 @@ For example, you receive different results if you order results by German (`de`)
 
 You can cast any string into a collation on the fly.
 
+{% include copy-clipboard.html %}
 ~~~ sql
 > SELECT 'A' COLLATE de < 'Ä' COLLATE de;
 ~~~
@@ -108,6 +115,7 @@ true
 
 However, you cannot compare values with different collations:
 
+{% include copy-clipboard.html %}
 ~~~ sql
 SELECT 'Ä' COLLATE sv < 'Ä' COLLATE de;
 ~~~
@@ -117,6 +125,7 @@ pq: unsupported comparison operator: <collatedstring{sv}> < <collatedstring{de}>
 
 You can also use casting to remove collations from values.
 
+{% include copy-clipboard.html %}
 ~~~ sql
 > SELECT CAST(name AS STRING) FROM de_names ORDER BY name;
 ~~~

v2.1/column-families.md

@@ -24,6 +24,7 @@ To manually assign a column family on [table creation](create-table.html), use t
 
 For example, let's say we want to create a table to store an immutable blob of data (`data BYTES`) with a last accessed timestamp (`last_accessed TIMESTAMP`). Because we know that the blob of data will never get updated, we use the `FAMILY` keyword to break it into a separate column family:
 
+{% include copy-clipboard.html %}
 ~~~ sql
 > CREATE TABLE test (
     id INT PRIMARY KEY,
@@ -32,7 +33,10 @@ For example, let's say we want to create a table to store an immutable blob of d
     FAMILY f1 (id, last_accessed),
     FAMILY f2 (data)
 );
+~~~
 
+{% include copy-clipboard.html %}
+~~~ sql
 > SHOW CREATE TABLE users;
 ~~~
 
@@ -60,18 +64,21 @@ When using the [`ALTER TABLE .. ADD COLUMN`](add-column.html) statement to add a
 
 - Use the `CREATE FAMILY` keyword to assign a new column to a **new family**. For example, the following would add a `data2 BYTES` column to the `test` table above and assign it to a new column family:
 
+  {% include copy-clipboard.html %}
   ~~~ sql
   > ALTER TABLE test ADD COLUMN data2 BYTES CREATE FAMILY f3;
   ~~~
 
 - Use the `FAMILY` keyword to assign a new column to an **existing family**. For example, the following would add a `name STRING` column to the `test` table above and assign it to family `f1`:
 
+  {% include copy-clipboard.html %}
   ~~~ sql
   > ALTER TABLE test ADD COLUMN name STRING FAMILY f1;
   ~~~
 
 - Use the `CREATE IF NOT EXISTS FAMILY` keyword to assign a new column to an **existing family or, if the family doesn't exist, to a new family**. For example, the following would assign the new column to the existing `f1` family; if that family didn't exist, it would create a new family and assign the column to it:
 
+  {% include copy-clipboard.html %}
   ~~~ sql
   > ALTER TABLE test ADD COLUMN name STRING CREATE IF NOT EXISTS FAMILY f1;
   ~~~

v2.1/commit-transaction.md

@@ -14,7 +14,7 @@ For non-retryable transactions, if statements in the transaction [generated any
 
 ## Synopsis
 
-{% include sql/{{ page.version.version }}/diagrams/commit_transaction.html %}
+<section> {% include sql/{{ page.version.version }}/diagrams/commit_transaction.html %} </section>
 
 ## Required privileges
 
@@ -34,6 +34,7 @@ How you commit transactions depends on how your application handles [transaction
 
 When using [client-side transaction retries](transactions.html#client-side-transaction-retries), statements are committed by [`RELEASE SAVEPOINT cockroach_restart`](release-savepoint.html). `COMMIT` itself only clears the connection for the next transaction.
 
+{% include copy-clipboard.html %}
 ~~~ sql
 > BEGIN;
 
@@ -54,6 +55,7 @@ When using [client-side transaction retries](transactions.html#client-side-trans
 
 If you are using transactions that CockroachDB will [automatically retry](transactions.html#automatic-retries) (i.e., all statements sent in a single batch), commit the transaction with `COMMIT`.
 
+{% include copy-clipboard.html %}
 ~~~ sql
 > BEGIN; UPDATE products SET inventory = 100 WHERE = '8675309'; UPDATE products SET inventory = 100 WHERE = '8675310'; COMMIT;
 ~~~

v2.1/common-errors.md

@@ -185,7 +185,7 @@ decide whether to retry or not based on whether it would be better for
 your application to apply the transaction twice or return an error to
 the user.
 
-## Something Else?
+## Something else?
 
 If we do not have a solution here, you can try using our other [support resources](support-resources.html), including:
 

v2.1/configure-replication-zones.md

@@ -355,7 +355,7 @@ Zone Name | Description
 ----------|-----------------|------------
 `.meta` | The "meta" ranges contain the authoritative information about the location of all data in the cluster.<br><br>Because historical queries are never run on meta ranges and it is advantageous to keep these ranges smaller for reliable performance, CockroachDB comes with a **pre-configured** `.meta` replication zone giving these ranges a lower-than-default `ttlseconds`.<br><br>If your cluster is running in multiple datacenters, it's a best practice to configure the meta ranges to have a copy in each datacenter.
 `.liveness` | The "liveness" range contains the authoritative information about which nodes are live at any given time.<br><br>Just as for "meta" ranges, historical queries are never run on the liveness range, so CockroachDB comes with a **pre-configured** `.liveness` replication zone giving this range a lower-than-default `ttlseconds`.<br><br>If this range is unavailable, the entire cluster will be unavailable, so giving it a high replication factor is strongly recommended.
-`.timeseries` | The "timeseries" ranges contain monitoring data about the cluster that powers the graphs in CockroachDB's admin UI. If necessary, you can add a `.timeseries` replication zone to control the replication of this data.
+`.timeseries` | The "timeseries" ranges contain monitoring data about the cluster that powers the graphs in CockroachDB's Admin UI. If necessary, you can add a `.timeseries` replication zone to control the replication of this data.
 `.system` | There are system ranges for a variety of other important internal data, including information needed to allocate new table IDs and track the status of a cluster's nodes. If necessary, you can add a `.system` replication zone to control the replication of this data.
 
 To control replication for one of the above sets of system ranges, create a YAML file defining only the values you want to change (other values will not be affected), and use the `cockroach zone set <zone-name> -f <file.yaml>` command with appropriate flags:

v2.1/constraints.md

@@ -29,26 +29,30 @@ How you add constraints depends on the number of columns you want to constrain,
 
 - **One column of a new table** has its constraints defined after the column's data type. For example, this statement applies the Primary Key constraint to `foo.a`:
 
-    ``` sql
+    {% include copy-clipboard.html %}
+    ~~~ sql
     > CREATE TABLE foo (a INT PRIMARY KEY);
-    ```
+    ~~~
 - **Multiple columns of a new table** have their constraints defined after the table's columns. For example, this statement applies the Primary Key constraint to `foo`'s columns `a` and `b`:
 
-    ``` sql
+    {% include copy-clipboard.html %}
+    ~~~ sql
     > CREATE TABLE bar (a INT, b INT, PRIMARY KEY (a,b));
-    ```
+    ~~~
 
   {{site.data.alerts.callout_info}}The Default Value and Not Null constraints cannot be applied to multiple columns.{{site.data.alerts.end}}
 
 - **Existing tables** can have the following constraints added:
   - **Check**, **Foreign Key**, and **Unique** constraints can be added through [`ALTER TABLE...ADD CONSTRAINT`](add-constraint.html). For example, this statement adds the Unique constraint to `baz.id`:
 
+    {% include copy-clipboard.html %}
     ~~~ sql
     > ALTER TABLE baz ADD CONSTRAINT id_unique UNIQUE (id);
     ~~~
 
   - **Default Values** can be added through [`ALTER TABLE...ALTER COLUMN`](alter-column.html#set-or-change-a-default-value). For example, this statement adds the Default Value constraint to `baz.bool`:
 
+    {% include copy-clipboard.html %}
     ~~~ sql
     > ALTER TABLE baz ALTER COLUMN bool SET DEFAULT true;
     ~~~
@@ -63,11 +67,15 @@ The order in which you list constraints is not important because constraints are
 
 You can name constraints applied to new tables using the `CONSTRAINT` clause before defining the constraint:
 
-``` sql
+{% include copy-clipboard.html %}
+~~~ sql
 > CREATE TABLE foo (a INT CONSTRAINT another_name PRIMARY KEY);
+~~~
 
+{% include copy-clipboard.html %}
+~~~ sql
 > CREATE TABLE bar (a INT, b INT, CONSTRAINT yet_another_name PRIMARY KEY (a,b));
-```
+~~~
 
 ### View constraints
 

v2.1/create-index.md

@@ -54,6 +54,7 @@ To create the most efficient indexes, we recommend reviewing:
 
 Single-column indexes sort the values of a single column.
 
+{% include copy-clipboard.html %}
 ~~~ sql
 > CREATE INDEX ON products (price);
 ~~~
@@ -64,6 +65,7 @@ Because each query can only use one index, single-column indexes are not typical
 
 Multiple-column indexes sort columns in the order you list them.
 
+{% include copy-clipboard.html %}
 ~~~ sql
 > CREATE INDEX ON products (price, stock);
 ~~~
@@ -74,12 +76,14 @@ To create the most useful multiple-column indexes, we recommend reviewing our [b
 
 Unique indexes do not allow duplicate values among their columns.
 
+{% include copy-clipboard.html %}
 ~~~ sql
 > CREATE UNIQUE INDEX ON products (name, manufacturer_id);
 ~~~
 
 This also applies the [Unique constraint](unique.html) at the table level, similarly to [`ALTER TABLE`](alter-table.html). The above example is equivalent to:
 
+{% include copy-clipboard.html %}
 ~~~ sql
 > ALTER TABLE products ADD CONSTRAINT products_name_manufacturer_id_key UNIQUE (name, manufacturer_id);
 ~~~
@@ -88,12 +92,14 @@ This also applies the [Unique constraint](unique.html) at the table level, simil
 
 [Inverted indexes](inverted-indexes.html) can be created on schemaless data in a [`JSONB`](jsonb.html) column.
 
+{% include copy-clipboard.html %}
 ~~~ sql
 > CREATE INVERTED INDEX ON users (profile);
 ~~~
 
 The above example is equivalent to the following PostgreSQL-compatible syntax:
 
+{% include copy-clipboard.html %}
 ~~~ sql
 > CREATE INDEX ON users USING GIN (profile);
 ~~~
@@ -102,6 +108,7 @@ The above example is equivalent to the following PostgreSQL-compatible syntax:
 
 Storing a column improves the performance of queries that retrieve (but don’t filter) its values.
 
+{% include copy-clipboard.html %}
 ~~~ sql
 > CREATE INDEX ON products (price) STORING (name);
 ~~~
@@ -112,6 +119,7 @@ However, to use stored columns, queries must filter another column in the same i
 
 To sort columns in descending order, you must explicitly set the option when creating the index. (Ascending order is the default.)
 
+{% include copy-clipboard.html %}
 ~~~ sql
 > CREATE INDEX ON products (price DESC, stock);
 ~~~
@@ -122,6 +130,7 @@ How columns are sorted impacts the order of rows returned by queries using the i
 
 Normally, CockroachDB selects the index that it calculates will scan the fewest rows. However, you can override that selection and specify the name of the index you want to use. To find the name, use [`SHOW INDEX`](show-index.html).
 
+{% include copy-clipboard.html %}
 ~~~ sql
 > SHOW INDEX FROM products;
 ~~~
@@ -135,6 +144,8 @@ Normally, CockroachDB selects the index that it calculates will scan the fewest
 +----------+--------------------+--------+-----+--------+-----------+---------+----------+
 (3 rows)
 ~~~
+
+{% include copy-clipboard.html %}
 ~~~ sql
 > SELECT name FROM products@products_price_idx WHERE price > 10;
 ~~~

v2.1/create-security-certificates.md

@@ -43,7 +43,7 @@ File name pattern | File usage
 `ca.crt`     | CA certificate
 `node.crt`   | Server certificate
 `node.key`   | Key for server certificate
-`client.<user>.crt` | Client certificate for `<user>` (eg: `client.root.crt` for user `root`)
+`client.<user>.crt` | Client certificate for `<user>` (for example: `client.root.crt` for user `root`)
 `client.<user>.key` | Key for the client certificate
 
 Note the following: