MYSQL MyISAM data recovery implementation

myisamMySQLtransaction

I am creating integration into eshop script, shop is using MyISAM tables and I need to implement something like transactions in InnoDB, what I actually need is full recovery of data after modifying or adding some rows.

Scenario would be like: some PHP script fills several tables with information, there will be about 10 tables affected. I'm thinking about creating temporary tables and filling them. After whole fill process succeeded, it will put actual rows to permanent tables and if not it will clean temporary tables.

I am wondering if there is easier way to have full recovery on fail? I cannot edit existing table's structure, or change table's engine. Thanks in advance for your time.

Edit: I have made very basic table of reference for simple understading of what I am dealing with. http://creately.com/diagram/h7yqs7qg2/UP3fno4Rzw3DTW3IdDa5uVDZQHE%3D

Real case scenario would be: I am creating order for user, but I cannot be sure that user creation didn't failed on behalf of creation(let's say created row only on main user table) then when I'll check if user exists for order it will return true. So when I'll start order creation an I'll need it's address but it won't exist. Thus order creation will also fail. That's why there has to be rollback if failed any of data. Data cannot be simply deleted by row id because row could be modified(Invoicing order or change of order status).

Sorry for my bad Englist.

Best Answer

I have BAD NEWS / GOOD NEWS for you

BAD NEWS

MyISAM is simply not suitable for you because...

MyISAM is not a transactional storage engine
Writes to a MyISAM cannot be rolled back
MyISAM tables that are open crash very easily if the mysqld process or DB server crashes

GOOD NEWS

Using InnoDB is absolutely in your best interests. You will have to do some work for this to become a reality.

STEP 01 : Create a Script that will Convert all tables to InnoDB

Conversion of all tables to InnoDB is incredibly straightforward.

MYSQL_CONN="-u... -p..."
SQL="SELECT CONCAT('ALTER TABLE ',table_schema,'.',table_name,' ENGINE=InnoDB;')"
SQL="${SQL} InnoDBConversionSQL FROM information_schema.tables WHERE engine='MyISAM'"
SQL="${SQL} AND table_schema NOT IN ('information_schema','mysql','performance_schema')"
SQL="${SQL} ORDER BY (data_length+index_length)"
mysql ${MYSQL_CONN} -ANe"${SQL}" > /root/ConvertMyISAMToInnoDB.sql

STEP 02 : Configure InnoDB Settings for Multithreading and Caching

If the DB Server has 8GB RAM, use the following settings in /etc/my.cnf

[mysqld]
innodb_data_file_path=ibdata1:10M:autoextend
innodb_file_per_table
innodb_buffer_pool_size=4G
innodb_log_file_size=1G
innodb_log_buffer_size=32M
innodb_open_files=16384
innodb_read_io_threads=64
innodb_write_io_threads=64
innodb_io_capacity=5000
key_buffer_size=8M

STEP 03 : Create new InnoDB Logs

cd /var/lib/mysql
service mysql stop
rm -f ibdata1 ib_logfile0 ib_logfile1
service mysql start

STEP 04 : Perform InnoDB Conversion

mysql ${MYSQL_CONN} < /root/ConvertMyISAMToInnoDB.sql

STEP 05 : Make changes in your code for transactional support

You will have to employ the use of three commands : 1) START TRANSACTION; 2) COMMIT; 3) ROLLBACK;

Before you starting writing new data, precede it once with

START TRANSACTION;

START TRANSACTION; will create an initial checkpoint in the event you want to

commit all changes to the database (via COMMIT)
abandon all subsequent changes (via ROLLBACK)

Thus, in your PHP code, you must strategically place COMMIT; commands in places your know you want to fully submit all INSERTs, UPDATEs, and DELETEs of all InnoDB tables. In like fashion, you must also place ROLLBACK; commands in places where you wish to abandoned compiled changes to InnoDB tables.

CAVEAT

If you still want to the data as MyISAM, I have an additional suggestion.

Get another DB Server. Load all data into the second server as follows:

STEP 01 : service mysql stop

STEP 02 : Add this to /etc/my.cnf

[mysqld]
skip-innodb

STEP 03 : service mysql start

STEP 04 : Load the data into the second server

mysql -hIPofSecondServer ${MYSQL_CONN} < /root/ConvertMyISAMToInnoDB.sql

STEP 05 : Setup replication from InnoDB Server to MyISAM server

That way, you can change back to MyISAM by just failing over to the server that's MyISAM

Related Solutions

Mysql – why/how does the number of matched columns influences the way of excecuting a query

I can provide with a general explanation, but it may not apply specifically to your particular case:

The way decision making works is by evaluation cost of execution plan, then picking up what is hopefully the cheapest plan. This you already know.

When it comes to indexing, though, stuff are getting interesting. The way to evaluate the usefulness or viability of an index is to estimate the selectivity given some value.

For the moment, forget about your FULLTEXT index, and let's assume a simple index on some column col1, and another index on some column col2. Given the following two queries:

SELECT * FROM t WHERE col1 < 10 and col2 = 4;
SELECT * FROM t WHERE col1 BETWEEN 100 AND 110 and col2 = 4;

It may happen that the query is evaluated differently in these two cases. Why? Because it may happen that col2 = 4 returns more rows than col1 < 10, in which case we prefer to use index on col1. But then, it may return less rows than col1 BETWEEN 100 AND 110, in which case we prefer the index on col2.

Your case is not very much different. MySQL estimates the number of rows returned by some index query. When you use more columns, MySQL gets the impression your index is likely to result with few rows. So it chooses to start with TableA, then joins what should be very few rows with TableB.

But if MySQL believes the index to return many rows, it may prefer starting with TableB. Why is that? Because you are sorting on indexed columns of TableB. Sorting is a lot of work, too. So MySQL may choose to first sort the rows, then join to TableA and filter by fulltext index. It may not be a bad idea if the fulltext search yields with many rows anyhow.

Thesql 5.1 — unknown variable ‘basedir=c:/thesql/’

Thank for posting the my.ini

PROBLEM: You have the basedir and datadir under the [client] section

basedir and datadir are server-only options, not client program options.

SOLUTION : Remove them from under the [client] section and you are good to go !!!

When done, this

[client]
port= new_port

##The MySQL server
Path to installation directory. All paths are usually resolved relative to this.
basedir="C:/MySQL/"
#Path to the database root
datadir="C:/MySQL/"
#Set the default character set.
default-character-set=latin1

should now be this:

[client]
port= new_port