우선 A서버가 메인이고 B가 백업용입니다. 그리고 A서버와 B서버는 rsync로 15분마다 동기화 되고 매일 밤마다 백업은 따로 실시합니다. (여기선 mysqldump를 씁니다.)
작동 중인 A서버에서 mysql DB파일을 그대로 rsync로 B 서버에 덮어쓰면 문제가 생기려나요? 하드웨어는 다르지만 mysql버전과 사용자 id, 비번은 같습니다.
우선 A서버가 메인이고 B가 백업용입니다. 그리고 A서버와 B서버는 rsync로 15분마다 동기화 되고 매일 밤마다 백업은 따로 실시합니다. (여기선 mysqldump를 씁니다.)
작동 중인 A서버에서 mysql DB파일을 그대로 rsync로 B 서버에 덮어쓰면 문제가 생기려나요? 하드웨어는 다르지만 mysql버전과 사용자 id, 비번은 같습니다.
강제적으로 메인서버를 죽이고 백업서버를 돌렸을때 잘 돌아간다면 문제 없지만
백업서버가 재대로 안돌아간다면 백업을 한 의미는 화일카피밖에 안될 것입니다.
For storage engines that represent each table using its own files, tables can be backed up by copying those files.
For example, MyISAM tables are stored as files, so it is easy to do a backup by copying files (*.frm, *.MYD, and *.MYI files).
To get a consistent backup, stop the server or lock and flush the relevant tables:
FLUSH TABLES tbl_list WITH READ LOCK;
You need only a read lock; this enables other clients to continue to query the tables while you are making a copy of the files
in the database directory. The flush is needed to ensure that the all active index pages are written to disk before you start the backup.
See Section 13.3.5, “LOCK TABLES and UNLOCK TABLES Syntax”, and Section 13.7.6.3, “FLUSH Syntax”.
You can also create a binary backup simply by copying all table files, as long as the server isn't updating anything.
(But note that table file copying methods do not work if your database contains InnoDB tables.
Also, even if the server is not actively updating data, InnoDB may still have modified data cached in memory and not flushed to disk.)
요약해보면 DB파일을 복사하려면 서버가 업데이트되지 않아야 하고, InnoDB는 그러한 경우에도 flush가 안되서 동작을 하지 않는다... 죠