​
Install

Run the following command to install the connector from the root of your project:

npm install --save @latitude-data/mysql-connector

​
How to configure sources

The sources files must be inside the queries/ folder.

To know how the source hierarchy works, please, visit How to configure sources.

​
Configuration

To configure the connection with your MySQL database follow these steps:

1

Create the source `.yaml` file within the `queries` folder if you haven't already

/queries/source.yml

2

Add the following code for your MySQL connection

type: mysql
details:
  host: string
  user: string
  port: string
  password: string
  database: string
  ssl: boolean | 'Amazon RDS' | SSLConfig
3

Replace the details section with your info and save

4

Done, now you can test your connection

​
Attributes

  • Host → The address of the server where your MySQL database lives. It could be a straightforward IP address like 192.168.1.1 or a domain name such as database.example.com. Think of it as the location where your database is hosted.
  • Port → The port of the server where your MySQL database lives. Defaults to 3306.
  • User → The username you use to log into your MySQL database. It’s like your personal key that identifies you to the MySQL server, allowing you access to perform operations within the database.
  • Password → The password goes hand-in-hand with your username. It’s the secret code that proves your identity to the MySQL server, ensuring that only authorized users can access the database.
  • Database → The name of the specific MySQL database you want to get data from.
  • Ssl -> (Optional) There are 3 options to configure SSL:
    • A true boolean for the default SSL strategy. This should work most of the times
    • An ‘Amazon RDS’ string to indicate a default profile included with the connector to connect to Amazon RDS instances
    • An SSLConfig object

​
SslConfig

  • Ca -> (Optional) Path to the certificate authority(ies) to trust instead of the ones Node.js is configured to trust. This can either be the root CA of your OS or a CA you obtained from your DB provider.
  • Key -> (Optional) Path to the private keys in PEM format.
  • Cert -> (Optional) Path to the cert chains in PEM format.
  • RejectUnauthorized -> (Optional) True or false if the connector should validate the SSL certificate

​
Certificate Authorities (CAs)

Most of the following documentation comes from Planetscale’s excellent docs. We copied and adapted some of their content here in the interest of simplicity for you, the reader, but it would be remiss not to mention their excellent work.

​
What is a Certificate Authority (CA)?

A Certificate Authority (CA) is a trusted party that signs digital certificates used to identify websites and other services. Their most well known use is signing the certificates used by websites serving content over HTTPS. Using a signed certificate means that you can trust that you really are communicating with the website that you think you are, without someone else listening in.

​
Why is a Certificate Authority (CA) needed for TLS / SSL?

Encryption alone won’t provide trust, only confidentiality. Without a way to verify the entity at the other end of a secure connection, you risk establishing an encrypted connection to a malicious party. This means that TLS / SSL only provides real security when certificates are validated against specific trusted Certificate Authorities.

​
What is a CA root store?

In day-to-day browsing you don’t need to specify which CAs to trust, your operating system and / or browser come with a list of trusted authorities. These trusted authorities verify the identities of domain owners creating HTTPS certificates, and sign those certificates so that you can trust them as well. The root store of certificates from Certificate Authorities is a collection of certificates that are trusted to sign other certificates.

Operating systems all come with CA root stores. Below we have listed common paths on which the CA root store can be found in various operating systems and distributions.

​
CA root configuration

Linux On Linux, the path to the system CA roots depends on the distribution that you are using.

Debian / Ubuntu / Gentoo / Arch / Slackware This path also applies to Debian or Ubuntu derivatives. You need to make sure the ca-certificates package is installed.

/etc/ssl/certs/ca-certificates.crt

RedHat / Fedora / CentOS / Mageia / Vercel / Netlify This path also applies to RedHat or Fedora derivatives like Amazon Linux and Oracle Linux. This is the path to use for applications deployed on Vercel and Netlify.

/etc/pki/tls/certs/ca-bundle.crt

Alpine This is a commonly used distribution for Docker containers.

/etc/ssl/cert.pem

OpenSUSE This also applies to OpenSUSE derivatives.

/etc/ssl/ca-bundle.pem

MacOS / FreeBSD / OpenBSD MacOS provides an extracted version of the system roots on disk that can be used for the CA roots. On FreeBSD you need to install the ca_root_nss package for this path to be available.

/etc/ssl/cert.pem

Windows Windows does not provide a file with the CA roots. You’ll need to obtain CAs either from your DB provider or others. The curl project provides an extracted bundle of root certificates from the Mozilla CA Certificate program. You can download the bundle at https://curl.se/docs/caextract.html. Once you download the file, you can point at it from the connectors’ configuration.

​
Test connection

To test the connection you can:

  1. Create a query .sql in the queries directory that points to a table of your new connection in the FROM clause. See the section SQL Syntax Basics to learn more.
  2. Use the command line to run latitude run query_file_name where query_file_name is the name of your .sql file. This will display the results in your terminal. See the section Running queries to learn more about how to query your data.
Microsoft SQLPostgreSQL