Bitnami MySQL for Google Multi-Tier Solutions

What are the differences between a Bitnami Single-Tier Solution and Multi-Tier Solution?

Single-tier architecture implies that all the required components of an application run on a single server. If your environment is growing and becoming more complex, a single layer architecture will not meet your scalability requirements. Single-Tier Solutions are great for departmental applications, smaller production environments, new users, or those applications that don't support multi-tier architectures.

The typical architecture of a Bitnami Single-Tier Solution looks like this:

Single-tier architecture

Multi-tier architecture involves more than one server and infrastructure resource. As an example, the Front End-Database topology separates the application server from the database server. This allows you to extend workloads in the cloud and tailor your application to meet specific scalability and reliability goals. Multi-Tier Solutions provide more sophisticated deployment topologies for improved scalability and reliability for larger production or mission critical environments.

This Bitnami Multi-Tier Solution uses multiple virtual machines to replicate the databases from the master node to a configurable number of replicas. This topology is illustrated below:

Multi-tier architecture

Description

MySQL is a fast, reliable, scalable, and easy to use open-source relational database system. MySQL Server is designed to handle mission-critical, heavy-load production applications.

First steps with the Bitnami MySQL Stack

Welcome to your new Bitnami application running on Google Cloud Platform! Here are a few questions (and answers!) you might need when first starting with your application.

What credentials do I need?

You need two sets of credentials:

  • The application credentials, consisting of a username and password. These credentials allow you to log in to your new Bitnami application.

  • The server credentials, consisting of an SSH username and key. These credentials allow you to log in to your Google Cloud Platform server using an SSH client and execute commands on the server using the command line.

What is the administrator username set for me to log in to the application for the first time?

Username: root

What is the administrator password?

The password is randomly assigned when you first launched the application through the Google Cloud Launcher. Refer to the FAQ to learn how to find the application credentials.

What SSH username should I use for secure shell access to my application?

SSH username: bitnami

How do I get my SSH key or password?

You will need to create and associate an SSH key pair with the server(s). Use the same key pair for secure shell access to the server. Click here for more information.

How to start or stop the services?

NOTE: The steps below require you to execute the commands on the remote server. Please check our FAQ for instructions on how to connect to your server through SSH.

Each Bitnami server includes a control script that lets you easily stop, start and restart all the services installed on the current individual server.

Obtain the status of a service with the service bitnami status command:

$ sudo service bitnami status

Use the service bitnami command to start, stop or restart all the services in a similar manner:

  • Start all the services.

    $ sudo service bitnami start
    
  • Stop all the services.

    $ sudo service bitnami stop
    
  • Restart all the services.

    $ sudo service bitnami restart
    
TIP: To start, restart or stop individually each server of the cluster, check the FAQ section about how to start or stop servers in a Multi-Tier Solution.

How to connect instances hosted in separate virtual networks or VPCs?

The Google Cloud Platform makes it possible to connect instances hosted in separate Virtual Private Clouds (VPCs), even if those instances belong to different projects or are hosted in different regions. This feature, known as VPC Network Peering, can result in better security (as services do not need to be exposed on public IP addresses) and performance (due to use of private, rather than public, networks and IP addresses).

Learn more about VPC Network Peering.

How to check cluster replication status?

To check the status of your MySQL cluster, log in to the master or primary database server host using SSH, start the MySQL command-line client using your administrative credentials, and run the following command within it:

SHOW PROCESSLIST;
SHOW SLAVE HOSTS;

The output of these commands will be a list of cluster nodes and their current replication status.

How to add nodes to the cluster?

IMPORTANT: These steps assume that you have already installed the Google Cloud SDK and you are signed in to the Google Cloud Platform through the gcloud command-line client. If this is not the case, please refer to the Google Cloud SDK documentation for instructions on how to install and use the command-line client.

To add nodes to the cluster, follow these steps:

  • Log in to the Google Cloud Console.
  • Browse to the Deployment Manager and select the deployment to which you wish to add nodes.
  • In the deployment overview, review the deployment properties and click to view the "Expanded Config" deployment configuration file.

