VTOrc has a new flag --allow-emergency-reparent that allows the users to toggle the ability of VTOrc to run emergency
reparent operations. Users that want VTOrc to fix the replication issues, but don't want it to run any reparents
should start using this flag. By default, VTOrc will be able to run EmergencyReparentShard. Users must specify the
flag to false to change the behaviour.

VTOrc has a new flag --change-tablets-with-errant-gtid-to-drained that allows users to choose whether VTOrc should change the
tablet type of tablets with errant GTIDs to DRAINED. By default, it is disabled.

This feature allows users to configure VTOrc such that any tablet that encounters errant GTIDs is automatically taken out of the
serving graph. These tablets can then be inspected for what the errant GTIDs are, and once fixed, they can rejoin the cluster.

Running EmergencyReparentShard from the vtctldclient has a new sub-flag --wait-for-all-tablets that makes EmergencyReparentShard wait
for a response from all the tablets. Originally EmergencyReparentShard was meant only to be run when a primary tablet is unreachable.
We have realized now that there are cases when the replication is broken but all the tablets are reachable. In these cases, it is advisable to
call EmergencyReparentShard with --wait-for-all-tablets so that it does not ignore one of the tablets.

This flag enables transaction support on StreamExecute api.
Once enabled, VTGate StreamExecute gRPC api will send session as the last packet in the response.
The client should enable it only when they have made the required changes to expect such a packet.

It is disabled by default.

A new field foreignKeyMode has been added to the VSchema. This field can be provided for each keyspace. The VTGate flag --foreign_key_mode has been deprecated in favour of this field.

Building vtadmin-web now requires node >= v18.16.0 (LTS). Breaking changes from v16 to v18 are listed
in https://nodejs.org/en/blog/release/v18.0.0, but none apply to VTAdmin. Full details on v18.16.0 are listed
on https://nodejs.org/en/blog/release/v18.16.0.

Throttler related vttablet flags:

• --throttle_threshold is deprecated and will be removed in v19.0
• --throttle_metrics_query is deprecated and will be removed in v19.0
• --throttle_metrics_threshold is deprecated and will be removed in v19.0
• --throttle_check_as_check_self is deprecated and will be removed in v19.0
• --throttler-config-via-topo is deprecated after assumed true in v17.0. It will be removed in a future version.

Cache related vttablet flags:

• --queryserver-config-query-cache-lfu is deprecated and will be removed in v19.0. The query cache always uses a LFU implementation now.
• --queryserver-config-query-cache-size is deprecated and will be removed in v19.0. This option only applied to LRU caches, which are now unsupported.

Buffering related vtgate flags:

• --buffer_implementation is deprecated and will be removed in v19.0

Cache related vtgate flags:

• --gate_query_cache_lfu is deprecated and will be removed in v19.0. The query cache always uses a LFU implementation now.
• --gate_query_cache_size is deprecated and will be removed in v19.0. This option only applied to LRU caches, which are now unsupported.

VTGate flags:

The following EmergencyReparentShard stats are deprecated in v18.0 and will be removed in v19.0:
- ers_counter
- ers_success_counter
- ers_failure_counter

Flags in vtcombo:
- --vtctld_addr

Flags in vtctldclient ApplySchema:
- --skip-preflight

Flags in vtctl ApplySchema:
- --skip_preflight

Flags in vtgate:
- --vtctld_addr

Flags in vttablet:
- --vtctld_addr
- --use_super_read_only
- --disable-replication-manager
- --init_populate_metadata
- --queryserver-config-pool-prefill-parallelism
- --queryserver-config-stream-pool-prefill-parallelism
- --queryserver-config-transaction-pool-prefill-parallelism
- --queryserver-config-schema-change-signal-interval
- --enable-lag-throttler

Flags in vtctld:
- --vtctld_show_topology_crud
- --durability_policy

Flags in vtorc:
- --lock-shard-timeout
- --orc_web_dir

The Gen4 planner has been the default planner since Vitess 14. The v3 planner was deprecated in Vitess 15 and has now been removed in this release.

