The next step is to modify the configuration file with the user
and password we defined in the previous step
(Section 220.127.116.11, “Create a MySQL User(s)”). Open the configuration
file located in
/usr/local/etc/mysql/fabric.cfg on Unix and
The following shows the content of the configuration file and
the modifications necessary. Notice that in the
[storage] section, we place the user and
password of the user created in the previous step. We explain
each section in more detail below.
[DEFAULT] prefix = /usr/local sysconfdir = /usr/local/etc logdir = /var/log [storage] address = localhost:3306 user = fabric password = secret database = fabric connection_timeout = 6 connection_attempts = 6 connection_delay = 1 [servers] user = fabric password = [protocol.xmlrpc] address = localhost:32274 threads = 5 user = admin password = admin disable_authentication = no realm = MySQL Fabric ssl_ca = ssl_cert = ssl_key = [executor] executors = 5 [logging] level = INFO url = file:///var/log/fabric.log [sharding] mysqldump_program = /usr/bin/mysqldump mysqlclient_program = /usr/bin/mysql [connector] ttl = 1 [failure_tracking] notifications = 300 notification_clients = 50 notification_interval = 60 failover_interval = 0 detections = 3 detection_interval = 6 detection_timeout = 1 prune_time = 3600
The sections of the configuration file as as follows. Each
section has one or more variables defined that provide key
information to the Fabric system libraries. You should not have
to change any of these variables other than the user and
password for the backing store (in the
If a value for a required option is not set through the command
line (for example,
nor is found in the configuration file, Fabric looks in the
[DEFAULT] section. It is worth mentioning
though that this section does not support hierarchical
definitions and has the following variables:
prefix: Installation prefix given to setup.py
when doing an install.
sysconfdir: The directory where the
configuration file is placed.
logdir: Absolute path where the log file
created by a daemon is stored (for example,
/var/log). It is used when the
logging.url option has a relative path.
The configuration options related to the backing store are
listed in the
[storage] section and are the
address: Identifies the host and port where the
MySQL Server is running (for example,
user: User's name used to connect to MySQL (for
password: Password used to authenticate user
secret). Although it is not
recommended, you may set an empty password by leaving the
database: The database where the Fabric's
tables are created (for example,
connection_timeout: The maximum amount of time
in seconds that Fabric waits for a database access to
complete before aborting the request on behalf of which the
database access is being performed (for example,
connection_attempts: The maximum number of
times Fabric tries to create a connection to access the
database before aborting the request on behalf of which the
database access is being performed (for example,
connection_delay: The delay in seconds between
consecutive attempts to create a connection to the database
Fabric accepts requests through an XML-RPC protocol which can be
configured in the
address: Identifies the host and port used by
Fabric to accept XML-RPC requests (for example,
threads: Number of XML-RPC session threads that
are simultaneously created. In other words, it determines
the number of concurrent requests that Fabric may accept
password: User's password used to authenticate
user: User's name used to authenticate command
disable_authentication: Whether command
requests require authentication or not
realm: Sphere where users are defined.
ssl_ca: The path to a file in PEM format that
contains a list of trusted SSL certificate authorities.
ssl_cert: The name of the SSL certificate file
in PEM format to use for establishing a secure connection.
ssl_key: The name of the SSL key file in PEM
format to use for establishing a secure connection.
The requests received through the XML-RPC are mapped to procedures which can be immediately executed or scheduled through the executor which guarantees that conflicting requests are processed in a serial other. Procedures scheduled through the executor are processed within the context of thread spawned by the executor. Usually, read operations are immediately executed by the XML-RPC session thread and write operations are scheduled through the executor.
The configuration options related to the “executor”
are in the
executors: Number of threads that are created
to process procedures that are scheduled through the
executor (for example,
Fabric logs information on its activities to the standard output
when started as regular process. However, when started as a
daemon, it writes information to a file. Logging information can
be configured in the
level: How verbose is the logged information:
CRITICAL (for example,
url: File used to store logging information
when Fabric is started as daemon (for example,
file:///var/log/fabric.log). The option
can be either a full or relative path.
To perform operations such as moving and splitting shards,
Fabric relies on the
mysql client programs. However, as they may be
installed in different locations and may not be available in the
PATH environment variables, it is necessary
to specify where they can be found in the
mysqldump_program: Path to mysqldump (for
mysqlclient_program: Path to mysql client (for
# Remove entries older than _PRUNE_TIME in seconds. _MIN_PRUNE_TIME = 60 _PRUNE_TIME = _DEFAULT_PRUNE_TIME = 3600 # Interval in seconds within which consecutive failures are considered. _MIN_DETECTION_INTERVAL = 2.0 _DETECTION_INTERVAL = _DEFAULT_DETECTION_INTERVAL = 5.0 # Number of consecutive failures to consider a server faulty. _MIN_DETECTIONS = 1 _DETECTIONS = _DEFAULT_DETECTIONS = 2 # Number of seconds that it should wait before giving up to connect to a server. _MIN_DETECTION_TIMEOUT = 1 _DETECTION_TIMEOUT = _DEFAULT_DETECTION_TIMEOUT = 1
Connectors and other external entities can report errors while
accessing servers so that Fabric can keep track of server's
health and act accordingly. For example, Fabric may promote a
new master after getting
different clients (
notification_clients) within a
pre-defined time interval (i.e.
notification_interval). If a server is considered
unstable but it is not a master, it is simply marked as faulty.
To avoid making the system unstable, a new master can only be
automatically promoted after the
has been elapsed since the last promotion. In order to ease
Fabric's adoption, a built-in failure detector is provided. If
the failure detector is enabled to monitor a group, a new master
will be promoted after
3 failed successive
attempts to access the current master within a time interval
failover_interval). The failure detection routine
tries to connect to servers in a group and uses the value
detection_timeout as timeout. These
options are found in the
notifications: Number of reported issues after
which a server is considered unstable.
notification_clients: Number of different
sources that must report an issue to consider a server
notification_interval: Windown interval in
seconds that is considered to compute the number of reported
failover_interval: Interval after which a new
master can be automaically elected if the current master is
detections: Number of successive failed
attempts after which the built-in failure detector consider
the server unstable.
detection_interval: Window interval in seconds
that is considered to compute the number of successive
failed attempts to access a server.
detection_timeout: Timeout in seconds used to
try to connect to a server.
prune_time: Period in seconds during which
reported issues are kept in the error log.
Connectors that are Fabric-aware contact Fabric to fetch
information on groups, shards, and servers and cache the results
locally for a time period to improve performance. Any
information that specifies how connectors must handle
information reported by Fabric is defined in the
ttl: Time-to-live in seconds. This determines
how long a connector may consider a information fetched from