Expanded configuration

  • Copy or download the contents of the "Expanded Config" file to the server with the Google Cloud SDK as expanded-config.yaml.
  • Edit the file using a text editor and add configuration for one or more additional nodes, by copying the configuration and metadata for an existing node and its corresponding data disk and then updating the copied configuration to use a unique name for the new node(s) and data disk(s).

    For example, to add a new MongoDB node to a MongoDB cluster, here is an abridged example of the configuration and metadata that you would update to add a new node and data disk. To create a unique name for the new node, you would typically replace the XX placeholder in the node name with a number.

    NOTE: The code block below is an illustrative example for MongoDB and will differ in your specific deployment. You should always copy the code block from your deployment's actual configuration file.
     - metadata:
         dependsOn:
         - mongodb-multivm-2-node-XX-data
         - mongodb-multivm-2-node-0
       name: mongodb-multivm-2-node-XX
       properties:
         bootDiskType: pd-standard
         canIpForward: true
         disks:
         - autoDelete: true
           boot: true
           deviceName: mongodb-multivm-2-node-XX-boot
           initializeParams:
             diskType: https://www.googleapis.com/compute/v1/projects/PROJECT-NAME/zones/us-central1-f/diskTypes/pd-standard
             sourceImage: projects/bitnami-launchpad/global/images/bitnami-mongodb-3-4-7-0-linux-debian-8-x86-64-nami
           type: PERSISTENT
         - autoDelete: true
           boot: false
           deviceName: mongodb-multivm-2-node-XX-data
           source: $(ref.mongodb-multivm-2-node-XX-data.selfLink)
           type: PERSISTENT
         machineType: https://www.googleapis.com/compute/v1/projects/PROJECT-NAME/zones/us-central1-f/machineTypes/n1-standard-1
         metadata:
             ...
         networkInterfaces:
         - accessConfigs:
           - name: External NAT
             type: ONE_TO_ONE_NAT
           network: https://www.googleapis.com/compute/v1/projects/PROJECT-NAME/global/networks/default
           subnetwork: https://www.googleapis.com/compute/v1/projects/PROJECT-NAME/regions/us-central1/subnetworks/default
         serviceAccounts:
         - email: default
           scopes:
           - https://www.googleapis.com/auth/cloudruntimeconfig
         tags:
           items:
           - mongodb-multivm-2-node-XX
         zone: us-central1-f
       type: compute.v1.instance
     - name: mongodb-multivm-2-node-XX-data
       properties:
         sizeGb: 10
         type: https://www.googleapis.com/compute/v1/projects/PROJECT-NAME/zones/us-central1-f/diskTypes/pd-standard
         zone: us-central1-f
       type: compute.v1.disk    
    
  • Preview the updated deployment with the command below. Replace the DEPLOYMENT-ID placeholder in the command below with the correct name of your deployment.

    $ gcloud deployment-manager deployments update DEPLOYMENT-ID --config expanded-config.yaml --preview
    
  • Once you have verified that the deployment preview is correct, confirm the deployment and initialize the new node(s):

    $ gcloud deployment-manager deployments update DEPLOYMENT-ID
    

Verify that the new node(s) have been added successfully by logging in to the Google Cloud Console and selecting the deployment to check the number of running nodes. Once you have confirmed that the new node(s) have been added successfully, log in to the primary node and verify that the new node(s) are now part of the cluster by checking the cluster replication status.

What is the default configuration?

The grant tables define the initial MySQL user accounts and their access privileges. The default configuration consists of two user accounts:

  • root: This user has all privileges including remote access to the database.
  • repl: Has "Replication slave" privileges which enable replication slaves to read binary log events from the master.

Check our recommendations for a production server.

MySQL version

In order to see which MySQL version your system is running, execute the following command:

$ mysqld --version

MySQL configuration file

The MySQL configuration file is located at /opt/bitnami/mysql/conf/my.cnf.

The MySQL official documentation has more details about how to configure the MySQL database.

MySQL socket

