Details
-
Type:
Bug
-
Status: Closed
-
Resolution: Not a Bug
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: None
-
Labels:
Description
So in the process of moving to a new VPS (fancy name for a VM) with MariaDB installed (Ubuntu 10.04 LTS, stock MariaDB, whichever one is the latest in the apt sources), and when I try run the .sql export on my MariaDB installation I get the following:
root@primary:~# mysql -q -u root -p prod_test < dmp.sql
ERROR 2013 (HY000) at line 1529: Lost connection to MySQL server during query
Line 1529 is quite innocuous: /*!40000 ALTER TABLE `tblSubscriptionEmail` ENABLE KEYS */;
This is consistent and reproducible. Since MariaDB errors out to syslog, I checked my syslog to see what it had to say, and here it is:
Feb 28 00:14:21 primary kernel: [2247125.181808] OOM killed process 20943 (mysqld) vm:1347796kB, rss:404944kB, swap:0kB
Feb 28 00:14:22 primary mysqld_safe: Number of processes running now: 0
Feb 28 00:14:22 primary mysqld_safe: mysqld restarted
Feb 28 00:14:22 primary mysqld: 120228 00:14:22 [Note] PrimeBase XT (PBXT) Engine 1.0.11-7 Pre-GA loaded...
Feb 28 00:14:22 primary mysqld: 120228 00:14:22 [Note] Paul McCullagh, PrimeBase Technologies GmbH, http://www.primebase.org
Feb 28 00:14:22 primary mysqld: 120228 00:14:22 [Note] The server was not shutdown correctly, recovery required
Feb 28 00:14:22 primary mysqld: InnoDB: The InnoDB memory heap is disabled
Feb 28 00:14:22 primary mysqld: InnoDB: Mutexes and rw_locks use GCC atomic builtins
Feb 28 00:14:22 primary mysqld: InnoDB: Compressed tables use zlib 1.2.3.3
Feb 28 00:14:22 primary mysqld: 120228 0:14:22 InnoDB: Initializing buffer pool, size = 256.0M
Feb 28 00:14:22 primary mysqld: 120228 0:14:22 InnoDB: Completed initialization of buffer pool
Feb 28 00:14:22 primary mysqld: 120228 0:14:22 InnoDB: highest supported file format is Barracuda.
Feb 28 00:14:22 primary mysqld: 120228 0:14:22 Percona XtraDB (http://www.percona.com) 1.0.17-13.0 started; log sequence number 45356
Feb 28 00:14:22 primary mysqld: 120228 0:14:22 [Note] Recovering after a crash using /var/log/mysql/mariadb-bin
Feb 28 00:14:22 primary mysqld: 120228 0:14:22 [Note] Starting crash recovery...
Feb 28 00:14:22 primary mysqld: 120228 0:14:22 [Note] Crash recovery finished.
Feb 28 00:14:22 primary mysqld: 120228 0:14:22 [Note] Event Scheduler: Loaded 0 events
Feb 28 00:14:22 primary mysqld: 120228 0:14:22 [Note] /usr/sbin/mysqld: ready for connections.
Feb 28 00:14:22 primary mysqld: Version: '5.3.4-MariaDB-rc-mariadb111~lucid-log' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (MariaDB - http://mariadb.com/)
What gives? Is it a memory leak that's causing the process to be terminated? I'll gladly give up a copy of the 44mb MySQL dump, but I would have to do so privately for privacy concerns.
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Re: [Bug 942283] Re: MariaDB crashes on import from MySQL mysqldump export
Hi Elena,
Done - the file is "riccardo.sql.gz" - let me know if you need anything
else off the server or if you need access to it. It's a dev server, so it's
not like there's anything sensitive on it.
Riccardo
On 29 February 2012 02:32, Elena Stepanova <942283@bugs.launchpad.net>wrote:
> Hi,
>
> Yes, if it is okay with you, please upload the dump to
> ftp://ftp.askmonty.org/, the private section.
>
> Thank you.
>
> –
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/942283
>
> Title:
> MariaDB crashes on import from MySQL mysqldump export
>
> Status in Maria:
> New
>
> Bug description:
> So in the process of moving to a new VPS (fancy name for a VM) with
> MariaDB installed (Ubuntu 10.04 LTS, stock MariaDB, whichever one is
> the latest in the apt sources), and when I try run the .sql export on
> my MariaDB installation I get the following:
>
> root@primary:~# mysql -q -u root -p prod_test < dmp.sql
> ERROR 2013 (HY000) at line 1529: Lost connection to MySQL server during
> query
>
> Line 1529 is quite innocuous: /*!40000 ALTER TABLE
> `tblSubscriptionEmail` ENABLE KEYS */;
>
> This is consistent and reproducible. Since MariaDB errors out to
> syslog, I checked my syslog to see what it had to say, and here it is:
>
> Feb 28 00:14:21 primary kernel: [2247125.181808] OOM killed process 20943
> (mysqld) vm:1347796kB, rss:404944kB, swap:0kB
> Feb 28 00:14:22 primary mysqld_safe: Number of processes running now: 0
> Feb 28 00:14:22 primary mysqld_safe: mysqld restarted
> Feb 28 00:14:22 primary mysqld: 120228 00:14:22 [Note] PrimeBase XT
> (PBXT) Engine 1.0.11-7 Pre-GA loaded...
> Feb 28 00:14:22 primary mysqld: 120228 00:14:22 [Note] Paul McCullagh,
> PrimeBase Technologies GmbH, http://www.primebase.org
> Feb 28 00:14:22 primary mysqld: 120228 00:14:22 [Note] The server was not
> shutdown correctly, recovery required
> Feb 28 00:14:22 primary mysqld: InnoDB: The InnoDB memory heap is disabled
> Feb 28 00:14:22 primary mysqld: InnoDB: Mutexes and rw_locks use GCC
> atomic builtins
> Feb 28 00:14:22 primary mysqld: InnoDB: Compressed tables use zlib 1.2.3.3
> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 InnoDB: Initializing
> buffer pool, size = 256.0M
> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 InnoDB: Completed
> initialization of buffer pool
> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 InnoDB: highest
> supported file format is Barracuda.
> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 Percona XtraDB (
> http://www.percona.com) 1.0.17-13.0 started; log sequence number 45356
> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 [Note] Recovering after a
> crash using /var/log/mysql/mariadb-bin
> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 [Note] Starting crash
> recovery...
> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 [Note] Crash recovery
> finished.
> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 [Note] Event Scheduler:
> Loaded 0 events
> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 [Note] /usr/sbin/mysqld:
> ready for connections.
> Feb 28 00:14:22 primary mysqld: Version:
> '5.3.4-MariaDB-rc-mariadb111~lucid-log' socket:
> '/var/run/mysqld/mysqld.sock' port: 3306 (MariaDB - http://mariadb.com/)
>
> What gives? Is it a memory leak that's causing the process to be
> terminated? I'll gladly give up a copy of the 44mb MySQL dump, but I
> would have to do so privately for privacy concerns.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/maria/+bug/942283/+subscriptions
>
Re: MariaDB crashes on import from MySQL mysqldump export
Hi,
Thank you for the file.
I am trying to run it and don't see any obvious problems on my machines so far, I tried release builds on Ubuntu 10.04 and openSUSE, as well as a debug build with valgrind.
I can see however that the table which is being altered when you are getting the problem is not tiny, as well as the indexed fields, so probably the operation can be just memory consuming indeed.
How much memory do you have on your VM total, could it be that it really does not have enough?
Also, could you please attach your server configuration file, especially if you made any changes comparing to the default installation.
Thank you.
Hi Elena,
my.cnf attached. You are right - the table isn't tiny, but that's why
autocommit is on, so that it will commit each of those insert's to disk and
not hog memory. The VM only has 512mb, htop tells me that there is 260mb
available, and because it is a VPS there is no swap (OpenVZ doesn't support
swap on CentOS 5 I think). I get that the OOM Killer is probably taking it
out, but is there not a graceful way for MariaDB to handle low memory
inserts? Or is there something I'm doing wrong?
Riccardo
On 1 March 2012 06:37, Elena Stepanova <email address hidden> wrote:
> Hi,
>
> Thank you for the file.
> I am trying to run it and don't see any obvious problems on my machines so
> far, I tried release builds on Ubuntu 10.04 and openSUSE, as well as a
> debug build with valgrind.
>
> I can see however that the table which is being altered when you are
> getting the problem is not tiny, as well as the indexed fields, so probably
> the operation can be just memory consuming indeed.
> How much memory do you have on your VM total, could it be that it really
> does not have enough?
>
> Also, could you please attach your server configuration file, especially
> if you made any changes comparing to the default installation.
>
> Thank you.
>
> –
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/942283
>
> Title:
> MariaDB crashes on import from MySQL mysqldump export
>
> Status in Maria:
> New
>
> Bug description:
> So in the process of moving to a new VPS (fancy name for a VM) with
> MariaDB installed (Ubuntu 10.04 LTS, stock MariaDB, whichever one is
> the latest in the apt sources), and when I try run the .sql export on
> my MariaDB installation I get the following:
>
> root@primary:~# mysql -q -u root -p prod_test < dmp.sql
> ERROR 2013 (HY000) at line 1529: Lost connection to MySQL server during
> query
>
> Line 1529 is quite innocuous: /*!40000 ALTER TABLE
> `tblSubscriptionEmail` ENABLE KEYS */;
>
> This is consistent and reproducible. Since MariaDB errors out to
> syslog, I checked my syslog to see what it had to say, and here it is:
>
> Feb 28 00:14:21 primary kernel: [2247125.181808] OOM killed process 20943
> (mysqld) vm:1347796kB, rss:404944kB, swap:0kB
> Feb 28 00:14:22 primary mysqld_safe: Number of processes running now: 0
> Feb 28 00:14:22 primary mysqld_safe: mysqld restarted
> Feb 28 00:14:22 primary mysqld: 120228 00:14:22 [Note] PrimeBase XT
> (PBXT) Engine 1.0.11-7 Pre-GA loaded...
> Feb 28 00:14:22 primary mysqld: 120228 00:14:22 [Note] Paul McCullagh,
> PrimeBase Technologies GmbH, http://www.primebase.org
> Feb 28 00:14:22 primary mysqld: 120228 00:14:22 [Note] The server was not
> shutdown correctly, recovery required
> Feb 28 00:14:22 primary mysqld: InnoDB: The InnoDB memory heap is disabled
> Feb 28 00:14:22 primary mysqld: InnoDB: Mutexes and rw_locks use GCC
> atomic builtins
> Feb 28 00:14:22 primary mysqld: InnoDB: Compressed tables use zlib 1.2.3.3
> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 InnoDB: Initializing
> buffer pool, size = 256.0M
> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 InnoDB: Completed
> initialization of buffer pool
> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 InnoDB: highest
> supported file format is Barracuda.
> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 Percona XtraDB (
> http://www.percona.com) 1.0.17-13.0 started; log sequence number 45356
> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 [Note] Recovering after a
> crash using /var/log/mysql/mariadb-bin
> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 [Note] Starting crash
> recovery...
> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 [Note] Crash recovery
> finished.
> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 [Note] Event Scheduler:
> Loaded 0 events
> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 [Note] /usr/sbin/mysqld:
> ready for connections.
> Feb 28 00:14:22 primary mysqld: Version:
> '5.3.4-MariaDB-rc-mariadb111~lucid-log' socket:
> '/var/run/mysqld/mysqld.sock' port: 3306 (MariaDB - http://mariadb.com/)
>
> What gives? Is it a memory leak that's causing the process to be
> terminated? I'll gladly give up a copy of the 44mb MySQL dump, but I
> would have to do so privately for privacy concerns.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/maria/+bug/942283/+subscriptions
>
my.cnf
LPexportBug942283_my.cnf
Re: [Bug 942283] Re: MariaDB crashes on import from MySQL mysqldump export
Hi Elena,
my.cnf attached. You are right - the table isn't tiny, but that's why
autocommit is on, so that it will commit each of those insert's to disk and
not hog memory. The VM only has 512mb, htop tells me that there is 260mb
available, and because it is a VPS there is no swap (OpenVZ doesn't support
swap on CentOS 5 I think). I get that the OOM Killer is probably taking it
out, but is there not a graceful way for MariaDB to handle low memory
inserts? Or is there something I'm doing wrong?
Riccardo
On 1 March 2012 06:37, Elena Stepanova <942283@bugs.launchpad.net> wrote:
> Hi,
>
> Thank you for the file.
> I am trying to run it and don't see any obvious problems on my machines so
> far, I tried release builds on Ubuntu 10.04 and openSUSE, as well as a
> debug build with valgrind.
>
> I can see however that the table which is being altered when you are
> getting the problem is not tiny, as well as the indexed fields, so probably
> the operation can be just memory consuming indeed.
> How much memory do you have on your VM total, could it be that it really
> does not have enough?
>
> Also, could you please attach your server configuration file, especially
> if you made any changes comparing to the default installation.
>
> Thank you.
>
> –
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/942283
>
> Title:
> MariaDB crashes on import from MySQL mysqldump export
>
> Status in Maria:
> New
>
> Bug description:
> So in the process of moving to a new VPS (fancy name for a VM) with
> MariaDB installed (Ubuntu 10.04 LTS, stock MariaDB, whichever one is
> the latest in the apt sources), and when I try run the .sql export on
> my MariaDB installation I get the following:
>
> root@primary:~# mysql -q -u root -p prod_test < dmp.sql
> ERROR 2013 (HY000) at line 1529: Lost connection to MySQL server during
> query
>
> Line 1529 is quite innocuous: /*!40000 ALTER TABLE
> `tblSubscriptionEmail` ENABLE KEYS */;
>
> This is consistent and reproducible. Since MariaDB errors out to
> syslog, I checked my syslog to see what it had to say, and here it is:
>
> Feb 28 00:14:21 primary kernel: [2247125.181808] OOM killed process 20943
> (mysqld) vm:1347796kB, rss:404944kB, swap:0kB
> Feb 28 00:14:22 primary mysqld_safe: Number of processes running now: 0
> Feb 28 00:14:22 primary mysqld_safe: mysqld restarted
> Feb 28 00:14:22 primary mysqld: 120228 00:14:22 [Note] PrimeBase XT
> (PBXT) Engine 1.0.11-7 Pre-GA loaded...
> Feb 28 00:14:22 primary mysqld: 120228 00:14:22 [Note] Paul McCullagh,
> PrimeBase Technologies GmbH, http://www.primebase.org
> Feb 28 00:14:22 primary mysqld: 120228 00:14:22 [Note] The server was not
> shutdown correctly, recovery required
> Feb 28 00:14:22 primary mysqld: InnoDB: The InnoDB memory heap is disabled
> Feb 28 00:14:22 primary mysqld: InnoDB: Mutexes and rw_locks use GCC
> atomic builtins
> Feb 28 00:14:22 primary mysqld: InnoDB: Compressed tables use zlib 1.2.3.3
> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 InnoDB: Initializing
> buffer pool, size = 256.0M
> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 InnoDB: Completed
> initialization of buffer pool
> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 InnoDB: highest
> supported file format is Barracuda.
> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 Percona XtraDB (
> http://www.percona.com) 1.0.17-13.0 started; log sequence number 45356
> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 [Note] Recovering after a
> crash using /var/log/mysql/mariadb-bin
> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 [Note] Starting crash
> recovery...
> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 [Note] Crash recovery
> finished.
> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 [Note] Event Scheduler:
> Loaded 0 events
> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 [Note] /usr/sbin/mysqld:
> ready for connections.
> Feb 28 00:14:22 primary mysqld: Version:
> '5.3.4-MariaDB-rc-mariadb111~lucid-log' socket:
> '/var/run/mysqld/mysqld.sock' port: 3306 (MariaDB - http://mariadb.com/)
>
> What gives? Is it a memory leak that's causing the process to be
> terminated? I'll gladly give up a copy of the 44mb MySQL dump, but I
> would have to do so privately for privacy concerns.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/maria/+bug/942283/+subscriptions
>
Re: [Bug 942283] Re: MariaDB crashes on import from MySQL mysqldump export
Hah! Fixed it![]()
mysql -u root -p --quick --unbuffered --max_allowed_packet=1M frugaloon <
dmp.sql
I was setting the max allowed packet HIGH (like 16M) or leaving it on the
default, and it kept wiping out. Thanks for your help!
Riccardo
On 1 March 2012 07:02, Riccardo Spagni <ric@spagni.net> wrote:
> Hi Elena,
>
> my.cnf attached. You are right - the table isn't tiny, but that's why
> autocommit is on, so that it will commit each of those insert's to disk and
> not hog memory. The VM only has 512mb, htop tells me that there is 260mb
> available, and because it is a VPS there is no swap (OpenVZ doesn't support
> swap on CentOS 5 I think). I get that the OOM Killer is probably taking it
> out, but is there not a graceful way for MariaDB to handle low memory
> inserts? Or is there something I'm doing wrong?
>
> Riccardo
>
>
> On 1 March 2012 06:37, Elena Stepanova <942283@bugs.launchpad.net> wrote:
>
>> Hi,
>>
>> Thank you for the file.
>> I am trying to run it and don't see any obvious problems on my machines
>> so far, I tried release builds on Ubuntu 10.04 and openSUSE, as well as a
>> debug build with valgrind.
>>
>> I can see however that the table which is being altered when you are
>> getting the problem is not tiny, as well as the indexed fields, so probably
>> the operation can be just memory consuming indeed.
>> How much memory do you have on your VM total, could it be that it really
>> does not have enough?
>>
>> Also, could you please attach your server configuration file, especially
>> if you made any changes comparing to the default installation.
>>
>> Thank you.
>>
>> –
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https://bugs.launchpad.net/bugs/942283
>>
>> Title:
>> MariaDB crashes on import from MySQL mysqldump export
>>
>> Status in Maria:
>> New
>>
>> Bug description:
>> So in the process of moving to a new VPS (fancy name for a VM) with
>> MariaDB installed (Ubuntu 10.04 LTS, stock MariaDB, whichever one is
>> the latest in the apt sources), and when I try run the .sql export on
>> my MariaDB installation I get the following:
>>
>> root@primary:~# mysql -q -u root -p prod_test < dmp.sql
>> ERROR 2013 (HY000) at line 1529: Lost connection to MySQL server during
>> query
>>
>> Line 1529 is quite innocuous: /*!40000 ALTER TABLE
>> `tblSubscriptionEmail` ENABLE KEYS */;
>>
>> This is consistent and reproducible. Since MariaDB errors out to
>> syslog, I checked my syslog to see what it had to say, and here it is:
>>
>> Feb 28 00:14:21 primary kernel: [2247125.181808] OOM killed process
>> 20943 (mysqld) vm:1347796kB, rss:404944kB, swap:0kB
>> Feb 28 00:14:22 primary mysqld_safe: Number of processes running now: 0
>> Feb 28 00:14:22 primary mysqld_safe: mysqld restarted
>> Feb 28 00:14:22 primary mysqld: 120228 00:14:22 [Note] PrimeBase XT
>> (PBXT) Engine 1.0.11-7 Pre-GA loaded...
>> Feb 28 00:14:22 primary mysqld: 120228 00:14:22 [Note] Paul McCullagh,
>> PrimeBase Technologies GmbH, http://www.primebase.org
>> Feb 28 00:14:22 primary mysqld: 120228 00:14:22 [Note] The server was
>> not shutdown correctly, recovery required
>> Feb 28 00:14:22 primary mysqld: InnoDB: The InnoDB memory heap is
>> disabled
>> Feb 28 00:14:22 primary mysqld: InnoDB: Mutexes and rw_locks use GCC
>> atomic builtins
>> Feb 28 00:14:22 primary mysqld: InnoDB: Compressed tables use zlib
>> 1.2.3.3
>> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 InnoDB: Initializing
>> buffer pool, size = 256.0M
>> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 InnoDB: Completed
>> initialization of buffer pool
>> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 InnoDB: highest
>> supported file format is Barracuda.
>> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 Percona XtraDB (
>> http://www.percona.com) 1.0.17-13.0 started; log sequence number 45356
>> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 [Note] Recovering after
>> a crash using /var/log/mysql/mariadb-bin
>> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 [Note] Starting crash
>> recovery...
>> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 [Note] Crash recovery
>> finished.
>> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 [Note] Event Scheduler:
>> Loaded 0 events
>> Feb 28 00:14:22 primary mysqld: 120228 0:14:22 [Note] /usr/sbin/mysqld:
>> ready for connections.
>> Feb 28 00:14:22 primary mysqld: Version:
>> '5.3.4-MariaDB-rc-mariadb111~lucid-log' socket:
>> '/var/run/mysqld/mysqld.sock' port: 3306 (MariaDB - http://mariadb.com/
>> )
>>
>> What gives? Is it a memory leak that's causing the process to be
>> terminated? I'll gladly give up a copy of the 44mb MySQL dump, but I
>> would have to do so privately for privacy concerns.
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/maria/+bug/942283/+subscriptions
>>
>
>
Re: MariaDB crashes on import from MySQL mysqldump export
Hi Riccardo,
There is no 'configuration issue' or another similar status in launchpad, so I will set it to 'Invalid' to get it closed. Please don't take it as offense.
Launchpad bug id: 942283
Re: MariaDB crashes on import from MySQL mysqldump export
Hi,
Yes, if it is okay with you, please upload the dump to ftp://ftp.askmonty.org/, the private section.
Thank you.