mysql-monitoring-release

Notifications

Requires notifications-release

Don't forget to first create a database for the notifications, e.g.

mysql -uroot -ppassword -h10.244.7.2 -e "CREATE DATABASE notifications_db"

Then use that in your notifications-db-stub.yml, e.g. tcp://root:[email protected]:3306/notifications_db

Adding the UAA client

A client is required for sending notifications. With the cf-uaac gem installed:

$ uaac target https://uaa.${YOUR_SYSTEM_DOMAIN}
# Enter the secret from 'Credentials -> UAA -> Admin Client Credentials' when prompted
$ uaac token client get admin
$ uaac client add mysql-monitoring \
  --authorized_grant_types client_credentials \
  --authorities notifications.write,critical_notifications.write,emails.write,emails.write \
  --secret ${MYSQL_MONITORING_NOTIFICATIONS_CLIENT_SECRET:-"REPLACE_WITH_CLIENT_SECRET"}

Setup

In your bosh deployment manifest make sure you:

1. Add the value of mysql-monitoring.replication-canary.canary_username to cf_mysql.mysql.server_audit_excluded_users
2. Add the value of mysql-monitoring.replication-canary.canary_username to cf_mysql.broker.quota_enforcer.ignored_users
3. Add the following to cf_mysql.mysql.seeded_databases:

- name: VALUE_OF_mysql-monitoring.replication-canary.canary_database
  username: VALUE_OF_mysql-monitoring.replication-canary.canary_username
  password: VALUE_OF_mysql-monitoring.replication-canary.canary_password

1. Replace the client username (mysql-monitoring.replication-canary.notifications_client_username) with the one created above
2. Replace the client secret (mysql-monitoring.replication-canary.notifications_client_secret) with the one created above

Deploying as the backing store for Cloud Foundry

In order to use cf-mysql-release as the internal database for Cloud Foundry, various components of Cloud Foundry like UAA and CAPI require the backing database to be online before they will start successfully. However, the replication canary also has a dependency on UAA to obtain a token for sending emails via the notifications service.

The easiest way to break this dependency cycle when adding this monitoring to a Cloud Foundry deployment is as follows:

• ensure max_in_flight=1 (mysql always needs this anyway)
• ensure serial: true in the update block
• re-order jobs in manifest as follows:
• consul
• other jobs e.g. NATS, router
• mysql DBs
• mysql proxies
• UAA/CC
• replication-canary
• everything else including Diego