solidDB for MySQL 5.1 User Guide

solidDB for MySQL is a turbo-charged version of MySQL database that includes MySQL Server, solidDB Storage Engine and MyISAM storage engine. It also comes with an online backup capability that is included at no additional cost. It behaves like MySQL Server since it includes the same code and uses the same interface and drivers. It is fully transactional and scales well in multi-CPU environments so it is well suited to support large numbers of concurrent users and heavy transaction volumes. It is meant for OLTP workloads as opposed to data warehousing ones such as OLAP.

solidDB for MySQL is based on Solid's proven transactional product solidDB 6, which is a fully-featured relational database that is being used in products from companies including HP, Siemens, Nortel and NEC. solidDB for MySQL supports mission critical applications that require a high level of reliability and large transaction volumes. solidDB for MySQL is licensed under GNU GPL.

solidDB Storage Engine is a multi-threaded, transactional storage engine for MySQL Server. It is designed for mission-critical implementations that require a robust, transactional database able to fully leverage multi-processor environments to support heavy transaction volumes and a large number of concurrent users. solidDB Storage Engine supports full ACID compliance with configurable transaction isolation levels, both optimistic and pessimistic concurrency control, Multi-Version Concurrency Control (MVCC) with non-blocking reads and writes, row-level locking, and support for foreign keys and referential integrity.

In Release 5.0, solidDB Storage Engine is statically linked with MySQL Server 5.0.

In Release 5.1, which is currently available as Beta, solidDB Storage Engine supports dynamic linking with MySQL Server 5.1, in accordance with MySQL Server 5.1's Pluggable Storage Engine Architecture.

Contact information for Solid:

Web site: http://www.soliddb.com

Sales inquiries: <sales@soliddb.com>

Technical support: <techsupp@soliddb.com>

Marketing: <solidwebex@soliddb.com>

Offices

Americas

Asia Pacific

EMEA

solidDB for MySQL 5.1 is currently available as a Beta release on Linux only. solidDB Storage Engine supports dynamic linking with MySQL Server 5.1, in accordance with MySQL Server 5.1's Pluggable Storage Engine Architecture. In this release, solidDB Storage Engine and MySQL Server 5.1 Release Candidate (5.1.22) must be downloaded separately.

3.1 Installing solidDB for MySQL on a Linux Platform

solidDB for MySQL is delivered as a tar.gz package. Extract the package under a non-root user's home directory or to a directory of your choice. The commands are:

shell> tar zxvf solidmysql-<sw_version>-linux-i686-VERSION.tar.gz

shell> cd solidmysql-<sw_version>-linux-i686-VERSION

Copy libsoliddb.so to MySQL library directory

Comment all solidDB configuration parameters from the defaults file in use(.my.cnf).

mysqld --skip-innodb

mysql -u root mysql

Next, give the following SQL commands:

SQL> INSERT INTO plugin VALUES ('soliddb', 'libsoliddb.so');

SQL> commit;

SQL>exit;

Next, give the following command:

killall mysqld

Edit the ~/.my.cnf file to contain soliddb (uncomment options)

When you run mysqld_safe, you must define a configuration file for it by using the --defaults-file command line option. Define, for example, the support-files/my-soliddb.cnf as the configuration file.

shell> bin/mysqld_safe --default-storage-engine=solidDB --defaults-file=support-files/my-soliddb.cnf &

You can create a solidDB database (solid.db) in the data/ directory as shown here:

shell> cd bin

shell> mysql -u root

shell> create database solid;

shell> use solid;

	Note
	If you want to run mysqld as root, you must supply --user=<username> to mysql_install_db and mysqld_safe. In this case, the server is started as that user's process. If you are root and try to do this without the --user option, the server will fail to start.

This chapter explains how to compile solidDB for MySQL from source for the Linux platform.

	Important
	Before upgrading to MySQL 5.1, backup your database by using MySQL 5.0.

