Question

Currently we have a database where STATEMENT bin log format works fine.
Now we are adding a new table with an auto increment value.
This auto increment column is no purpose for the business logic.
We have added this as part of our primary key.
Here offer_expiry_time is the first part of primary key since we have all our queries as range queries based on expiry time range.

Assume our table looks similar to this:

CREATE TABLE offer_expiry_info  
    offer_expiry_time BIGINT UNSIGNED NOT NULL null,  
    purchase_id INT UNSIGNED auto_increment,
    PRIMARY KEY (offer_expiry_time, purchase_id),
    KEY idx_purchase_id (purchase_id)
)ENGINE = INNOBB;

Now our concerns are:

  1. Will STATEMENT level bin log format work for this table? (even we are fine with different values for auto increment columns across replications). Basically Will STATEMENT level ever work?

  2. If it works what are the issues that might occur while bringing up a failed db machine?

  3. If STATEMENT mode will not work, then can we use specific(MIXED) replication mode for this table alone? Can the rest of the tables in the same database can have STATEMENT mode?

  4. This may be a very silly question as i am not aware of how mysql handles replication. Is it possible to specify the replication mode based on the query type? (For insert queries do ROW level replication and for DELETE queries perform STATEMENT level replication)

    The question 4 is because we do perform deletion based on range based delete and hence will have a better performance if we can have STATEMENT replication for delete queries.

DELETE FROM order_expiry_info WHERE offer_expiry_time "LESS THAN" SOME TIME

Since we do batch inserts, STATEMENT level replication will help us a lot.
Is it possible to have the tables with auto increment columns have STATEMENT level bin log format?

[edited] Also we do have another issue with the transaction isolation level.
ERROR: "Getting the error Binary logging not possible. Message: Transaction level 'REA D-UNCOMMITTED' in InnoDB is not safe for binlog mode 'STATEMENT'"

Any suggestion would be very much helpful?

Was it helpful?

Solution

Yes those scenarios will work fine with the statement binlogs.

If you can access the logs, you will see that certain values are logged before each statements to ensure things like the timestamp and auto increment values will be preserved appropriately.

I have been using statement based replication for years without an issue in any of these areas. I would suggest sticking with that and only considering row based or mixed replication if a specific performance situation arises that may need them.

Please note there are certain types of usage which are not safe with statement based replication, but simple auto increment usage isn't one of them.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top