Fixed typos in documentation.
This commit is contained in:
@ -82,7 +82,7 @@ Beyond the language support for debugging using tools such as gdb, MaxScale will
|
||||
|
||||
## Command Line Option
|
||||
|
||||
Normally when MaxScale starts it will place itself in the background and setup the signal masks so that it is immune to the normal set of signals that will cause the process to exit, SIGINT and SIGQUIT. This behaviour is normally what is required, however if you wish to run MaxScale under the control of a debugger it is useful to suppress this behaviour. A command line option, -d is provided to turn off this behaviour.
|
||||
Normally when MaxScale starts it will place itself in the background and setup the signal masks so that it is immune to the normal set of signals that will cause the process to exit, SIGINT and SIGQUIT. This behavior is normally what is required, however if you wish to run MaxScale under the control of a debugger it is useful to suppress this behavior. A command line option, -d is provided to turn off this behavior.
|
||||
|
||||
% gdb maxscale
|
||||
|
||||
@ -234,7 +234,7 @@ Server 0x60d920
|
||||
|
||||
### Modules
|
||||
|
||||
MaxScale makes significant use of moules, shared objects, that are loaded on demand based on the configuration. A routine exists that will print the currently loaded modules.
|
||||
MaxScale makes significant use of modules, shared objects, that are loaded on demand based on the configuration. A routine exists that will print the currently loaded modules.
|
||||
|
||||
(gdb) call printModules()
|
||||
|
||||
@ -476,7 +476,7 @@ The commands available are very similar to those described above to print things
|
||||
|
||||
## Listing Services
|
||||
|
||||
The list services command is designed to give a concise tabular view of the currently configured services within MaxScale along with key data that summarises the use beign made of the service.
|
||||
The list services command is designed to give a concise tabular view of the currently configured services within MaxScale along with key data that summarizes the use being made of the service.
|
||||
|
||||
**MaxScale>** list services
|
||||
|
||||
@ -830,13 +830,13 @@ Server 0x6ec5d0 (server4)
|
||||
|
||||
* the value of ‘Ndb_cluster_node_id’ for SQL nodes in MySQL Cluster
|
||||
|
||||
* the -1 value for a failure getting one of these informations
|
||||
* the -1 value for a failure getting one of these information
|
||||
|
||||
* Repl Depth is the replication depth level found by MaxScale MySQL Monitor
|
||||
|
||||
* Master Id is the master node, if available, for current server
|
||||
|
||||
* Slave Ids is the slave list for the current node, if availbable
|
||||
* Slave Ids is the slave list for the current node, if available
|
||||
|
||||
Note, the Master Root Server used for routing decision is the server with master role and with lowest replication depth level. All slaves servers even if they are intermediate master are suitable for read statement routing decisions.
|
||||
|
||||
@ -844,7 +844,7 @@ Note, the Master Root Server used for routing decision is the server with master
|
||||
|
||||
Value of 0 or less than monitor interval means there is no replication delay.
|
||||
|
||||
* Last Repl Heartbeat is the maxScale timestamp read or inserted (if current server is master)
|
||||
* Last Repl Heartbeat is the MaxScale timestamp read or inserted (if current server is master)
|
||||
|
||||
The Replication Heartbeat table is updated by MySQL replication, starting MaxScale when there is a significant slave delay may result that Slave Delay and Last Repl Heartbeat are not available for some time in the slave server details
|
||||
|
||||
@ -1559,7 +1559,7 @@ Server 0x6ec5d0 (server4)
|
||||
|
||||
**MaxScale>** set server 0x6ec840 slave
|
||||
|
||||
Valid options that are recognised by the set server command are running, master and slave. Please note that if the monitor is running it will reset the flags to match reality, this interface is really for use when the monitor is disabled.
|
||||
Valid options that are recognized by the set server command are running, master and slave. Please note that if the monitor is running it will reset the flags to match reality, this interface is really for use when the monitor is disabled.
|
||||
|
||||
In user mode there is no need to find the address of the server structure, the name of the server from the section header in the configuration file make be given.
|
||||
|
||||
@ -1691,7 +1691,7 @@ Note, not all configuration elements can be changed dynamically currently. This
|
||||
|
||||
## Add user
|
||||
|
||||
The add user command is used to add new users to the debug CLI of MaxScale. The default behaviour of the CLI for MaxScale is to have a login name of admin and a fixed password of mariadb. Adding new users will disable this default behaviour and limit the login access to the users that are added.
|
||||
The add user command is used to add new users to the debug CLI of MaxScale. The default behavior of the CLI for MaxScale is to have a login name of admin and a fixed password of mariadb. Adding new users will disable this default behavior and limit the login access to the users that are added.
|
||||
|
||||
**MaxScale>** add user admin july2013
|
||||
|
||||
@ -1711,11 +1711,11 @@ User admin already exists.
|
||||
|
||||
**MaxScale>**** **
|
||||
|
||||
If you should forget or lose the the account details you may simply remove the passwd file in $MAXSCALE_HOME/etc and the system will revert to the default behaviour with admin/mariadb as the account.
|
||||
If you should forget or lose the the account details you may simply remove the passwd file in $MAXSCALE_HOME/etc and the system will revert to the default behavior with admin/mariadb as the account.
|
||||
|
||||
## Enable/disable log
|
||||
|
||||
The enable/disable log command is used to enable/disable the log facility of MaxScale. The default behaviour for MaxScale is to have all logs enabled in DEBUG version, and only error log in production release.
|
||||
The enable/disable log command is used to enable/disable the log facility of MaxScale. The default behavior for MaxScale is to have all logs enabled in DEBUG version, and only error log in production release.
|
||||
|
||||
Examples:
|
||||
|
||||
@ -1741,7 +1741,7 @@ No output for these commands in the debug interface, but in the affected logs th
|
||||
|
||||
# Logging facility
|
||||
|
||||
MaxScale generates output of its behavior to four distinct logs, error, messages, trace and debug log. Error and message logs are enabled by default but all logs can be dynamically enabled and disabled by using maxadm utility, debug client interface (telnet) or optionally by using your own application through the client API.
|
||||
MaxScale generates output of its behavior to four distinct logs, error, messages, trace and debug log. Error and message logs are enabled by default but all logs can be dynamically enabled and disabled by using maxadmin utility, debug client interface (telnet) or optionally by using your own application through the client API.
|
||||
|
||||
## Log contents
|
||||
|
||||
|
@ -52,5 +52,5 @@ Reasons for "backend failure" in rwsplit:
|
||||
|
||||
### Router error
|
||||
|
||||
In cases where SESSION_ROUTE_QUERY has returned successfully (=1) query may not be successfully processed in backend or even sent to it. It is posible that router fails in routing the particular query but there is no such error which would prevent session from continuing. In this case router handles error silently by creating and adding MySQL error to first available backend’s (incoming) eventqueue where it is found and sent to client (clientReply).
|
||||
In cases where SESSION_ROUTE_QUERY has returned successfully (=1) query may not be successfully processed in backend or even sent to it. It is possible that router fails in routing the particular query but there is no such error which would prevent session from continuing. In this case router handles error silently by creating and adding MySQL error to first available backend’s (incoming) eventqueue where it is found and sent to client (clientReply).
|
||||
|
||||
|
@ -74,7 +74,7 @@ When a switch takes a value, this may either be as the next argument on the comm
|
||||
|
||||
If no arguments other than the command line switches are passed to MaxAdmin it will enter its interactive mode of operation. Users will be prompted to enter commands with a **MaxScale>** prompt. The commands themselves are documented in the sections later in this document. A help system is available that will give some minimal details of the commands available.
|
||||
|
||||
Command history is available on platforms that support the libedit library. This allows the use of the up and down arrow keys to recall previous commands that have been executed by MaxAdmin. The default edit mode for the history is to emulate the vi commands, the behaviour of libedit may however be customised using the .editrc file. To obtain the history of commands that have been executed use the inbuilt history command.
|
||||
Command history is available on platforms that support the libedit library. This allows the use of the up and down arrow keys to recall previous commands that have been executed by MaxAdmin. The default edit mode for the history is to emulate the vi commands, the behavior of libedit may however be customized using the .editrc file. To obtain the history of commands that have been executed use the inbuilt history command.
|
||||
|
||||
In interactive mode it is possible to execute a set of commands stored in an external file by using the source command. The command takes the argument of a filename which should contain a set of MaxScale commands, one per line. These will be executed in the order they appear in the file.
|
||||
|
||||
@ -713,7 +713,7 @@ MaxScale uses a number of threads, as defined in the MaxScale configuration file
|
||||
2 | Processing | 1 | 0x7f54c0030d00 | < 100ms | IN|OUT
|
||||
MaxScale>
|
||||
|
||||
The resultant output returns data as to the average thread utilisation for the past minutes 5 minutes and 15 minutes. It also gives a table, with a row per thread that shows what DCB that thread is currently processing events for, the events it is processing and how long, to the nearest 100ms has been send processing these events.
|
||||
The resultant output returns data as to the average thread utilization for the past minutes 5 minutes and 15 minutes. It also gives a table, with a row per thread that shows what DCB that thread is currently processing events for, the events it is processing and how long, to the nearest 100ms has been send processing these events.
|
||||
|
||||
## The Event Queue
|
||||
|
||||
@ -726,7 +726,7 @@ At the core of MaxScale is an event driven engine that is processing network eve
|
||||
0x1e22f10 | Processing | IN|OUT |
|
||||
MaxScale>
|
||||
|
||||
The output of this command gives the DCB’s that are currenting in the event queue, the events queued for that DCB, and events that are beign processed for that DCB.
|
||||
The output of this command gives the DCB’s that are currently in the event queue, the events queued for that DCB, and events that are being processed for that DCB.
|
||||
|
||||
## The Housekeeper Tasks
|
||||
|
||||
@ -770,7 +770,7 @@ This command provides important version information for the module. Each module
|
||||
|
||||
MaxScale write a number of log files in the log directory within MaxScale home directory. The default option for these is that the grow continually, it is recommended that periodically the log files are rotated. This will close the current log file and open a new one with a new name. The log file names use a sequence number which is incremented each time the logs are rotated.
|
||||
|
||||
It is possible to rotate just a single log file, using the flush log command and the name of the log to flush. The names that are recognised by MaxAdmin are error, message, trace or debug.
|
||||
It is possible to rotate just a single log file, using the flush log command and the name of the log to flush. The names that are recognized by MaxAdmin are error, message, trace or debug.
|
||||
|
||||
MaxScale> flush log message
|
||||
MaxScale>
|
||||
@ -819,7 +819,7 @@ Note that this uses the default port of 6603 and confines the connections to loc
|
||||
|
||||
The way that MaxScale does it’s polling is that each of the polling threads, as defined by the threads parameter in the configuration file, will call epoll_wait to obtain the events that are to be processed. The events are then added to a queue for execution. Any thread can read from this queue, not just the thread that added the event.
|
||||
|
||||
Once the thread has done an epoll call with no timeout it will either do an epoll_wait call with a timeout or it will take an event from the queue if there is one. These two new parameters affect this behaviour.
|
||||
Once the thread has done an epoll call with no timeout it will either do an epoll_wait call with a timeout or it will take an event from the queue if there is one. These two new parameters affect this behavior.
|
||||
|
||||
The first parameter, which may be set by using the non_blocking_polls option in the configuration file, controls the number of epoll_wait calls that will be issued without a timeout before MaxScale will make a call with a timeout value. The advantage of performing a call without a timeout is that the kernel treats this case as different and will not rescheduled the process in this case. If a timeout is passed then the system call will cause the MaxScale thread to be put back in the scheduling queue and may result in lost CPU time to MaxScale. Setting the value of this parameter too high will cause MaxScale to consume a lot of CPU when there is infrequent work to be done. The default value of this parameter is 3.
|
||||
|
||||
|
@ -336,7 +336,7 @@ The Corosync / Pacemaker cluster is ready to be configured to manage resources.
|
||||
|
||||
The Corosync / Pacemaker cluster is ready to be configured to manage resources.
|
||||
|
||||
# MaxScale init script /etc/init.d/maxscale
|
||||
# MaxScale init script /etc/init.d/maxscale
|
||||
|
||||
The MaxScale /etc/init.d./maxscale script allows to start/stop/restart and monitor MaxScale process running in the system.
|
||||
|
||||
@ -400,7 +400,7 @@ For more informations;
|
||||
|
||||
For more informations;
|
||||
|
||||
[http://www.linux-ha.org/wiki/LSB_Resource_Agents](http://www.linux-ha.org/wiki/LSB_Resource_Agents)
|
||||
[http://www.linux-ha.org/wiki/LSB_Resource_Agents](http://www.linux-ha.org/wiki/LSB_Resource_Agents)
|
||||
|
||||
After checking MaxScale is well managed by the /etc/init.d/script is possible to configure the MaxScale HA via Pacemaker.
|
||||
|
||||
|
Reference in New Issue
Block a user