mirror of
https://github.com/asterisk/asterisk.git
synced 2025-10-31 10:47:18 +00:00
c8ab8be1ca
Signed-off-by: Jaco Kroon <jaco@uls.co.za> UserNote: New cache_size option for res_odbc to on a per class basis limit the number of cached connections. Please reference the sample configuration for details.
156 lines
6.8 KiB
Plaintext
156 lines
6.8 KiB
Plaintext
;;; odbc setup file
|
|
|
|
; ENV is a global set of environmental variables that will get set.
|
|
; Note that all environmental variables can be seen by all connections,
|
|
; so you can't have different values for different connections.
|
|
[ENV]
|
|
;INFORMIXSERVER => my_special_database
|
|
;INFORMIXDIR => /opt/informix
|
|
;ORACLE_HOME => /home/oracle
|
|
|
|
; All other sections are arbitrary names for database connections.
|
|
|
|
;
|
|
; The context name is what will be used in other configuration files, such
|
|
; as extconfig.conf and func_odbc.conf, to reference this connection.
|
|
[asterisk]
|
|
;
|
|
; Permit disabling sections without needing to comment them out.
|
|
; If not specified, it is assumed the section is enabled.
|
|
enabled => no
|
|
;
|
|
; This value should match an entry in /etc/odbc.ini
|
|
; (or /usr/local/etc/odbc.ini, on FreeBSD and similar systems).
|
|
dsn => asterisk
|
|
;
|
|
; Username for connecting to the database. The user defaults to the context name if unspecified.
|
|
;username => myuser
|
|
;
|
|
; Password for authenticating the user to the database. The default
|
|
; password is blank.
|
|
;password => mypass
|
|
;
|
|
; Build a connection at startup?
|
|
pre-connect => yes
|
|
;
|
|
; What should we execute to ensure that our connection is still alive? The
|
|
; statement should return a non-zero value in the first field of its first
|
|
; record. The default is "select 1".
|
|
;sanitysql => select 1
|
|
;
|
|
; The maximum number of connections to have open at any given time.
|
|
; This defaults to 1 and it is highly recommended to only set this higher
|
|
; if using a version of UnixODBC greater than 2.3.1.
|
|
;max_connections => 20
|
|
;
|
|
; When the channel is destroyed, should any uncommitted open transactions
|
|
; automatically be committed?
|
|
;forcecommit => no
|
|
;
|
|
; How should we perceive data in other transactions within the database?
|
|
; Possible values are read_uncommitted, read_committed, repeatable_read,
|
|
; and serializable. The default is read_committed.
|
|
;isolation => repeatable_read
|
|
;
|
|
; Is the backslash a native escape character? The default is yes, but for
|
|
; MS SQL Server, the answer is no.
|
|
;backslash_is_escape => yes
|
|
;
|
|
; How long (in seconds) should we attempt to connect before considering the
|
|
; connection dead? The default is 10 seconds, but you may wish to reduce it,
|
|
; to increase responsiveness.
|
|
;connect_timeout => 10
|
|
;
|
|
; When a connection fails, how long (in seconds) should we cache that
|
|
; information before we attempt another connection? This increases
|
|
; responsiveness, when a database resource is not working.
|
|
;negative_connection_cache => 300
|
|
;
|
|
; Enable query logging. This keeps track of the number of prepared queries
|
|
; and executed queries as well as the query that has taken the longest to
|
|
; execute. This can be useful for determining the latency with a database.
|
|
; The data can be viewed using the "odbc show" CLI command.
|
|
; Note that only successful queries are logged currently.
|
|
;logging => yes
|
|
;
|
|
; Slow query limit. If a query exceeds the given amount of time (in milliseconds)
|
|
; when executing then a WARNING message will be output to indicate that there
|
|
; may be a problem. Note that logging must be set to "yes" for this to occur. By
|
|
; default this is set to 5000 milliseconds (or 5 seconds). If you would like to
|
|
; disable the WARNING message it can be set to "0".
|
|
;slow_query_limit => 5000
|
|
;
|
|
; Set the type of connection cache. Historically res_odbc used a stack, resulting in
|
|
; a single connection being re-used frequently, whilst other connections could end up
|
|
; dying. Using a queue or round-robin strategy results in all connections being re-used
|
|
; and kept alive.
|
|
; Each strategy has pros and cons as debated on
|
|
; https://github.com/asterisk/asterisk/pull/1026. In summary, the stack results
|
|
; in a small number of connections remaining "hot" on the database side which
|
|
; could argumentatively maintain higher performance at the cost of longer-idle
|
|
; connections being timed out from the DB side, resulting in a short CPU spike on
|
|
; asterisk side when that "dead tail" is attempted to be used. The queue on the
|
|
; other hand will keep the load more spread over connections, resulting in them
|
|
; being kept active, avoiding the CPU spike on asterisk side to a much larger
|
|
; degree, at the cost of potentially keeping more connections (which could
|
|
; potentially be purged DB side) active.
|
|
; The default remains a stack to be backwards compatible, setting this value to
|
|
; any of rr, roundrobin or queue will result in a round-robin queue being used.
|
|
;cache_type => roundrobin
|
|
;
|
|
; Limit the number of connections to cache. This is separate from
|
|
; max_connections which is the total number of connections that open, whereas
|
|
; this value specifies how many idle connections will be stored in the connection
|
|
; cache. On extremely spiky loads this could be useful to limit the overall
|
|
; number of connections that's kept open when the spike comes down. The default
|
|
; is to not limit the cache size (thus effectively limit to max_connections).
|
|
; When a returned connection would result in the cache size being exceeded, the
|
|
; longest idle connection in the cache shall be dropped.
|
|
; Setting this to zero will effectively disable the connection cache, setting to -1
|
|
; will set this to "infinite" (default).
|
|
;cache_size => 10
|
|
|
|
[mysql2]
|
|
enabled => no
|
|
dsn => MySQL-asterisk
|
|
username => myuser
|
|
password => mypass
|
|
pre-connect => yes
|
|
|
|
; Certain servers, such as MS SQL Server and Sybase use the TDS protocol, which
|
|
; limits the number of active queries per connection to 1.
|
|
[sqlserver]
|
|
enabled => no
|
|
dsn => mickeysoft
|
|
max_connections => 5
|
|
username => oscar
|
|
password => thegrouch
|
|
pre-connect => yes
|
|
sanitysql => select count(*) from systables
|
|
; forcecommit => no ; Default to committing uncommitted transactions?
|
|
; Note: this is NOT the autocommit flag; this
|
|
; determines the end result of transactions which
|
|
; are not explicitly committed or rolled back. By
|
|
; default, such transactions are rolled back if the
|
|
; call ends without an explicit commit.
|
|
; isolation => read_committed ; Isolation level; supported levels are:
|
|
; read_uncommitted, read_committed, repeatable_read,
|
|
; serializable. Note that not all databases support
|
|
; all isolation levels (e.g. Postgres only supports
|
|
; repeatable_read and serializable). See database
|
|
; documentation for further information.
|
|
;
|
|
; Many databases have a default of '\' to escape special characters. MS SQL
|
|
; Server does not.
|
|
backslash_is_escape => no
|
|
|
|
;
|
|
; If you are having problems with concurrency, please read this note from the
|
|
; mailing lists, regarding UnixODBC:
|
|
;
|
|
; http://lists.digium.com/pipermail/asterisk-dev/2009-February/036539.html
|
|
;
|
|
; In summary, try setting "Threading=2" in the relevant section within your
|
|
; odbcinst.ini.
|
|
;
|