Просмотр новости
Найдите то, что Вас интересует
Спутники
РН
SpaceX
Роскосмос
NASA
СпутникиРНSpaceXРоскосмосNASASo I realized I had not made a post about this after this situation that recently came up.
Here is the scenario: A backup was taken at midnight, they used MySQL dumps per database. Then at ten am the next day the database crashed. A series of events happened before I was called in, but they got it up to a version of the database with MyISAM tables and the IBD files missing from the tablespace.
So option 1, restoring from backup would get us to midnight and we would lose hours of data. Option 2, we reimport the 1000\'s of ibd files and keep everything. Then we had option 3, restore from backup, then apply the binlogs for recent changes.
To make it more interesting, they didn\'t have all of the ibd files I was told, and I did see some missing. So not sure how that was possible but option 2 became an invalid option. They, of course, wanted the least data loss possible, so we went with option 3.
To do this safely I started up another instance of MySQL under port 3307. This allowed me a safe place to work while traffic had read access to the MyISAM data on the port 3306 instance.
Once all the backup dump files uncompressed and imported into the 3307 instance I was able to focus on the binlog files.
At first this concept sounds much harder risky than it really is. It is actually pretty straight forward and simple.
So first you have to find the data your after. A review of the binlog files gives you a head start as to what files are relevant. In my case, somehow they managed to reset the binlog so the 117 file had 2 date ranges within it.
First for binlog review, the following command outputs the data in human-readable format.
mysqlbinlog --defaults-file=/root/.my.cnf --base64-output=DECODE-ROWS --verbose mysql-bin.000117 > review_mysql-bin.000117.sql
*Note... Be careful running the above command. Notice I have it dumping the file directly in same location as binlog. So VALIDATE that your file name is valid. This mysql-bin.000117.sql is different than this mysql-bin.000117 .sql . You will loose your binlog with the 2nd option and a space before .sql.
Now to save the data so it can be applied. Since I had several binlogs I created a file and I wanted to double-check the time ranges anyway.
mysqlbinlog --defaults-file=/root/.my.cnf --start-datetime=\"2019-07-09 00:00:00\" --stop-datetime=\"2019-07-10 00:00:00\" mysql-bin.000117 > binlog_restore.sql
mysqlbinlog --defaults-file=/root/.my.cnf mysql-bin.000118 > > binlog_restore.sql
mysqlbinlog --defaults-file=/root/.my.cnf mysql-bin.000119 > > binlog_restore.sql
mysqlbinlog --defaults-file=/root/.my.cnf --start-datetime=\"2019-07-10 00:00:00\" --stop-datetime=\"2019-07-10 10:00:00\" mysql-bin.000117 > > binlog_restore.sql
mysqlbinlog --defaults-file=/root/.my.cnf --stop-datetime=\"2019-07-10 10:00:00\" mysql-bin.000120 > > binlog_restore.sql
mysqlbinlog --defaults-file=/root/.my.cnf --stop-datetime=\"2019-07-10 10:00:00\" mysql-bin.000121 > > binlog_restore.sql
mysql --socket=/var/lib/mysql_restore/mysql.sock -e \"source /var/lib/mysql/binlog_restore.sql\"
Now I applied all the data from those binlogs for the given time ranges. The client double-checked all data and was very happy to have it all back.
Several different options existed for this situation, this happened to workout best with the client.
Once the validated all was ok on the restored version it was a simple stop both databases, moved the data directories (wanted to keep the datadir defaults intact) , chown the directories just to be safe and start up MySQL. Now the restored instance was up on port 3306.
MySQL Binlogs:: How to recover appeared first on MariaDB.org
So I realized I had not made a post about this after this situation that recently came up.
Here is the scenario: A backup was taken at midnight, they used MySQL dumps per database. Then at ten am the next day the database crashed. A series of events happened before I was called in, but they got it up to a version of the database with MyISAM tables and the IBD files missing from the tablespace.
So option 1, restoring from backup would get us to midnight and we would lose hours of data. Option 2, we reimport the 1000's of ibd files and keep everything. Then we had option 3, restore from backup, then apply the binlogs for recent changes.
To make it more interesting, they didn't have all of the ibd files I was told, and I did see some missing. So not sure how that was possible but option 2 became an invalid option. They, of course, wanted the least data loss possible, so we went with option 3.
To do this safely I started up another instance of MySQL under port 3307. This allowed me a safe place to work while traffic had read access to the MyISAM data on the port 3306 instance.
Once all the backup dump files uncompressed and imported into the 3307 instance I was able to focus on the binlog files.
At first this concept sounds much harder risky than it really is. It is actually pretty straight forward and simple.
So first you have to find the data your after. A review of the binlog files gives you a head start as to what files are relevant. In my case, somehow they managed to reset the binlog so the 117 file had 2 date ranges within it.
First for binlog review, the following command outputs the data in human-readable format.
mysqlbinlog --defaults-file=/root/.my.cnf --base64-output=DECODE-ROWS --verbose mysql-bin.000117 > review_mysql-bin.000117.sql
*Note... Be careful running the above command. Notice I have it dumping the file directly in same location as binlog. So VALIDATE that your file name is valid. This mysql-bin.000117.sql is different than this mysql-bin.000117 .sql . You will loose your binlog with the 2nd option and a space before .sql.
Now to save the data so it can be applied. Since I had several binlogs I created a file and I wanted to double-check the time ranges anyway.
mysqlbinlog --defaults-file=/root/.my.cnf --start-datetime="2019-07-09 00:00:00" --stop-datetime="2019-07-10 00:00:00" mysql-bin.000117 > binlog_restore.sql
mysqlbinlog --defaults-file=/root/.my.cnf mysql-bin.000118 >> binlog_restore.sql
mysqlbinlog --defaults-file=/root/.my.cnf mysql-bin.000119 >> binlog_restore.sql
mysqlbinlog --defaults-file=/root/.my.cnf --start-datetime="2019-07-10 00:00:00" --stop-datetime="2019-07-10 10:00:00" mysql-bin.000117 >> binlog_restore.sql
mysqlbinlog --defaults-file=/root/.my.cnf --stop-datetime="2019-07-10 10:00:00" mysql-bin.000120 >> binlog_restore.sql
mysqlbinlog --defaults-file=/root/.my.cnf --stop-datetime="2019-07-10 10:00:00" mysql-bin.000121 >> binlog_restore.sql
mysql --socket=/var/lib/mysql_restore/mysql.sock -e "source /var/lib/mysql/binlog_restore.sql"
Now I applied all the data from those binlogs for the given time ranges. The client double-checked all data and was very happy to have it all back.
Several different options existed for this situation, this happened to workout best with the client.
Once the validated all was ok on the restored version it was a simple stop both databases, moved the data directories (wanted to keep the datadir defaults intact) , chown the directories just to be safe and start up MySQL. Now the restored instance was up on port 3306.
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | MySQL How do you restore tablespace | 0 | 7.63 | 13-07-2019 |
| 2 | Migration of your data from one database to another | 0 | 5.05 | 17-11-2022 |
| 3 | Backups Using the MySQL Clone Operation | 0 | 4.93 | 28-07-2026 |
| 4 | Binary Log Compression is Safe since MySQL 8.0.34 | 0 | 11.88 | 26-03-2026 |
| 5 | Using your FRM file to get Schema and then import idb files.. | 0 | 4.63 | 12-11-2020 |
| 6 | How to downgrade MariaDB or MySQL | 0 | 6.01 | 21-05-2024 |
| 7 | MySQL & Dockers…a simple set up | 0 | 5.87 | 15-03-2020 |
| 8 | Partial physical database restore for MariaDB and MySQL | 0 | 5.64 | 02-07-2024 |
| 9 | MariaDB innovation: binlog_storage_engine | 0 | 7.56 | 16-02-2026 |