You can upgrade the MySQL database by using mysql_upgrade and it should be executed each time you upgrade MySQL. It checks all tables in all databases for incompatibilities with the current version of MySQL Server see (http://dev.mysql.com/doc/refman/5.1/en/mysql-upgrade.html). solidDB for MySQL files do not need any additional upgrade procedure.

	Note
	You must use the same configuration of database files and block sizes in MySQL 5.1 as you used in MySQL 5.0.

To upgrade the MySQL database, proceed as follows:

	Important
	Backup your database before upgrading.

You can upgrade the MySQL database by using mysql_upgrade and it should be executed each time you upgrade MySQL. It checks all tables in all databases for incompatibilities with the current version of MySQL Server see (http://dev.mysql.com/doc/refman/5.1/en/mysql-upgrade.html). solidDB for MySQL files do not need any additional upgrade procedure.

	Note
	You must use the same configuration of database files and block sizes in MySQL 5.1 as you used in MySQL 5.0.

To upgrade the MySQL database, proceed as follows:

The solidDB Storage Engine is enabled by default. If you do not want to use solidDB tables, you can add the skip-soliddb option to your MySQL option file.

This section contains representative examples of solidDB configuration parameters. Refer to Chapter 9, solidDB for MySQL Startup Options and System Variables for additional information about solidDB-related configuration parameters.

To set up the solidDB database files, use the soliddb_filespec option in the [mysqld] section of the .my.cnf option file. The value of soliddb_filespec should be a list of one or more database file specifications. If you name more than one data file, separate them by comma (“,”) characters:

soliddb_filespec=database_file[,database_file2]...

For example,

[mysqld]
soliddb_filespec=soliddb1 10M
    

This setting configures a single 10MB database file named soliddb1. No location for the database file is given. By default, solidDB creates it in the MySQL data directory. The full syntax for a database file specification includes the filename and the file-size:

file_name file_size

solidDB creates tablespace files in the MySQL data directory by default. To specify a location explicitly, use the soliddb_filespec option with a path. For example, to use two files named soliddb1 and soliddb2 but create them in the /soliddb directory, configure solidDB like this:

[mysqld]
soliddb_filespec=/soliddb/soliddb1 10M,/soliddb/soliddb2 20M
  

For more information on file management, see Chapter 28, solidDB File Space Management and Disk I/O.

If you want to tune other mysqld and solidDB parameters, the following values are typical and would suit most users:

[mysqld]
skip-external-locking
max_connections=1024
read_buffer_size=1M
sort_buffer_size=1M
#
# If you are using solidDB tables only, set key_buffer_size to 5%
# of main memory. If you have large MyISAM tables, divide the main
# memory between solidDB and MyISAM. You can do this by estimating
# the number of rows on MyISAM tables and solidDB tables and calculating
# rows_in_myisam / (rows_in_myisam + rows_in_soliddb) and then using
# this information to set your key_buffer_size and soliddb_cache_size.
# Remember that the total size should be < 80% of system main memory.
key_buffer_size=value
#
# Set the cache size to 70-80% of your ram
#
#
soliddb_cache_size=value
#
# Set durability to strict
#
set-variable = soliddb_durability_level=3

This chapter explains basic tasks needed to start solidDB for MySQL.

mysqld_safe --mysqld=<mysql-server-name> --default-storage-engine=solidDB

8.2 Opening the MySQL Query Tool

	Note
	These instructions are for the command-line query tool, not for MySQL Query Browser.

You can start the query tool from the Linux prompt as follows:

shell> mysql -u root

This section describes the command-line options and system variables for solidDB for MySQL. System variables have two possible states: they are either true or false. System variables can be enabled at server startup by naming them, or disabled by using a skip- prefix. For example, to enable or disable deleting solidDB transaction log files after each successful checkpoint, you can use --soliddb_checkpoint_deletelog or --skip-soliddb_checkpoint_deletelog on the command line, or soliddb_checkpoint_deletelog or skip-soliddb_checkpoint_deleletelog in an option file.

System variables that take a numeric value can be specified as --var_name=value on the command line or as var_name=value in option files.

Data dictionary is a file that defines the basic organization of a database. A data dictionary contains a list of all files in the database, the number of records in each file, and the names and types of each field.

install plugin SOLIDDB_SYS_TABLES soname 'libsoliddb.so';
install plugin SOLIDDB_SYS_COLUMNS soname 'libsoliddb.so';
install plugin SOLIDDB_SYS_COLUMNS_AUX soname 'libsoliddb.so';
install plugin SOLIDDB_SYS_KEYS soname 'libsoliddb.so';
install plugin SOLIDDB_SYS_KEYPARTS soname 'libsoliddb.so';
install plugin SOLIDDB_SYS_KEYPARTS_AUX soname 'libsoliddb.so';
install plugin SOLIDDB_SYS_FORKEYS soname 'libsoliddb.so';
install plugin SOLIDDB_SYS_FORKEYPARTS soname 'libsoliddb.so';
install plugin SOLIDDB_SYS_SCHEMAS soname 'libsoliddb.so';
install plugin SOLIDDB_SYS_SEQUENCES soname 'libsoliddb.so';
install plugin SOLIDDB_SYS_CARDINAL soname 'libsoliddb.so';
install plugin SOLIDDB_SYS_TABLEMODES soname 'libsoliddb.so';
install plugin SOLIDDB_SYS_COLLATIONS soname 'libsoliddb.so';
install plugin SOLIDDB_SYS_INFO soname 'libsoliddb.so';
install plugin SOLIDDB_SYS_BLOBS soname 'libsoliddb.so';

uninstall plugin SOLIDDB_SYS_TABLES;
uninstall plugin SOLIDDB_SYS_COLUMNS;
uninstall plugin SOLIDDB_SYS_COLUMNS_AUX;
uninstall plugin SOLIDDB_SYS_KEYS;
uninstall plugin SOLIDDB_SYS_KEYPARTS;
uninstall plugin SOLIDDB_SYS_KEYPARTS_AUX;
uninstall plugin SOLIDDB_SYS_FORKEYS;
uninstall plugin SOLIDDB_SYS_FORKEYPARTS;
uninstall plugin SOLIDDB_SYS_SCHEMAS;
uninstall plugin SOLIDDB_SYS_SEQUENCES;
uninstall plugin SOLIDDB_SYS_CARDINAL;
uninstall plugin SOLIDDB_SYS_TABLEMODES;
uninstall plugin SOLIDDB_SYS_COLLATIONS;
uninstall plugin SOLIDDB_SYS_INFO;
uninstall plugin SOLIDDB_SYS_BLOBS;
    

10.4 Accessing solidDB Data Dictionary

solidDB data dictionary stores server information. Your ability to access specific system tables depends on your user access rights. For example, Database Administrators (DBA) can view all information on the data dictionary. solidDB data dictionary contains the following tables:

Table	Description
SOLIDDB_SYS_TABLES	This table includes information about tables. See also Section 10.5.2, “SOLIDDB_SYS_TABLES”.
SOLIDDB_SYS_COLUMNS	This table includes information about columns. See also Section 10.5.3, “SOLIDDB_SYS_COLUMNS”.
SOLIDDB_SYS_COLUMNS_AUX	This table includes information about columns default values. See also Section 10.5.4, “SOLIDDB_SYS_COLUMNS_AUX”.
SOLIDDB_SYS_KEYS	This table includes information about keys. See also Section 10.5.5, “SOLIDDB_SYS_KEYS”.
SOLIDDB_SYS_KEYPARTS	This table includes information about key attributes. See also Section 10.5.6, “SOLIDDB_SYS_KEYPARTS”.
SOLIDDB_SYS_KEYPARTS_AUX	This table includes information about the directory prefix length. See also Section 10.5.7, “SOLIDDB_SYS_KEYPARTS_AUX”.
SOLIDDB_SYS_FORKEYS	This table includes information about foreign keys. See also Section 10.5.8, “SOLIDDB_SYS_FORKEYS”.
SOLIDDB_SYS_FORKEYPARTS	This table includes information about foreign key attributes. See also Section 10.5.9, “SOLIDDB_SYS_FORKEYPARTS”.
SOLIDDB_SYS_SCHEMAS	This table includes information about schemas (databases). See also Section 10.5.10, “SOLIDDB_SYS_SCHEMAS”.
SOLIDDB_SYS_SEQUENCES	This table includes information about sequences (autoincrement fields are implemented using sequences). See also Section 10.5.11, “SOLIDDB_SYS_SEQUENCES”.
SOLIDDB_SYS_BLOBS	This table includes information about the blobs stored into the database. Furthermore, this table sees to it that the BLOB is physically saved on disk once only even if it is logically saved several times. See also Section 10.5.12, “SOLIDDB_SYS_BLOBS”.
SOLIDDB_SYS_CARDINAL	This table includes information about the number of rows in the table and the size of the data in the table. See also Section 10.5.13, “SOLIDDB_SYS_CARDINAL”.
SOLIDDB_SYS_INFO	This table includes system information. See also Section 10.5.14, “SOLIDDB_SYS_INFO”.
SOLIDDB_SYS_TABLEMODES	This table shows the table mode of the tables whose table mode was explicitly set. It does not show the mode of tables that were left at the default mode (pessimistic). See also Section 10.5.15, “SOLIDDB_SYS_TABLEMODES”.
SOLIDDB_SYS_COLLATIONS	This table contains information on the supported charsets and collations. See also Section 10.5.16, “SOLIDDB_SYS_COLLATIONS”.

For example, if you have created a solidDB table t01 using MySQL client as follows:

mysql> use test;

Database changed
    

mysql> create table t01(a int not null, primary key(a)) engine=soliddb;

Query OK, 0 rows affected (0.73 sec)
    

Assuming that you have installed solidDB data dictionary to database soliddb, you can see a description of all solidDB tables by issuing the following command in the MySQL client interface:

mysql> select * from soliddb.SOLIDDB_SYS_TABLES;

+-------+-------------------------+------------+--------------+
| ID    | TABLE_NAME              | TABLE_TYPE | TABLE_SCHEMA |
+-------+-------------------------+------------+--------------+
|   100 | SYS_TABLES              | BASE TABLE | _SYSTEM      |
|   200 | SYS_COLUMNS             | BASE TABLE | _SYSTEM      |
|   400 | SYS_UROLE               | BASE TABLE | _SYSTEM      |
|   500 | SYS_RELAUTH             | BASE TABLE | _SYSTEM      |
|   600 | SYS_ATTAUTH             | BASE TABLE | _SYSTEM      |
|   700 | SYS_VIEWS               | BASE TABLE | _SYSTEM      |
|   800 | SYS_KEYPARTS            | BASE TABLE | _SYSTEM      |
|   900 | SYS_KEYS                | BASE TABLE | _SYSTEM      |
|  1000 | SYS_CARDINAL            | BASE TABLE | _SYSTEM      |
|  1100 | SYS_INFO                | BASE TABLE | _SYSTEM      |
|  1300 | SYS_SYNONYM             | BASE TABLE | _SYSTEM      |
|  8000 | SYS_USERS               | BASE TABLE | _SYSTEM      |
|  8002 | SQL_LANGUAGES           | BASE TABLE | _SYSTEM      |
|  8004 | SYS_TYPES               | BASE TABLE | _SYSTEM      |
|  8006 | SYS_BLOBS               | BASE TABLE | _SYSTEM      |
|  8010 | SYS_FORKEYS             | BASE TABLE | _SYSTEM      |
|  8013 | SYS_FORKEYPARTS         | BASE TABLE | _SYSTEM      |
|  8015 | SYS_CHECKSTRINGS        | BASE TABLE | _SYSTEM      |
|  8017 | SYS_PROCEDURES          | BASE TABLE | _SYSTEM      |
|  8020 | SYS_TRIGGERS            | BASE TABLE | _SYSTEM      |
|  8024 | SYS_TABLEMODES          | BASE TABLE | _SYSTEM      |
|  8026 | SYS_EVENTS              | BASE TABLE | _SYSTEM      |
|  8029 | SYS_CATALOGS            | BASE TABLE | _SYSTEM      |
|  8032 | SYS_SCHEMAS             | BASE TABLE | _SYSTEM      |
|  8035 | SYS_SEQUENCES           | BASE TABLE | _SYSTEM      |
|  8038 | SYS_PROPERTIES          | BASE TABLE | _SYSTEM      |
|  8040 | SYS_HOTSTANDBY          | BASE TABLE | _SYSTEM      |
|  8043 | SYS_COLUMNS_AUX         | BASE TABLE | _SYSTEM      |
|  8045 | SYS_COLLATIONS          | BASE TABLE | _SYSTEM      |
| 10000 | SOLIDDB_SYS_TABLES      | BASE TABLE | soliddb      |
| 10002 | SOLIDDB_SYS_COLUMNS     | BASE TABLE | soliddb      |
| 10002 | SOLIDDB_SYS_COLUMNS_AUX | BASE TABLE | soliddb      |
| 10004 | SOLIDDB_SYS_KEYS        | BASE TABLE | soliddb      |
| 10006 | SOLIDDB_SYS_KEYPARTS    | BASE TABLE | soliddb      |
| 10007 | SOLIDDB_SYS_KEYPARTS_AUX| BASE TABLE | soliddb      |
| 10008 | SOLIDDB_SYS_FORKEYS     | BASE TABLE | soliddb      |
| 10010 | SOLIDDB_SYS_FORKEYPARTS | BASE TABLE | soliddb      |
| 10012 | SOLIDDB_SYS_SCHEMAS     | BASE TABLE | soliddb      |
| 10014 | SOLIDDB_SYS_SEQUENCES   | BASE TABLE | soliddb      |
| 10017 | SOLIDDB_SYS_BLOBS       | BASE TABLE | soliddb      |
| 10019 | SOLIDDB_SYS_CARDINAL    | BASE TABLE | soliddb      |
| 10021 | SOLIDDB_SYS_INFO        | BASE TABLE | soliddb      |
| 10023 | SOLIDDB_SYS_TABLEMODES  | BASE TABLE | soliddb      |
| 10025 | SOLIDDB_ADMIN_COMMANDS  | BASE TABLE | soliddb      |
| 10025 | SOLIDDB_SYS_COLLATIONS  | BASE TABLE | soliddb      |
+-------+-------------------------+------------+--------------+
48 rows in set (0.02 sec)
    

	Note
	All tables beginning with SYS_ or SQL_ are solidDB internal tables and cannot be accessed from the MySQL client.

To create a solidDB table, specify the ENGINE = solidDB option in the CREATE TABLE statement:

CREATE TABLE customers (a INT, b CHAR (20), INDEX (a)) ENGINE=solidDB;

The statement mentioned previously creates a table and an index on column a in the solidDB database that consists of the data files that you specified in the .my.cnf file. In addition, solidDB for MySQL creates a customers.frm file in the test directory under the MySQL database directory. Internally, solidDB for MySQL adds an entry for the table to its own data dictionary. The entry includes the database name. For example, if you have a database named test, and you create a table called customers in it, the entry is for 'test/customers'. This means you can create a table of the same name (customers) in another database, and the table names do not collide inside solidDB for MySQL.

You can specify the table type, optimistic or pessimistic, when you create the table. For more information on table modes, see Chapter 21, Concurrency Control. To create an optimistic table, you can use, for example, the command below:

CREATE TABLE customers (a INT, b CHAR (20), INDEX (a)) ENGINE=solidDB COMMENT='MODE=OPTIMISTIC';

To create a pessimistic table, you can use, for example, the command below:

CREATE TABLE customers (a INT, b CHAR (20), INDEX (a)) ENGINE=solidDB COMMENT='MODE=PESSIMISTIC';

If you specify no table type, the default value PESSIMISTIC is used.

If you want all your (non-system) tables to be created as solidDB tables, you can simply add the line default-storage-engine=soliddb to the [mysqld] section of your server option file.

You can check the table type for an existing table by two methods:

A character set is a set of symbols and encodings. A collation is a set of rules for comparing characters in a character set.

Here is an example of an imaginary character set:

Let's assume that have an alphabet with four letters: 'A', 'B', 'a', 'b'. We match each letter with a number: 'A' = 0, 'B' = 1, 'a' = 2, 'b' = 3. The letter 'A' is a symbol, the number 0 is the encoding for 'A', and the combination of all four letters and their encodings is a character set. Now we want to compare two string values, 'A' and 'B', for example. We can do this by looking at the encodings: 0 for 'A' and 1 for 'B'. Since 0 is less than 1, we conclude that 'A' is less than 'B'.

solidDB for MySQL 5.1 only supports a limited number of collations and character sets. The number of supported collations and character sets will be extended in the following releases.

By default, solidDB for MySQL 5.1 uses the latin1 character set and the latin1_swedish_c1 collation.

The available character sets can be printed by using the SHOW CHARACTER SET statement:

mysql> SHOW CHARACTER SET;

	Note
	If you use the \g option in the SHOW CHARACTER SET statement to show collations, do not use the semicolon at the end of the statement. For example: mysql> SHOW CHARACTER SET tl \g

Available collations in MySQL can be printed by using the SHOW COLLATION statement:

mysql> SHOW COLLATION;

Note that this printout includes all collations and character sets that are supported by MySQL. solidDB for MySQL 5.1 does not support all these yet. For more information about collations and which collations MySQL supports, please refer to MySQL User Guide Chapter 10.

solidDB for MySQL 5.1 currently supports part of the latin1, utf8, ucs2, cp932 and eucjpms character sets with the following collations. The table is sorted by charset and the collations within each charset are in alphabetical order.

If the solidDB system tables are installed, the supported collations in solidDB for MySQL can be printed by selecting the contents of the SOLIDDB_SYS_COLLATIONS table:

mysql> select ID, CHARSET_NAME, COLLATION_NAME FROM SOLIDDB_SYS_COLLATIONS order by ID;

If the solidDB system tables are installed, the supported charsets in solidDB for MySQL can be printed by selecting the CHARSET_NAME from SOLIDDB_SYS_COLLATIONS table:

mysql> mysql> select distinct CHARSET_NAME from SOLIDDB_SYS_COLLATIONS;

The supported charsets are:

+--------------+
| CHARSET_NAME |
+--------------+
| latin1       | 
| utf8         | 
| ucs2         | 
| binary       | 
| cp932        | 
| eucjpms      | 
+--------------+
    

where:

There are a number of known issues with solidDB tables in this release. Solid is already working to address the most serious of these. Known issues:

Some solidDB system variables are dynamic and can be set at runtime using SET GLOBAL. You can also obtain their values using SELECT. See Using System Variables in MySQL documentation for more information.

The following chapters describe the dynamic solidDB system variables. The options that can be set with the SET statement are also included. Section SET Syntax discusses these options.

Variables that have a type of 'string' take a string value. Variables that have a type of 'numeric' take a numeric value.

Consider, for example, a situation where your database has reached the maximum size specified by soliddb_filespec. You can add a new database file dynamically using a MySQL client as follows:

shell> mysql
shell> SET GLOBAL soliddb_filespec='solid5.db 1G';
shell> exit;

You can only add one database file at a time. If you need to add more than one database file, you must set soliddb_filespec several times.

In relational databases, it is common for records in one relation to reference records in the same or other relations. The requirement that the referenced records must exist is called referential integrity. References can be made to link information together and it is an essential part of database normalization. One important type of referential integrity is the foreign key constraint.

A foreign key is a referential constraint between two tables in the database. The foreign key identifies a column or a set of columns in one (referencing) table that refers to a column or set of columns in another (referenced) table. The columns in the referenced table must form a primary key or unique key. The values in one row of the referencing columns must occur in a single row in the referenced table. Thus, a row in the referencing table cannot contain values that do not exist in the referenced table. Multiple rows in the referencing table may refer to the same row in the referenced table.

The referencing and referenced table may be the same table, that is, the foreign key refers back to the same table. Such a foreign key is known in SQL:2003 as a self-referencing or recursive foreign key. A table may have multiple foreign keys, and each foreign key may have a different referenced table. Each foreign key is independently forced by the database system. Therefore, cascading relationships between tables can be documented by using foreign keys.

Foreign keys are defined in the ANSI SQL Standard, by using a FOREIGN KEY constraint. The syntax to add such a constraint to an existing table is defined in SQL:2003. Leaving out the column list in the REFERENCES clause means that the foreign key references the primary key of the referenced table.

solidDB for MySQL supports foreign key constraints. solidDB uses the MySQL parser for foreign key definitions. See FOREIGN KEY Constraints in the MySQL 5.1 Reference Manual for more information on foreign keys and Using Foreign Keys in the MySQL 5.1 Reference Manual for more information on how to use foreign keys. Foreign key syntax can be found in CREATE TABLE Syntax and in ALTER TABLE Syntax.

	Note
	This version of solidDB for MySQL does not support the MATCH option.

solidDB for MySQL requires that both the referencing table and referenced tables are solidDB tables. Additionally, solidDB requires indexes on foreign keys and referenced keys so that foreign key checks can be fast and not require a table scan. The index on the foreign key is automatically created. Corresponding columns in the foreign key and the referenced key must have similar internal data types inside solidDB so that they can be compared without a type conversion. The size and sign of integer types must be the same. The length of string types need not be the same. If you specify a SET NULL action, make sure that you have not declared the columns in the child table as NOT NULL.

The default referential action is ON UPDATE RESTRICT and ON DELETE RESTRICT unless the ON UPDATE and ON DELETE attributes are separately given. Here is an example of creating tables using foreign keys:

CREATE TABLE t1 (id INT NOT NULL, PRIMARY KEY (id)) ENGINE=SOLIDDB;

CREATE TABLE t2 (id INT PRIMARY KEY, t1_id INT NOT NULL, 
FOREIGN KEY fkey(t1_id) REFERENCES t1(id) ON DELETE CASCADE)
ENGINE=SOLIDDB;

If you attempt to insert a row to table t2 with a value that does not exist in the parent table t1, you get an error message:

mysql> insert into t2 values (0, 0);
ERROR 1452 (23000): Cannot add or update a child row: a foreign key
constraint fails (CONSTRAINT 'fkey' FOREIGN KEY ('t1_id') REFERENCES 
't1' ('id') ON DELETE CASCADE ON UPDATE RESTRICT)

You must define tables in such an order that all referenced tables are created before the tables referencing them. If MySQL reports an error number 1005 from a CREATE TABLE statement, and the error message refers to error number 155, then the table creation has failed because a foreign key constraint was not correctly formed. Similarly, if an ALTER TABLE fails and it refers to error number 155, then the table alteration has failed because a foreign key constraint was incorrectly formed for the altered table.

mysql> CREATE TABLE t3 (id INT PRIMARY KEY, t1_id INT, INDEX par_ind
(t1_id), FOREIGN KEY (t1_id) REFERENCES t4(id) ON DELETE CASCADE)
ENGINE=SOLIDDB;

ERROR 1005 (HY000): Can't create table './test/t3.frm' (errno: 155)

You can also see an error message in the server log:

SOLID Table Error 13011: Table t4 does not exist

See below for a more complex example, in which a product_order table has foreign keys for two other tables. One foreign key references a two-column index in the product table. The other references a single-column index in the customer table:

create table customer(customer_id int not null, customer_name
varchar(80), primary key(customer_id)) engine=soliddb;

create table product(product_id int not null, product_price int,
primary key(product_id)) engine=soliddb;

create table product_order(order_id int not null, customer_id int not
null, product_id int not null, number_of_products int,  primary
key(order_id), foreign key (customer_id) references
customer(customer_id), foreign key (product_id) references
product(product_id)) engine=soliddb;

Additionally, the foreign key can reference the same table:

create table t1(a int not null, b int not null, d int, primary key(a),
foreign key (b) references t1(a) on update no action on delete no
action) engine=soliddb;

create table t6(a int not null,
b int not null,
primary key(a),
foreign key ger (b) references t1(a)
on update set default on delete
set default) engine=soliddb;

ERROR 1005 (HY000): Can't create
table './test/t6.frm' (errno: 142)
                  

070313  9:30:13 [ERROR] This version
of MySQL/solidDB does not support
SET_DEFAULT option on referential actions.
              

Normally, when a transaction is committed, the database server writes data to two locations: the database file, and the transaction log file. However, the data are not necessarily written to those two locations at the same time. When a transaction is committed, the server writes the data to the transaction log file immediately, that is, as soon as the server commits the transaction. However, the server does not necessarily write the data to the database file immediately. The server may wait until it is less busy, or until it has accumulated multiple changes, before writing the data to the database file.

If the server shuts down abnormally (due to a power failure, for example) before all data have been written to the database file, the server can recover 100% of committed data by reading the combination of the database file and the transaction log file. Any changes since the last write to the database file are in the transaction log file. The server can read those changes from the log file and then use that information to update the database file. The process of reading changes from the log file and updating the database file is called “recovery”. At the end of the recovery process, the database file is 100% up to date.

The recovery process is automatically executed any time that the server restarts after an abnormal shutdown. The process is generally invisible to the user (except that there may be a delay before the server is ready to respond to new requests). Not surprisingly, to have a 100% recovery, you must have 100% of the transactions written to the log file. Normally, the database server writes data to the log file at the same time that the server commits the data. Thus committed transactions are stored on disk and will not be lost if the computer is shut down abnormally. This is called “strict durability”. The data that have been committed are “durable”, even if the server is shut down abnormally.

If durability is “strict”, data are written to the disk drive at the time that the data are committed. The user is not told that his data have been committed until the data were successfully written to the transaction log on disk. This ensures that the data are recoverable if the server shuts down abnormally, for example, due to a power failure. Strict durability makes it almost impossible to lose data unless the hard disk drive itself fails. If durability is “relaxed”, the user may be told that the data have been committed even before the data have been written to the transaction log on disk. The server may choose to delay writing the data by, for example, waiting until there are several transactions to write. If durability is relaxed, the server may lose a few committed transactions if there is a power failure before the data are written to disk.

Historically, the goal of most database servers has been to maximize safety, that is, to make sure that data are not lost due to a power failure or other problems. These database servers use “strict durability”. This approach is appropriate for many types of data, such as accounting data, where it is often unacceptable to lose track of even a single transaction. Some database servers have been designed to maximize performance, without regard to safety. This is acceptable in situations where, for example, you only need to sample data, or where the server can simply operate on the most recent set of data, regardless of the size of that set.

Suppose, for example, that you have a server containing statistical data about performance, for instance which computers experience the heaviest loads at particular times of the day. You might use such information to balance the load on your computers. This information changes over time, and “old” data are less valuable than “new” data. In fact, you might completely discard any data that are more than a week old. If you were to lose the performance and load balancing data, then your system would still function, and within a week you would have acquired a complete set of new data (assuming that you normally discard data older than one week). In this situation, occasional or small data loss is acceptable, and performance may be more important. solidDB allows you to specify whether you want logging to be “strict” (that is, to guarantee that all committed data can be recovered after an unexpected shutdown) or “relaxed” (that is, to allow some recent transactions to be lost in some circumstances).

You can increase performance by instructing the server that it does not necessarily have to write to the log file at the same time that it commits data. This allows the server to write to the log file later, perhaps when the server is less busy, or when several transactions can be written at once. This is called “relaxed durability”. It increases performance by decreasing the I/O load. If you set the transaction durability level to “relaxed”, you risk losing some data if the server shuts down abnormally after it has committed some data but before it has written those data to the transaction log. Therefore, you should use relaxed durability only when you can afford to lose a small amount of recent data.

If you can afford to lose a small amount of recent data, and if performance is crucial to you, then you may want to use relaxed durability. Relaxed durability is appropriate when each individual transaction is not crucial. For example, if you are monitoring system performance and you want to store data on response times, you may only be interested in average response times, which will not be significantly affected if you are missing a few pieces of data.

In fact, since measuring performance will itself affect performance (by using up resources such as Central Processing Unit (CPU) time and I/O bandwidth), you probably want your performance tracking operations themselves to have high performance (low cost) rather than high precision. Relaxed durability is appropriate in this situation. On the other hand, if you are tracking financial data, such as bill payments, then you probably want to ensure that 100% of your committed data are stored and recoverable. In this situation, you will want strict durability. You should use relaxed durability only when you can afford to lose a few of the most recent transactions. Otherwise, use strict durability. If you are not sure whether strict or relaxed durability is appropriate use strict durability.

If you specify an AUTO_INCREMENT column for a solidDB table, the table handle in the solidDB data dictionary contains a special sequence object called the “auto-increment sequence object” that is used in assigning new values for the column. This auto-increment sequence object is stored to disk.

If a user does not explicitly specify a value for an AUTO_INCREMENT column, solidDB increments the counter by one and assigns the new value to the column. If the user inserts a row that explicitly specifies the column value, and the value is bigger than the current counter value, the counter is set to the specified column value.

You may see gaps in the sequence of values assigned to the AUTO_INCREMENT column if you roll back transactions that have generated numbers using the counter.

If a user specifies NULL or 0 for the AUTO_INCREMENT column in an INSERT, solidDB treats the row as if the value had not been specified and generates a new value for it.

The behavior of the auto-increment mechanism is not defined if a user assigns a negative value to the column or if the value becomes bigger than the maximum integer that can be stored in the specified integer type.

solidDB supports the AUTO_INCREMENT = N table option in CREATE TABLE and ALTER TABLE statements, to set the initial counter value or alter the current counter value.

In terms of the SQL:1992 transaction isolation levels, the solidDB default is REPEATABLE READ. solidDB offers all four transaction isolation levels described by the SQL standard. You can set the default isolation level for all sessions by using the --transaction-isolation option on the command line or in an option file. For example, you can set the option in the [mysqld] section of an option file like this:

[mysqld]
transaction-isolation = {READ-UNCOMMITTED | READ-COMMITTED
                        | REPEATABLE-READ | SERIALIZABLE}

A user can change the isolation level for a single session or for all new incoming connections with the SET TRANSACTION statement. Its syntax is as follows:

SET [SESSION | GLOBAL] TRANSACTION ISOLATION LEVEL
                       {READ UNCOMMITTED | READ COMMITTED
                       | REPEATABLE READ | SERIALIZABLE}

	Note
	There are hyphens in the level names for the --transaction-isolation option, but not for the SET TRANSACTION statement.

The default behavior is to set the isolation level for the next (not started) transaction. If you use the GLOBAL keyword, the statement sets the default transaction level globally for all new sessions created from that point on (but not for existing sessions). You need the SUPER privilege to do this. Using the SESSION keyword sets the default transaction level for all future transactions performed on the current session.

Any client is free to change the session isolation level (even in the middle of a transaction), or the isolation level for the next transaction.

You can determine the global and session transaction isolation levels by checking the value of the tx_isolation system variable with these statements:

SELECT @@global.tx_isolation;

SELECT @@tx_isolation;

There are different areas in solidDB that can result in performance degradation. In order to remedy performance problems, you need to determine the underlying cause. A bit later on you can find a table that lists common symptoms of poor performance, possible causes, and directs you to the solution.

This chapter explains how to produce performance statistics output.

A pmon process is started by giving the command below:

mysql> SET GLOBAL soliddb_admin_command='pmon diff start soliddbpmon.out 1000';

Where soliddbpmon.out is the filename where the output is created and 1000 is the interval in milliseconds.

You can also append an existing file with command:

mysql> SET GLOBAL soliddb_admin_command='pmon diff start soliddbpmon.out 1000 append';

A pmon is stopped by giving the command below:

mysql> SET GLOBAL soliddb_admin_command='pmon diff stop';

You can import the pmon output file fx. to MS Excel (or other suitable tool) for further analysis or to send it to technical support.

For more information, please refer to solidDB Administrator Guide section Detailed DBMS Monitoring and Troubleshooting.

solidDB offers two different types of concurrency control mechanisms, which are known as "pessimistic" and "optimistic". We explain both methods in the following chapters. By default, solidDB uses "pessimistic" concurrency control.

create table t2(a int not null) engine=soliddb
comment='MODE=PESSIMISTIC';
insert into t2 values (1),(2);
commit;
set autocommit = 0;
update t2 set a = 5 where a = 1;
    

set autocommit = 0;
update t2 set a = 7 where a = 1;
/* This query waits for T1 to release locks on table t2 */
    

ERROR 1213 (40001): Deadlock found when trying to
get lock; try restarting transaction
    

commit;
    

21.2 Optimistic Concurrency Control

An alternative approach to locking is called "optimistic" concurrency control. Optimistic concurrency control assumes that although conflicts are possible, they will be very rare. Instead of locking every record every time that it is used, the software merely looks for indications that two users actually did try to update the same record at the same time. If that evidence is found, then one user's updates are discarded (and of course the user is informed).

When using optimistic concurrency control, each time that the server reads a record to try to update it, the server makes a copy of the "version number" of the record and stores that copy for later reference. When it's time to write the updated data back to the disk drive, the server compares the original version number that it read with the version number that the disk drive now contains. If the version numbers are the same, then no one else changed the record and we can write our updated value. However, if the value we originally read and the current value on the disk are not the same, then someone has changed the data since we read it, and whatever operation we did is probably out-of-date, so we discard our version of the data and give the user an error message. Naturally, each time that we update a record, we also update the version number.

	Note
	If you want created tables to be optimistic by default, use the --soliddb_pessimistic = 0 configuration option.

Here is an example of optimistic concurrency control operation:

On T1, enter the statements below:

create table t2(a int not null) engine=soliddb
comment='MODE=OPTIMISTIC';
insert into t2 values (1),(2);
commit;
set autocommit = 0;
update t2 set a = 5 where a = 1;
    

on T2, enter the statements below:

set autocommit = 0;
update t2 set a = 7 where a = 1;
    

On T2, you can see:

ERROR 1213 (40001): Deadlock found when trying to
get lock; try restarting transaction
    

Multiversioning in solidDB is implemented with a feature called Bonsai Tree. Bonsai Tree is a small active “index” (data storage tree) that efficiently stores new data (deletes, inserts, updates) in central memory, while maintaining multiversion information. Multiple versions of a row (old and new) can co-exist in Bonsai Tree. Both the old and new data are used for concurrency control and for ensuring consistent read levels for all transactions without any locking overhead. With Bonsai Tree, the effort needed for concurrency control is significantly reduced.

When a transaction is started, it is given a sequential Transaction Start Number (TSN). The TSN is used as the “read level” of the transaction; all key values inserted later into the database from other sessions are not visible to searches within the current transaction. This offers consistent index read levels that appear as if the read operation was performed atomically at the time the transaction was started. This guarantees that read operations are presented with a consistent view of the data without the need for locks, which have higher overhead.

Old versions of rows (and the newer version(s) of those same rows) are kept in Bonsai Tree for as long as there are transactions that need to see those old versions. After the completion of all transactions that reference the old versions, the “old” versions of the data are discarded from Bonsai tree, and new committed data are moved from Bonsai Tree to the main storage tree. The presorted key values are merged as a background operation concurrently with normal database operations. This offers significant I/O optimization and load balancing. During the merge, the deleted key values are physically removed.

In solidDB, the main data structure used to store data, including tables and indexes, is a B-tree variation. The server uses two of these structures;

solidDB collects performance statistics from the server. The statistics contain information about the solidDB internal state. You can use the SHOW ENGINE SOLIDDB STATUS SQL statement at any time to fetch the output of the performance statistics to your SQL client. See below for a command example:

mysql> SHOW ENGINE SOLIDDB STATUS\G

The performance statistics output includes the following information:

Example of the statistics output:

mysql> show engine soliddb status;
+-------------------------------------------------------------------+
| Status                                                            |
|                                                                   |
+-------------------------------------------------------------------+
| Memory size:
    534535 kilobytes
Transaction count statistics:
    Commit Abort Rollback    Total Read-only  Trxbuf  Active Validate
        40     0        8       48        47       0       1        0
Cache count statistics:
    Hit rate      Find      Read     Write
    94.4          1171      66        0        
Database statistics:
    Index writes            3  After last merge      0
    Log writes              0  After last cp         0
    Active searches         0  Average               2
    Database size    3392064 kilobytes
    Log size         1531904 kilobytes
|
+-------------------------------------------------------------------+
1 row in set (0.00 sec)

solidDB for MySQL maintains many status variables that provide information about its operation and performance. You can view these variables and their values by using the SHOW [GLOBAL] STATUS statement. For more information about MySQL server status variables see Status Variables. See also Chapter 24, solidDB Status.

See below for an example on how to retrieve status variables in solidDB for MySQL:

mysql> SHOW STATUS LIKE 'solidDB%';
+----------------------------------------+---------------------+
| Variable_name                          | Value               |
+----------------------------------------+---------------------+
| solidDB_memory_size                    | 606386              | 
| solidDB_transaction_commits            | 77                  | 
| solidDB_transaction_rollbacks          | 0                   | 
| solidDB_transaction_aborts             | 8                   | 
| solidDB_transaction_total              | 85                  | 
| solidDB_transaction_readonly           | 84                  | 
| solidDB_transaction_trxbuf             | 0                   | 
| solidDB_transaction_activecnt          | 1                   | 
| solidDB_transaction_validatecnt        | 0                   | 
| solidDB_cache_hit_rate                 | 99                  | 
| solidDB_cache_finds                    | 3821                | 
| solidDB_cache_reads                    | 25                  | 
| solidDB_cache_writes                   | 0                   | 
| solidDB_indexmerge_active              | OFF                 | 
| solidDB_index_writes                   | 3                   | 
| solidDB_index_writes_after_merge       | 0                   | 
| solidDB_log_writes                     | 0                   | 
| solidDB_log_writes_after_cp            | 0                   | 
| solidDB_active_searches                | 0                   | 
| solidDB_average_searches               | 2                   | 
| solidDB_database_size                  | 16064               | 
| solidDB_log_size                       | 5184                | 
| solidDB_checkpoint_active              | OFF                 | 
| solidDB_backup_active                  | OFF                 | 
| solidDB_version                        | 5.0.45-solidDB-0079 | 
| solidDB_pmon_fileopen                  | 4                   | 
| solidDB_pmon_fileread                  | 34                  | 
| solidDB_pmon_filewrite                 | 2                   | 
| solidDB_pmon_fileappend                | 0                   | 
| solidDB_pmon_fileflush                 | 2                   | 
| solidDB_pmon_filelock                  | 2                   | 
| solidDB_pmon_cachefind                 | 3821                | 
| solidDB_pmon_cachefileread             | 25                  | 
| solidDB_pmon_cachefilewrite            | 0                   | 
| solidDB_pmon_cacheprefetch             | 0                   | 
| solidDB_pmon_cacheprefetchwait         | 0                   | 
| solidDB_pmon_cachepreflush             | 0                   | 
| solidDB_pmon_cachelruwrite             | 0                   | 
| solidDB_pmon_cacheslotwait             | 0                   | 
| solidDB_pmon_sqlprepare                | 0                   | 
| solidDB_pmon_sqlexecute                | 0                   | 
| solidDB_pmon_sqlfetch                  | 0                   | 
| solidDB_pmon_dbeinsert                 | 3                   | 
| solidDB_pmon_dbedelete                 | 0                   | 
| solidDB_pmon_dbeupdate                 | 0                   | 
| solidDB_pmon_dbefetch                  | 2087                | 
| solidDB_pmon_dbefetchuniquefound       | 0                   | 
| solidDB_pmon_dbefetchuniquenotfound    | 0                   | 
| solidDB_pmon_transcommit               | 77                  | 
| solidDB_pmon_transabort                | 0                   | 
| solidDB_pmon_transrdonly               | 84                  | 
| solidDB_pmon_transbufcnt               | 0                   | 
| solidDB_pmon_transbufclean             | 5                   | 
| solidDB_pmon_transbufadded             | 4                   | 
| solidDB_pmon_transbufremoved           | 4                   | 
| solidDB_pmon_transvldcnt               | 0                   | 
| solidDB_pmon_transactcnt               | 1                   | 
| solidDB_pmon_transreadlevel            | 2887                | 
| solidDB_pmon_indwrite                  | 3                   | 
| solidDB_pmon_indwritesaftermerge       | 0                   | 
| solidDB_pmon_logwrites                 | 0                   | 
| solidDB_pmon_logfilewrite              | 0                   | 
| solidDB_pmon_logwritesaftercp          | 0                   | 
| solidDB_pmon_logsize                   | 5184                | 
| solidDB_pmon_srchnactive               | 0                   | 
| solidDB_pmon_dbsize                    | 16064               | 
| solidDB_pmon_dbfreesize                | 14656               | 
| solidDB_pmon_memsize                   | 606386              | 
| solidDB_pmon_mergequickstep            | 0                   | 
| solidDB_pmon_mergestep                 | 30                  | 
| solidDB_pmon_mergepurgestep            | 0                   | 
| solidDB_pmon_mergeuserstep             | 0                   | 
| solidDB_pmon_mergeoper                 | 23                  | 
| solidDB_pmon_mergecleanup              | 0                   | 
| solidDB_pmon_mergeact                  | 0                   | 
| solidDB_pmon_mergewrites               | 0                   | 
| solidDB_pmon_mergefilewrite            | 0                   | 
| solidDB_pmon_mergefileread             | 0                   | 
| solidDB_pmon_mergelevel                | 2887                | 
| solidDB_pmon_backupstep                | 0                   | 
| solidDB_pmon_backupact                 | 0                   | 
| solidDB_pmon_checkpointact             | 0                   | 
| solidDB_pmon_checkpointcount           | 0                   | 
| solidDB_pmon_checkpointfilewrite       | 0                   | 
| solidDB_pmon_checkpointfileread        | 4                   | 
| solidDB_pmon_estsamplesread            | 5                   | 
| solidDB_pmon_logflushes_logical        | 0                   | 
| solidDB_pmon_logflushes_physical       | 0                   | 
| solidDB_pmon_loggroupcommit_wakeups    | 1                   | 
| solidDB_pmon_logflushes_fullpages      | 0                   | 
| solidDB_pmon_logwaitflush              | 0                   | 
| solidDB_pmon_logmaxwritequeuerecords   | 0                   | 
| solidDB_pmon_logmaxwritequeuebytes     | 0                   | 
| solidDB_pmon_ss_threadcount            | 13                  | 
| solidDB_pmon_waitreadlevel_count       | 0                   | 
| solidDB_pmon_dbe_lock_ok               | 57                  | 
| solidDB_pmon_dbe_lock_timeout          | 0                   | 
| solidDB_pmon_dbe_lock_deadlock         | 0                   | 
| solidDB_pmon_dbe_lock_wait             | 0                   | 
| solidDB_pmon_mysql_rnd_init            | 0                   | 
| solidDB_pmon_mysql_index_read          | 0                   | 
| solidDB_pmon_mysql_fetch_next          | 0                   | 
| solidDB_pmon_mysql_cursor_create       | 0                   | 
| solidDB_pmon_mysql_cursor_reset_full   | 0                   | 
| solidDB_pmon_mysql_cursor_reset_simple | 0                   | 
| solidDB_pmon_mysql_cursor_reset_fetch  | 0                   | 
| solidDB_pmon_mysql_cursor_cache_find   | 0                   | 
| solidDB_pmon_mysql_cursor_cache_hit    | 0                   | 
| solidDB_pmon_mysql_connect             | 1                   | 
| solidDB_pmon_mysql_commit              | 0                   | 
| solidDB_pmon_mysql_rollback            | 0                   | 
+----------------------------------------+---------------------+
111 rows in set (0.00 sec)


  

You can display solidDB version information by using command:

show status like 'soliddb_version';

Here is an example output:

mysql> show status like 'soliddb_version';
+-----------------+---------------------+
| Variable_name   | Value               |
+-----------------+---------------------+
| solidDB_version | 5.0.45-solidDB-0079 | 
+-----------------+---------------------+
1 row in set (0.00 sec)
    

The following guidelines apply to troubleshooting solidDB problems:

SOLID Fatal error:
Out of central memory when allocating buffer memory (size =xxxxxxxxx)
    

SOLID Fatal error:
Too little cache memory has been specified for the SOLID process:

        [IndexFile]
        CacheSize=0    
        
Please edit the solid.ini file to increase this parameter value at least
to 172032 bytes and restart the SOLID process.        
    

In solidDB, data and indexes are stored in the same file(s). The term “index file” is used as a synonym for the term “database file”. The soliddb_filespec parameter specifies the name and location of the file(s) used to store the database. To define the location and maximum size for the file(s), the soliddb_filespec parameter accepts the following two arguments:

Example:

soliddb_filespec=solid.db 2000M

The size unit is 1 byte. You can use K, M and G unit symbols to denote kilobytes, megabytes and gigabytes, respectively. The maximum file-size is 4GB*blocksize-1. With the default 8KB block size, this makes 32TB - 1.

The soliddb_filespec parameter is also used to divide the database into multiple files and onto multiple disks. To divide the database into multiple files, specify another database specification. The index file will be written to the second file if it grows over the maximum value of the first parameter.

In the following example, the parameters divide the database file on the disks C:, D:, and E: to be split after growing larger than about 1 GB. Notice that the slash at the end of the first line has been added for layout purposes.

soliddb_filespec=C:\soldb\solid1.db/
1G,D:\soldb\solid2.db 1G,E:\soldb\solid3.db 1G

	Note
	The index file locations entered must be valid path names in the server's operating system. For example, if the server runs on a Unix operating system, path separators must be slashes instead of backlashes.

Although the database files reside in different directories, the filenames must be unique. There is no practical limit to the number of database files you can use.

Splitting the database file on multiple disks will increase the performance of the server because multiple disk heads will provide parallel access to the data in your database.

You may need to have multiple files on a single disk if your physical disk is portioned into multiple logical disks and no single logical disk can accommodate the size of the database file you expect to create.

If the database file is split into multiple physical disks, the multi-threaded solidDB engine is capable of assigning a separate disk I/O thread for each device. This way the server can perform database file I/O in a parallel manner.

If your database has reached the maximum size specified by the soliddb_filespec parameter, you have two options.

	Warning
	Do not attempt to use the soliddb_filespec parameter to decrease the size of a database; you risk losing pre-existing data and corrupting the database.

	Important
	Remember to add new file specification to the MySQL config file after you have added dynamically a new database file. You do not need to restart the server after you have added this new database file.

As a rule, solidDB uses the MySQL error messages. However, there are situations where solidDB writes error messages to the MySQL log. The possible error messages are:

MySQL offers standard database driver connectivity for using MySQL with applications and tools that are compatible with industry standards ODBC and JDBC. The drivers can be downloaded from MySQL web pages, see http://dev.mysql.com/downloads/connector/.