I have replicated my db on mysql 5.1 to mariadb 10.0. I have installed mariadb 10.0 on slave server, take the backup on mysql 5.1 , transferred the backup on slave server having mariadb 10.0. and setup replication. Everything goes well. But slave stuck at delete_row_event .
I made RCA and found that there was some type of data mismatch on this table. Below is the structure of the table:
CREATE TABLE gsf (
data_on_date date DEFAULT NULL,
record_timestamp timestamp NULL DEFAULT CURRENT_TIMESTAMP,
WAODate varchar(25) DEFAULT NULL,
CardNbr varchar(255) DEFAULT NULL,
TranAmt float DEFAULT NULL,
TranCode varchar(255) DEFAULT NULL,
InvoiceNbr varchar(255) DEFAULT NULL,
MerNo varchar(255) DEFAULT NULL,
BatchNo varchar(255) DEFAULT NULL,
GoeRefNum varchar(255) DEFAULT NULL,
GoeOrderID varchar(255) DEFAULT NULL,
KEY InvoiceNbr (InvoiceNbr)
) ENGINE=MyISAM DEFAULT CHARSET=latin1
I
I though that this may be due to some mis-configuration of replication at my end. So, I decided just to take the dump of this table and restore it.
Then, I dropped the table from the slave and take the complete dump of only this table from master and store in the slave. But here also I faced the same problem. Data was not identical here which I was not expecting this time.
On master, I executed:
mysql> select record_timestamp from gsf where record_timestamp=1443078738;
Empty set, 1 warning (0.38 sec)
mysql> show warnings;
+---------+------+-------------------------------------------------------------------------------+
| Level | Code | Message |
+---------+------+-------------------------------------------------------------------------------+
| Warning | 1292 | Incorrect datetime value: '1443078738' for column 'record_timestamp' at row 1 |
+---------+------+-------------------------------------------------------------------------------+
On the slave, I executed the same query and it returns,
record_timestamp |
+---------------------+
| 0000-00-00 00:00:00 |
| 0000-00-00 00:00:00 |
| 0000-00-00 00:00:00 |
| 0000-00-00 00:00:00 |
| 0000-00-00 00:00:00 |
| 0000-00-00 00:00:00 |
| 0000-00-00 00:00:00 |
| 0000-00-00 00:00:00 |
| 0000-00-00 00:00:00 |
| 0000-00-00 00:00:00 |
+---------------------+
10 rows in set, 1 warning (0.29 sec)
show warnings;
+---------+------+----------------------------------------+
| Level | Code | Message |
+---------+------+----------------------------------------+
| Warning | 1292 | Incorrect datetime value: '1443078738' |
I think a configuration variable on mariadb 10 is effecting my data.
Please help me in this regard.
Is creating slave from mysql 5.1 to mariadb 10.0 is feasible?
TIMESTAMP fields expect to be in the format '2015-09-24 07:12:18'. This is why you get warnings in both MySQL and MariaDB. Run the query with the correct formatting and the results will be the same for both DB's - assuming the import also didn't have warnings.
Use FROM_UNIXTIME() to convert from seconds since 1970 to the timestamp format:
SELECT FROM_UNIXTIME('1443078738') AS `timestamp`;
timestamp
.........
2015-09-24 07:12:18
As I understand it, MySQL and Maria are not committed to remaining compatible. I wouldn't be surprised if there were binary log incompatibilities. Could you test with a newer version of MySQL or an older MariaDB version.
Related
I am currently trying to optimize some workflows here. One of our workflows involves calculating a time offset in hours from a given date, and that involves selecting from a number of tables and applying some business logic. That part of the problem is fairly well solved. What I am trying to do is to calculate a final timestamp based upon a timestamp value and an offset (in hours).
My source table looks like:
MariaDB [ingest]> describe tmp_file_3;
+---------------+---------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+---------------+---------------------+------+-----+---------+-------+
| mci_idx | bigint(20) unsigned | YES | | NULL | |
| mcg_idx | bigint(20) unsigned | YES | | NULL | |
| ingested_time | timestamp | YES | | NULL | |
| hours_persist | int(11) | YES | | NULL | |
| active | tinyint(1) | YES | | NULL | |
+---------------+---------------------+------+-----+---------+-------+```
And I am populating my new table with the following SQL:
MariaDB [ingest]> insert into master_expiration_index (select mci_idx, TIMESTAMPADD(HOUR, hours_persist, ingested_time) as expiration_time from tmp_file_3 where active=1);
ERROR 1292 (22007): Incorrect datetime value: '2023-03-12 02:20:15' for column `ingest`.`master_expiration_index`.`expiration_time` at row 347025
The SQL is correct to my understanding, since if I add a limit 10 to the query executes without any issues. The questions I have are:
What is wrong with that datetime value? It appears to be in the correct format
How do I figure out which row is causing the issue?
How do I fix this in the general case?
Objective: cronjob runs a task; when completed successfully, insert new host record. If record exists, update timestamp to reflect this status.
# Table layout
> describe hosts_completed;
+-----------+---------------------+------+-----+-------------------+-----------------------------+
| Field | Type | Null | Key | Default | Extra |
+-----------+---------------------+------+-----+-------------------+-----------------------------+
| id | bigint(20) unsigned | NO | PRI | NULL | auto_increment |
| timestamp | timestamp | NO | | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP |
| hostname | varchar(32) | YES | MUL | NULL | |
+-----------+---------------------+------+-----+-------------------+-----------------------------+
# Current inventory
> select * from hosts_completed;
+----+---------------------+----------+
| id | timestamp | hostname |
+----+---------------------+----------+
| 10 | 2020-11-02 12:51:08 | myHost1 |
| 11 | 2020-11-02 14:32:16 | MyHost2 |
+----+---------------------+----------+
I want to update the status for myHost1 and my best shot would be like
> insert into hosts_completed(hostname) values("myHost1") ON DUPLICATE KEY UPDATE timestamp=now();
and it runs but adds a new record, it does not update the myHost1 record.
Where is the glitch?
The on duplicate key syntax requires a unique constraint on the column that is used to detect the conflict. Create it first:
alter table hosts_completed
add constraint unique_hostname
unique (hostname);
Note that this pre-requires no duplicates in the column (otherwise you need to housekeep your data before you can create the constraint).
Then you can use your curent query:
insert into hosts_completed(hostname)
values('myHost1')
on duplicate key update timestamp = now();
I am trying to get some data that has datetime set, using the long format(ex: 2019-04-26 18:02:42).
When I use the following query I expected to find the following entry:
SELECT ip, cam_id
FROM test_table
WHERE ( date_time >= '2019-04-26 20:00:00' AND date_time <'2019-04-26 20:59:59' );
Entry:
id | ip | cam_id | date_time
-----+----+--------+---------------------
1 | 13 | 2 | 2019-04-26 20:46:06
However I am not getting any results. What am I doing wrong?
EDIT: Table schema
Kolon | Veri tipi | S²ralama (collation) | Bo■ (null) olabilir | Varsay²lan | Saklama | Stats hedefi | A²klama
-----------+------------------------+----------------------+---------------------+----------------------------------------+----------+--------------+----------
id | integer | | not null | nextval('test_table_id_seq'::regclass) | plain | |
ip | integer | | | | plain | |
cam_id | integer | | | | plain | |
date_time | character varying(255) | | | | extended | |
¦ndeksler:
"test_table_pkey" PRIMARY KEY, btree (id)
If you are new to postgresql, you should start first by reading postgresql manual and examples only. Dont use any kind of third party or unrelated code and sql generators, especialy unrelated to postgresql, those will only confuse you.
Currently, your query is comparing strings not datetime.
if you run this query, it will change date_time columns character varying(255) type to timestamp one, then your query will run properly:
alter table test_table alter column date_time TYPE timestamp without time zone using date_time::timestamp without time zone
You have to convert string to datetime format:
CONVERT(datetime, YOUR_COLUMN, 'yyyy-mm-dd hh:mm')
A sequence is an alternative to create for example the Primary Key on every record in your tables.
So this is the common syntax I'm using actually
CREATE TABLE users(
id BIGINT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(100) UNIQUE NOT NULL
);
As you can see the common solution I implemented is the PRIMARY KEY clausule
But is RDBMS such as Oracle or PostgreSQL is possible to use sequences for replacing the previous code
For example in Oracle you declare
CREATE SEQUENCE id
START WITH 1
INCREMENT BY 1;
Or in PostgreSQL in this way
CREATE SEQUENCE id
START WITH 1
INCREMENT BY 1;
But this is possible in mariaDB Server?
In MariaDB since version 10.3 there is the possibility of natively using the creation of sequences; through the following example you can see how it is achieved
First let's create the table sequence
CREATE SEQUENCE id
START WITH 1
INCREASE BY 1;
If for example we want to see the structure of the table id, newly created; just execute the following in the console
MariaDB [blog]> describe id;
+-----------------------+---------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------------------+---------------------+------+-----+---------+-------+
| next_not_cached_value | bigint(21) | NO | | NULL | |
| minimum_value | bigint(21) | NO | | NULL | |
| maximum_value | bigint(21) | NO | | NULL | |
| start_value | bigint(21) | NO | | NULL | |
| increment | bigint(21) | NO | | NULL | |
| cache_size | bigint(21) unsigned | NO | | NULL | |
| cycle_option | tinyint(1) unsigned | NO | | NULL | |
| cycle_count | bigint(21) | NO | | NULL | |
+-----------------------+---------------------+------+-----+---------+-------+
From the above table you can notice important details such as the fact that the default numeric value is of type BIGINT
So that as we said that it is going to start in the numbering in 1 and in one more is going to increase, it allows us to generate the progressive number that can be associated, like a primary to a table
Let's create a new table of examples in the mariaDB manager
MariaDB [blog]> CREATE TABLE demo (
-> id BIGINT NOT NULL,
-> name VARCHAR (30),
-> PRIMARY KEY (id));
Finally, when declaring a primary key of autoincrement type it is not necessary to declare it in the insert sentence, when we use a sequence if it is necessary to write the name of the column; as the following example
MariaDB [blog]> INSERT INTO demo (id, name)
-> VALUES
-> (NEXT VALUE FOR id, 'alpha');
How can the previous sequence be observed, to insert the dynamic value generated by the sequence, we invoke the name of the sequence through NEXT VALUE for and at the end the name of the sequence id
Finally, you can obtain the result of our previous sentence, we execute a SELECT regularly on the table and we obtain the following
MariaDB [blog]> SELECT * FROM demo;
+ ---- + ------ +
| id | name |
+ ---- + ------ +
| 1 | alpha |
+ ---- + ------ +
Extra configurations:
Optionally, you can configure the following parameters to a sequence within the mariaDB manager:
minvalue = You can set it 1
maxvalue = Depending on the type of data you choose if it is INT or BIGINT you must check to place a cap that respects the limits of
those data types
Cycle = By default it has the option no cycle, otherwise, once the minimum value starts and the maximum limit is reached, the counter
is restarted and the numbering begins again (provided that the limit
of the data type) possible )
In a word - yes. That feature is available since version 10.3.
See the documentation for the full details.
MySQL ver 5.1.26
I'm getting the wrong result with a select that has where, order by and limit clauses.
It's only a problem when the order by uses the id column.
I saw the MySQL manual for LIMIT Optimization
My guess from reading the manual is that there is some problem with the index on the primary key, id. But I don't know where I should go from here...
Question: what should I do to best solve the problem?
Works correctly:
mysql> SELECT id, created_at FROM billing_invoices
WHERE (billing_invoices.account_id = 5) ORDER BY id DESC ;
+------+---------------------+
| id | created_at |
+------+---------------------+
| 1336 | 2010-05-14 08:05:25 |
| 1334 | 2010-05-06 08:05:25 |
| 1331 | 2010-05-05 23:18:11 |
+------+---------------------+
3 rows in set (0.00 sec)
WRONG result when limit added! Should be the first row, id - 1336
mysql> SELECT id, created_at FROM billing_invoices
WHERE (billing_invoices.account_id = 5) ORDER BY id DESC limit 1;
+------+---------------------+
| id | created_at |
+------+---------------------+
| 1331 | 2010-05-05 23:18:11 |
+------+---------------------+
1 row in set (0.00 sec)
Works correctly:
mysql> SELECT id, created_at FROM billing_invoices
WHERE (billing_invoices.account_id = 5) ORDER BY created_at DESC ;
+------+---------------------+
| id | created_at |
+------+---------------------+
| 1336 | 2010-05-14 08:05:25 |
| 1334 | 2010-05-06 08:05:25 |
| 1331 | 2010-05-05 23:18:11 |
+------+---------------------+
3 rows in set (0.01 sec)
Works correctly with limit:
mysql> SELECT id, created_at FROM billing_invoices
WHERE (billing_invoices.account_id = 5) ORDER BY created_at DESC limit 1;
+------+---------------------+
| id | created_at |
+------+---------------------+
| 1336 | 2010-05-14 08:05:25 |
+------+---------------------+
1 row in set (0.01 sec)
Additional info:
explain SELECT id, created_at FROM billing_invoices WHERE (billing_invoices.account_id = 5) ORDER BY id DESC limit 1;
+----+-------------+------------------+-------+--------------------------------------+--------------------------------------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+------------------+-------+--------------------------------------+--------------------------------------+---------+------+------+-------------+
| 1 | SIMPLE | billing_invoices | range | index_billing_invoices_on_account_id | index_billing_invoices_on_account_id | 4 | NULL | 3 | Using where |
+----+-------------+------------------+-------+--------------------------------------+--------------------------------------+---------+------+------+-------------+
Added SHOW CREATE TABLE billing_invoices result:
Table -- billing_invoices
Create Table --
CREATE TABLE `billing_invoices` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`account_id` int(11) NOT NULL,
`invoice_date` date NOT NULL,
`prior_invoice_id` int(11) DEFAULT NULL,
`closing_balance` decimal(8,2) NOT NULL,
`note` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`monthly_invoice` tinyint(1) NOT NULL,
`created_at` datetime DEFAULT NULL,
`updated_at` datetime DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `index_billing_invoices_on_account_id` (`account_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1337 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci
Added more:
I now see that on my development machine, everything is working correctly. That machine has version VERSION() of 5.1.26-rc-log
On my production machine, where the problem is, I see that VERSION() returns 5.1.26-rc-percona-log
So at this point, I'm thinking the problem is with the percona software?
Added more:
At this point, I'm going to consider it a bug in the Percona InnoDB driver. I've put a question to their forum. As an immediate work-around, I'm going to order by created_at. I will also investigate upgrading the db on my system and see if that helps.
My thanks to Rabbott and mdma for their help. I also appreciate the help that I'm not doing something silly, this really is a problem.
Could be this bug that was never resolved for your updated version? http://bugs.mysql.com/bug.php?id=31001
I am running 5.1.42 locally. I copy and pasted your queries from above and am getting all the correct results.. Whether it be the bug mentioned above or not, it sounds like a bug, and it appears to have been fixed in a more recent release than yours..
Seems peculiar, maybe a bug? As a workarount maybe you can make the selection explicit - use a subquery to select the MAX(id) and filter on that in a WHERE clause. E.g.
SELECT id, created_at FROM billing_invoices
WHERE id IN (SELECT MAX(id) FROM billing_invoices WHERE account_id=5)
From here,
Bug Details
It seems it was fixed in 5.1.28 :
[22 Jul 2008 20:34] Bugs System
Pushed into 5.1.28
However, I'm noticing the same problem in my version: 5.1.41-3ubuntu12.8