On Unix, MySQL clients can connect to the server in the local machine using an Unix socket file at /opt/bitnami/mysql/tmp/mysql.sock.

MySQL port

The default port for MySQL is 3306.

MySQL Process Identification Number

The MySQL .pid file allows other programs to find out the PID (Process Identification Number) of a running script. Find it at /opt/bitnami/mysql/tmp/mysqld.pid.

MySQL error log

The error log file contains information indicating when MySQL was started and stopped and also any critical errors that occur while the server is running. If the MySQL server notices a table that needs to be automatically checked or repaired, it writes a message to the error log. Find it at /opt/bitnami/mysql/logs/mysqld.log.

How is the cluster configured?

The Bitnami Multi-Tier Solution for MySQL uses multiple VMs, consisting of 1 master and 1 or more slaves, to provide a horizontally scalable and fault-tolerant deployment. Data automatically replicates from the master node to all slave nodes. Binary logging is enabled.

To understand how it works, consider the example below of a two-node cluster (one master and one slave):

  • On the master node, create a new table and populate it with some data:

     mysql [(none)]> USE bitnami;
     Database changed
    
     mysql [bitnami]> CREATE TABLE test (id INT NOT NULL, value VARCHAR(255) NOT NULL);
     Query OK, 0 rows affected (0.37 sec)
    
     mysql [bitnami]> INSERT INTO test VALUES (1, 'foo'), (2, 'bar');
     Query OK, 2 rows affected (0.07 sec)
     Records: 2  Duplicates: 0  Warnings: 0
    
  • On any of the slave nodes, check if the table exists and list its contents. It should display the same data originally entered on the master node:

     mysql [(none)]> USE bitnami;
     Database changed
    
     mysql [bitnami]> SELECT * FROM test;
     +----+-------+
     | id | value |
     +----+-------+
     |  1 | foo   |
     |  2 | bar   |
     +----+-------+
     2 rows in set (0.00 sec)
    

This shows that records added on the master node are automatically replicated to the slave node(s). For more information, refer to the MySQL documentation on replication.

How to find the database credentials?

How to connect to the MySQL database?

You can connect to the MySQL database from the same computer where it is installed with the mysql client tool.

$ mysql -u root -p 

