vitess.io/vitess@v0.16.2/doc/design-docs/SeparatingVttabletMysql.md (about)

     1  # Separating VTTablet and MySQL
     2  
     3  This document explores the setup where VTTablet and MySQL are not running on the
     4  same server, or in the same container. This is mostly useful when using a
     5  managed MySQL server (like CloudSQL or RDS).
     6  
     7  In this setup, Vitess is not responsible for any replication management or
     8  backups. Schema Swap is also not possible, as it relies on backups / restores.
     9  
    10  `Note`: this document is a work in progress, meant to centralize all findings on
    11  this subject. Eventually, we want to have an end to end test proving this setup
    12  works, probably on Kubernetes / GCE using CloudSQL.
    13  
    14  ## VTTablet Configuration
    15  
    16  The following adjustments need to be made to VTTablet command line parameters:
    17  
    18  * Do not specify `-mycnf-file`: instead, specify the `-mycnf_server_id`
    19    parameter.
    20  
    21  * Do not use `-mycnf_socket_file`. There is no local MySQL unix socket file.
    22  
    23  * Specify the host and port of the MySQL daemon for the `-db\_host`
    24    and `-db\_port` command line parameters. Do not specify
    25    `-db\_socket` parameters.
    26  
    27  * Disable restores / backups, by not passing any backup command line
    28    parameters. Specifically, `--restore_from_backup` and
    29    `-backup_storage_implementation` should not be set.
    30  
    31  Since cluster management and replication are not handled by Vitess, we just need
    32  to make sure the tablet type in the topology is correct before running
    33  vttablet. Usually, vttablet can be started with `-init_tablet_type replica`,
    34  even for a primary (as `primary/master` is not allowed), and it will discover 
    35  and set its type correctly to `primary`. When Vitess doesn't manage that at all, running
    36  `vtctl InitShardPrimary` is not possible, so there is no way to start as the
    37  primary just using vttablet. There are two solutions:
    38  
    39  * Preferred: Start the desired primary tablet with `-init_tablet_type replica`, 
    40    and then run a `vtctl TabletExternallyReparented <tablet alias>`.
    41  
    42  * Run `vtctl InitTablet ... <tablet alias>` with the desired primary tablet alias, 
    43    and then start vttablet with no `-init...` parameters. 
    44    Note: `InitTablet` has been deprecated so the first method is preferred.
    45    
    46  ## Other Configurations
    47  
    48  `vtctl` and `vtctld` can be run with the `-disable_active_reparents` flag. This
    49  would make all explicit reparent commands unreachable (like `InitShardPrimary`
    50  or `PlannedReparentShard`).
    51  
    52  `vtgate` and `vtworker` don't need any special configuration.
    53  
    54  ## Runtime Differences
    55  
    56  There are some subtle differences when connecting to MySQL using TCP, as opposed
    57  to connecting using a Unix socket. The main one is that when the server closes
    58  the connection, the client knows it when writing on a unix socket, but only
    59  realizes it when reading the response from a TCP socket. So using TCP, it is
    60  harder to distinguish a query that was killed from a query that was sent on a
    61  closed connection. It matters because we don't want to retry a query that was
    62  killed, but we want to retry a query sent on a closed connection.
    63  
    64  If this becomes an issue, we can find ways around it.
    65  
    66  ## Resharding
    67  
    68  Given that Vitess doesn't control cluster management or replication, is
    69  resharding still possible? The following features are necessary:
    70  
    71  * being able to start / stop replication on a slave. So we can keep a slave in a
    72    specific state while we copy or compare data.
    73  
    74  * have access to the current replication position, as MariaDB GTID or MySQL 5.6
    75    GTIDSet.
    76  
    77  * be able to connect as a replica to the primary MySQL, and start from an
    78    arbitrary past GTID, to support filtered replication.
    79  
    80  `Note`: in some setups, the primary for a shard is never moved around, and is
    81  made durable by a persistent drive. It would be possible in that case to have an
    82  alternative implementation of the Vitess GTID code using a filename / file
    83  position. Filtered replication would always need to connect to the primary of the
    84  source shard then. Let us know if you are in that situation, it is not a lot of
    85  work to implement.