MySQL

To manage MySQL databases, Turbonomic can connect to one or more database servers within a defined scope.

Prerequisites

Adding a MySQL database target

Note:

This topic describes features that are available in the new design of the user interface. This new design is enabled by default. If you switched to the legacy design, click New Feature Toggle button in the navigation bar of the user interface and then turn on the toggle to re-enable the new design. For more information, see New Design for the User Interface.

You can add all matching targets within a given scope.

  1. Click Settings > Target Configuration.

  2. On the Target configuration page, click Add Target.

  3. On the Select target page, click MySQL.

  4. In the side panel, review the connection requirements and then click Connect Target.

  5. Configure the following settings:

    • Display name

      Specify a name that uniquely identifies this connection.

      This name is for display purposes only and does not need to match any name in MySQL.

    • Username

      Specify the username of the account Turbonomic uses to connect to the target.

    • Password

      Specify the password of the account Turbonomic uses to connect to the target.

    • Scope

      Specify the scope Turbonomic uses for application discovery.

      The scope is a group of applications that are stitched to the underlying VMs when the VMs are discovered as part of a separate Turbonomic target.

      If you set a scope, Turbonomic searches for virtual machines in the selected group.

      Turbonomic can monitor up to 500 virtual machines in a group. If you have more than 500 virtual machines in your environment, split them across smaller groups and then add those groups as individual targets.

    • Port number

      Specify the MySQL remote port number. By default, the port is 3306.

    • Authenticate all database servers

      If you select this option, Turbonomic attempts to authenticate all database servers in the selected scope. If Turbonomic is unable to authenticate a database server, the target is not added and no data is collected.

Monitored resources

Turbonomic monitors the following resources:

  • Database server

    • Database memory (DBMem)

      Database memory (or DBMem) is the measurement of memory that is utilized by a Database Server.

    • Transaction

      Transaction is a value that represents the per-second utilization of the transactions that are allocated to a given entity.

    • Response time

      Response time is the elapsed time between a request and the response to that request. Response time is typically measured in seconds (s) or milliseconds (ms).

    • Connection

      Connection is the measurement of database connections utilized by applications.

      A database connection is a physical communication pathway that holds database sessions, which are logical entities in the database instance memory that represent the state of a current user login to a database. Connections should be managed properly.

    • DB cache hit rate

      DB cache hit rate is the measurement of Database Server accesses that result in cache hits, measured as a percentage of hits versus total attempts. A high cache hit rate indicates efficiency.

  • Virtual machine

    • Virtual memory (vMem)

      Virtual memory (vMem) is the measurement of memory that is in use.

    • Virtual CPU (vCPU)

      Virtual CPU is the measurement of CPU that is in use.

    • Virtual storage

      Virtual ssorage is the measurement of virtual storage capacity that is in use.

    • Storage access (IOPS)

      Storage access, also known as IOPS, is the per-second measurement of read and write access operations on a storage entity.

    • Latency

      Latency is the measurement of storage latency.

Actions

Turbonomic supports the following actions:

  • Database server

    Resize

    • Database memory (DBMem)

      Actions to resize database memory are driven by data on the Database Server, which is more accurate than data on the hosting VM. Turbonomic uses database memory and cache hit rate data to decide whether resize actions are necessary.

      A high cache hit rate value indicates efficiency. The optimal value is 100% for on-prem (self-hosted) Database Servers, and 90% for cloud Database Servers. When the cache hit rate reaches the optimal value, no action generates even if database memory utilization is high. If utilization is low, a resize down action generates.

      When the cache hit rate is less than the optimal value but database memory utilization remains low, no action generates. If utilization is high, a resize up action generates.

  • Virtual machine

    Resize

    Resize resource capacity, reservation, or limit to improve performance.