The k8stopo has been deprecated in Vitess 17, also see https://github.com/vitessio/vitess/issues/13298. With Vitess 18
the k8stopo has been removed.

The vtgr has been deprecated in Vitess 17, also see https://github.com/vitessio/vitess/issues/13300. With Vitess 18 vtgr has been removed.

The undocumented query_analyzer binary has been removed in Vitess 18, see https://github.com/vitessio/vitess/issues/14054.

The VTGate stat VindexUnknownParameters gauges unknown Vindex parameters found in the latest VSchema pulled from the topology.

In v17, the vtbackup stat DurationByPhase stat was added measuring the time spent by vtbackup in each phase. This stat turned out to be awkward to use in production, and has been replaced in v18 by a binary-valued Phase stat.

Phase reports a 1 (active) or a 0 (inactive) for each of the following phases:

• CatchupReplication
• InitialBackup
• RestoreLastBackup
• TakeNewBackup

To calculate how long vtbackup has spent in a given phase, sum the 1-valued data points over time and multiply by the data collection or reporting interval. For example, in Prometheus:

sum_over_time(vtbackup_phase{phase="TakeNewBackup"}) * <interval>

PhaseStatus reports a 1 (active) or a 0 (inactive) for each of the following phases and statuses:

• CatchupReplication phase has statuses Stalled and Stopped.
  • Stalled is set to 1 when replication stops advancing.
  • Stopped is set to 1 when replication stops before vtbackup catches up with the primary.

Requests to AWS S3 are instrumented in backup and restore metrics. For example:

vtbackup_backup_count{component="BackupStorage",implementation="S3",operation="AWS:Request:Send"} 823
vtbackup_backup_duration_nanoseconds{component="BackupStorage",implementation="S3",operation="AWS:Request:Send"} 1.33632421437e+11
vtbackup_restore_count{component="BackupStorage",implementation="S3",operation="AWS:Request:Send"} 165
vtbackup_restore_count{component="BackupStorage",implementation="S3",operation="AWS:Request:Send"} 165

New VTCtld and VTorc stats were added to measure frequency of reparents by keyspace/shard:
- emergency_reparent_counts - Number of times EmergencyReparentShard has been run. It is further subdivided by the keyspace, shard and the result of the operation.
- planned_reparent_counts - Number of times PlannedReparentShard has been run. It is further subdivided by the keyspace, shard and the result of the operation.

Also, the reparent_shard_operation_timings stat was added to provide per-operation timings of reparent operations.

A new VTTablet RPC ResetSequences has been added, which is being used by MoveTables and Migrate for workflows
where a sequence table is being moved (https://github.com/vitessio/vitess/pull/13238). This has an impact on the
Vitess upgrade process from an earlier version if you need to use such a workflow before the entire cluster is upgraded.

Any MoveTables or Migrate workflow that moves a sequence table should only be run after all vitess components have been
upgraded, and no upgrade should be done while such a workflow is in progress.

A new CLI flag --tx-throttler-dry-run to set the Transaction Throttler to monitoring-only/dry-run mode has been added.
If the transaction throttler is enabled with --enable-tx-throttler and the new dry-run flag is also specified, the
tablet will not actually throttle any transactions; however, it will increase the counters for transactions throttled
(vttablet_transaction_throttler_throttled). This allows users to deploy the transaction throttler in production and
gain observability on how much throttling would take place, without actually throttling any requests.

Bookworm was released on 2023-06-10, and will be the new default base container for Docker builds.
Bullseye images will still be built and available as long as the OS build is current, tagged with the -bullseye suffix.

Buster LTS supports will stop in June 2024, and Vitess v18.0 will be supported through October 2024.
To prevent supporting a deprecated buster build for several months after June 2024, we are preemptively
removing Vitess support.

2 new inbuilt durability policies have been added to Vitess in this release namely semi_sync_with_rdonly_ack and cross_cell_with_rdonly_ack. These policies are exactly like semi_sync and cross_cell respectively, and differ just in the part where the rdonly tablets can also send semi-sync ACKs.