Set up a slave with copy of another slave

Hi,
I’ve got a master-slave pair, now I need to duplicate the slave.
Is it possible to stop slave MySQL, copy all datadir files, and then simply run the new slave?

You can absolutely copy a slave, as a rule of thumb I’d usually lock the tables completely (or shut down the slave whilst copying the files) whilst copying the files though: [INDENT]STOP SLAVE;
FLUSH TABLES WITH READ LOCK;

rsync newslave:<new_mysql_datadir>

UNLOCK TABLES;
START SLAVE;[/INDENT]
^^ should do it, make sure to keep the MySQL client window open whilst the tables are locked (usually easier to keep that session open in a screen session)

Note: If the servers are all MySQL/Percona 5.6 remember to remove/rename the auto.cnf file before starting up the new server. The auto.cnf file defines the servers UUID (a bit like server_id used to be in /etc/my.cnf, but globally unique and it’s stored in the data_directory now), and thus needs to be unique (auto-generated) for each and every slave. The Percona guys wrote about this recently, check ([URL=“Beware of MySQL 5.6 server UUID when cloning slaves”]http://www.mysqlperformanceblog.com/...loning-slaves/[/URL]) for more info.

Thank you!

I’ve rsync’ed the datadir w/ MySQL stopped, but the copy failed to start:
[HR][/HR]140526 18:43:35 mysqld_safe Starting mysqld daemon with databases from /srv/mysql
140526 18:43:35 [Note] Flashcache bypass: disabled
140526 18:43:35 [Note] Flashcache setup error is : ioctl failed

140526 18:43:35 [Note] Plugin ‘FEDERATED’ is disabled.
140526 18:43:35 InnoDB: The InnoDB memory heap is disabled
140526 18:43:35 InnoDB: Mutexes and rw_locks use GCC atomic builtins
140526 18:43:35 InnoDB: Compressed tables use zlib 1.2.3
140526 18:43:35 InnoDB: Using Linux native AIO
140526 18:43:36 InnoDB: Initializing buffer pool, size = 40.0G
140526 18:43:38 InnoDB: Completed initialization of buffer pool
140526 18:43:38 InnoDB: highest supported file format is Barracuda.
InnoDB: Error: tried to read 512 bytes at offset 0 512.
InnoDB: Was only able to read 0.
140526 18:43:38 InnoDB: Operating system error number 22 in a file operation.
InnoDB: Error number 22 means ‘Invalid argument’.
InnoDB: Some operating system error numbers are described at
InnoDB: [url]http://dev.mysql.com/doc/refman/5.5/en/operating-system-error-codes.html[/url]
InnoDB: File operation call: ‘read’.
InnoDB: Cannot continue operation.
140526 18:43:38 mysqld_safe mysqld from pid file /srv/mysql/idb03.pid ended [HR][/HR]
Then I deleted ib_logfile{0|1} and got the following:
[HR][/HR]140526 18:54:56 mysqld_safe Starting mysqld daemon with databases from /srv/mysql
140526 18:54:56 [Note] Flashcache bypass: disabled
140526 18:54:56 [Note] Flashcache setup error is : ioctl failed

140526 18:54:56 [Note] Plugin ‘FEDERATED’ is disabled.
140526 18:54:56 InnoDB: The InnoDB memory heap is disabled
140526 18:54:56 InnoDB: Mutexes and rw_locks use GCC atomic builtins
140526 18:54:56 InnoDB: Compressed tables use zlib 1.2.3
140526 18:54:56 InnoDB: Using Linux native AIO
140526 18:54:56 InnoDB: Initializing buffer pool, size = 40.0G
140526 18:54:58 InnoDB: Completed initialization of buffer pool
140526 18:54:58 InnoDB: Log file /srv/mysql/ib_logfile0 did not exist: new to be created
InnoDB: Setting log file /srv/mysql/ib_logfile0 size to 1900 MB
InnoDB: Database physically writes the file full: wait…
InnoDB: Progress in MB: 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500 1600 1700 1800 1900
140526 18:55:00 InnoDB: Log file /srv/mysql/ib_logfile1 did not exist: new to be created
InnoDB: Setting log file /srv/mysql/ib_logfile1 size to 1900 MB
InnoDB: Database physically writes the file full: wait…
InnoDB: Progress in MB: 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500 1600 1700 1800 1900
140526 18:55:01 InnoDB: Error: Write to file /srv/mysql/ib_logfile0 failed at offset 0 0.
InnoDB: 512 bytes should have been written, only 0 were written.
InnoDB: Operating system error number 22.
InnoDB: Check that your OS and file system support files of this size.
InnoDB: Check also that the disk is not full or a disk quota exceeded.
InnoDB: Error number 22 means ‘Invalid argument’.
InnoDB: Some operating system error numbers are described at
InnoDB: [URL]http://dev.mysql.com/doc/refman/5.5/en/operating-system-error-codes.html[/URL]
140526 18:55:01 InnoDB: Assertion failure in thread 140044504708864 in file fil0fil.c line 5378
InnoDB: Failing assertion: ret
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: [URL]http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html[/URL]
InnoDB: about forcing recovery.
140526 18:55:01 - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

key_buffer_size=6442450944
read_buffer_size=131072
max_used_connections=0
max_threads=200
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 6729048 K
bytes of memory
Hope that’s ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong…
stack_bottom = (nil) thread_stack 0x31000
/usr/sbin/mysqld(my_print_stacktrace+0x39)[0x7a0799]
/usr/sbin/mysqld(handle_segfault+0x464)[0x510224]
/lib64/libpthread.so.0(+0xf710)[0x7f5ea6b27710]
/lib64/libc.so.6(gsignal+0x35)[0x7f5ea5cee925]
/lib64/libc.so.6(abort+0x175)[0x7f5ea5cf0105]
/usr/sbin/mysqld[0x8cbc4b]
/usr/sbin/mysqld[0x8fe6ed]
/usr/sbin/mysqld[0x9009b9]
/usr/sbin/mysqld[0x90137d]
/usr/sbin/mysqld[0x90209f]
/usr/sbin/mysqld[0x9040e8]
/usr/sbin/mysqld[0x84dc5d]
/usr/sbin/mysqld[0x810299]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x48)[0x680218]
/usr/sbin/mysqld[0x58feda]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0xa1c)[0x5941dc]
/usr/sbin/mysqld[0x51573b]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x5bd)[0x51919d]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x7f5ea5cdad1d]
/usr/sbin/mysqld[0x50e7f1]
The manual page at [URL]http://dev.mysql.com/doc/mysql/en/crashing.html[/URL] contains
information that should help you find out what is causing the crash.
140526 18:55:01 mysqld_safe mysqld from pid file /srv/mysql/idb03.pid ended [HR][/HR]
​What am I missing?

Hi there,

Are you running mysqld as “mysql” user? You can run “ps aux | grep mysqld” to verify.

Then check the file permission in your datadir, run “ls -l data_dir”. Make sure files are owned by “mysql”.

Is the new slave of the same server version as the existing slave?

also verify configuration file my.cnf values on new slave should be same specially innodb_log_file_size