You will be prompted to enter the *root* user password. This is the [same password entered during the server deployment process](/google-templates/faq#how-to-find-application-credentials).

How to connect to MySQL from a different machine?

IMPORTANT: By default, the database port for the nodes in this solution cannot be accessed over a public IP address. As a result, you will only be able to connect to your database nodes from machines that are running in the same network. For security reasons, we do not recommend making the database port accessible over a public IP address. If you must make it accessible over a public IP address, we recommend restricting access to a trusted list of source IP addresses using firewall rules. Refer to the FAQ for information on opening ports in the server firewall.

Connecting to MySQL from the same network

To connect to MySQL from a different machine in the same network, use a command like the one below:

$ mysql -h SERVER-IP -u root -p

You will be prompted to enter the root user password. This is the same password entered during the server deployment process.

If you wish to connect to the primary MySQL host from a different network using its public IP address, we recommend creating an SSH tunnel, as described in the FAQ. However, you should only do this if you wish to temporarily connect to, or use, the MySQL console. This approach is not recommended to permanently connect your application to the MySQL cluster, as a connectivity failure in the SSH tunnel would affect your application's functionality.

Connecting to MySQL from a different network

If you must connect to the database from a machine that it is not running in the same network as the MySQL cluster, you can follow these approaches (these are shown in order of preference, from the most secure to the less recommended solution):

  • Option 1: Peer both virtual networks to secure the connections between the two instances. Learn how to connect instances in different networks using network peering.
  • Option 2: Create an SSH tunnel to connect the database console to perform administrative tasks using the primary host's public IP address. Refer to the FAQ for more information on this.

    NOTE: You should only access the primary server using an SSH tunnel if you wish to temporarily connect to, or use, the MySQL console. This approach is not recommended to permanently connect your application to the MySQL cluster, as a connectivity failure in the SSH tunnel would affect your application's functionality.
  • Option 3: Make the server publicly accessible and restrict access to a trusted list of source IP addresses using firewall rules. Refer to the FAQ for information on opening ports in the server firewall.

How to create a database for a custom application?

These are the basic steps to create a new database and user for your applications:

  • Create a new database:

     mysql> create database DATABASE_NAME;
     Query OK, 1 row affected (0.00 sec)
    
  • Create a new user (only with local access) and grant privileges to this user on the new database:

     mysql> grant all privileges on DATABASE_NAME.* TO 'USER_NAME'@'localhost' identified by 'PASSWORD';
     Query OK, 1 row affected (0.00 sec)
    
  • Create a new user (with remote access) and grant privileges to this user on the new database:

     mysql> grant all privileges on DATABASE_NAME.* TO 'USER_NAME'@'%' identified by 'PASSWORD';
     Query OK, 1 row affected (0.00 sec)
    
  • After modifying the MySQL grant tables, execute the following command in order to apply the changes:

     mysql> flush privileges;
     Query OK, 1 row affected (0.00 sec)
    

Some applications require specific privileges in the database. Check the MySQL official getting started guide.

How to create a database backup?

To back up all the databases, create a dump file using the mysqldump tool.

$ mysqldump -A -u root -p > backup.sql

This operation could take some time depending on the database sizes.

NOTE: The steps previously described will only back up the data contained inside your databases. There may be other files that you should take into account when performing a full backup, such as files that may have been uploaded to your application. Refer to your application's documentation for more details.

How to restore a database backup?

Once you have the backup file, you can restore it with a command like the one below:

$ mysql -u root -p < backup.sql

How to secure your server?

Once you have created a new database and user for your application, connect to your MySQL server and follow these recommendations:

  • Disallow root login remotely:

     mysql> DELETE FROM mysql.user WHERE User='root' AND Host NOT IN ('localhost', '127.0.0.1', '::1');
    

    Don't forget to reload the privileges tables to apply the changes:

     mysql> FLUSH PRIVILEGES;
    
  • Change your root user password.

  • It is strongly recommended that you do not have empty passwords for any user accounts when using the server for any production work.

The configuration adopted by the slaves when connecting to the master is set using the "CHANGE MASTER TO" syntax. Replication slaves store the password for the replication master in the master info repository. In case you receive the following warning message in the log file of MySQL you can use the "START SLAVE" syntax to specify credentials for connecting to the master.

IMPORTANT: Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL official documentation for more information.

How to recover a MySQL database with errors?

Before trying to recover a MySQL database, you should check the exact error in the MySQL log file at /opt/bitnami/mysql/logs/mysqld.log. Check the latest entries in the MySQL log file with the following command:

$ sudo tail -n 100 /opt/bitnami/mysql/logs/mysqld.log 

In this case, assume the following error in the log file:

110108 10:37:45 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'user' is marked as crashed

Here are some steps to resolve this error:

  • The MySQL database is configured to use InnoDB engine by default. You can add the innodb_force_recovery=1 option in the main MySQL configuration file at /opt/bitnami/mysql/etc/my.cnf to try and fix the database:

     [mysqld]
     innodb_force_recovery = 1
    
  • Start the MySQL database with the following command:

     $ mysqld --skip-grant-tables --user=mysql --pid-file=/opt/bitnami/mysql/tmp/mysqld.pid 
     --skip-external-locking --port=3306 --sock=/opt/bitnami/mysql/tmp/mysql.sock
    
  • Open a new console and try to log in the database:

     $ mysql -u root -p
    
  • In this case, the error was related to the mysql.user table. Run these commands:

     mysql> use mysql;
     mysql> repair table user;
     mysql> check table user;
     mysql> exit;
    

If the table is recovered, you should see "OK" in the mysql.user status table. Do not forget to remove the innodb_force_recovery option from the my.cnf file and restart the MySQL server again.

$ sudo service bitnami restart

If you find a different error or cannot fix an issue, we can try to help at http://community.bitnami.com.

google-templates