[MXS-420] MaxScale ID in replication_heartbeat table is not unique enough Created: 2015-10-23 Updated: 2017-12-01 Resolved: 2016-10-17 |
|
| Status: | Closed |
| Project: | MariaDB MaxScale |
| Component/s: | mariadbmon |
| Affects Version/s: | 1.2.1 |
| Fix Version/s: | N/A |
| Type: | New Feature | Priority: | Major |
| Reporter: | markus makela | Assignee: | markus makela |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Description |
|
MaxScale will use the PID of the running process to identify each MaxScale instance. This might be enough for multiple MaxScales running on the same system but MaxScales running on different systems can have multiple processes with the same PID. MaxScale needs to use an identifier that is unique to the process and unique to the system MaxScale is running in. |
| Comments |
| Comment by Dipti Joshi (Inactive) [ 2015-10-31 ] |
|
markus makela Why does MaxScale need to identify itself ? Or do you mean MaxAdmin ? |
| Comment by markus makela [ 2015-10-31 ] |
|
MaxScale detects replication lag by updating a row in the maxscale_schema.replication_heartbeat table. Each MaxScale instance uses the PID of the process to identify which row to update. Since PID isn't unique across systems, we need to add an additional identifier to it (hostname perhaps?) to prevent multiple MaxScales with the same PID updating the same row. |
| Comment by Dipti Joshi (Inactive) [ 2015-11-02 ] |
|
Is the maxscale_schema.replication_heartbeat table on the MariaDB/MaxScale server being monitored or local server on MaxScale machine ? Thanks, |
| Comment by markus makela [ 2015-11-02 ] |
|
The server being monitored by MaxScale. |
| Comment by markus makela [ 2016-10-17 ] |
|
Conflicts caused by overlapping updates are not a negative thing. This just means that the timestamp of the field gets updated more frequently. |