Does you mysqldump look like this:
/usr/bin/mysqldump -udspam -pdspampasswd -hlocalhost dspam
--single-transaction > dspam.sql
Have a look here at option --single-transaction
(https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html#option_mysqldump_single-transaction):
|--single-transaction|
This option sets the transaction isolation mode to|REPEATABLE READ|
<https://dev.mysql.com/doc/refman/8.0/en/innodb-transaction-isolation-levels.html#isolevel_repeatable-read>and
sends a|START TRANSACTION|
<https://dev.mysql.com/doc/refman/8.0/en/commit.html>SQL statement to
the server before dumping data. It is useful only with transactional
tables such as|InnoDB|, because then it dumps the consistent state of
the database at the time when|START TRANSACTION|
<https://dev.mysql.com/doc/refman/8.0/en/commit.html>was issued without
blocking any applications.
When using this option, you should keep in mind that only|InnoDB|tables
are dumped in a consistent state. For example,
any|MyISAM|or|MEMORY|tables dumped while using this option may still
change state.
While a|--single-transaction|
<https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html#option_mysqldump_single-transaction>dump
is in process, to ensure a valid dump file (correct table contents and
binary log coordinates), no other connection should use the following
statements:|ALTER TABLE|
<https://dev.mysql.com/doc/refman/8.0/en/alter-table.html>,|CREATE
TABLE| <https://dev.mysql.com/doc/refman/8.0/en/create-table.html>,|DROP
TABLE| <https://dev.mysql.com/doc/refman/8.0/en/drop-table.html>,|RENAME
TABLE|
<https://dev.mysql.com/doc/refman/8.0/en/rename-table.html>,|TRUNCATE
TABLE| <https://dev.mysql.com/doc/refman/8.0/en/truncate-table.html>. A
consistent read is not isolated from those statements, so use of them on
a table to be dumped can cause the|SELECT|
<https://dev.mysql.com/doc/refman/8.0/en/select.html>that is performed
by*mysqldump* <https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html>to
retrieve the table contents to obtain incorrect contents or fail.
The|--single-transaction|option and the|--lock-tables|
<https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html#option_mysqldump_lock-tables>option
are mutually exclusive because|LOCK TABLES|
<https://dev.mysql.com/doc/refman/8.0/en/lock-tables.html>causes any
pending transactions to be committed implicitly.
To dump large tables, combine the|--single-transaction|option with
the|--quick|
<https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html#option_mysqldump_quick>option.
Maybe the statement should be change to this:
/usr/bin/mysqldump -udspam -pdspampasswd -hlocalhost dspam
--single-transaction --quick > dspam.sql
On 8/13/2020 10:44 PM, Remo Mattei wrote:
👍
On Aug 13, 2020, at 9:31 PM, Eric Broch <[email protected]
<mailto:[email protected]>> wrote:
Diego,
Are you backing up your dspam database (mysqldump)?
Eric
On 8/13/2020 10:22 PM, Diego Piñon Conde wrote:
Perfect!
I killed that proccess and two more child and then dspam service run
nicely!
One more time, thank you very much Eric!
El 13/08/2020 a las 10:57 p. m., Eric Broch escribió:
6856 is the process id
If spamd is not running then those ports are being bound.
Can you kill that process and try to start spamd
On 8/13/2020 7:28 PM, Diego Piñon Conde wrote:
/netstat -lptn | grep 'spamd'//
//tcp 10 0 127.0.0.1:783 0.0.0.0:*
LISTEN 6856/spamd child//
//tcp6 129 0 ::1:783 :::* LISTEN
6856/spamd child/
---------------------------------------------------------------------
To unsubscribe, e-mail:
[email protected] For additional
commands, e-mail: [email protected]
