# larger LSN appears in innobackupex prepare output **URL:** \ **Category:** Percona XtraBackup\ **Created:** [February 18, 2016, 1:02pm UTC](https://forums.percona.com/t/larger-lsn-appears-in-innobackupex-prepare-output/4732 "2016-02-18T13:02:59Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![apple0315](https://avatars.discourse-cdn.com/v4/letter/a/b19c9b/32.png) [@apple0315](https://forums.percona.com/u/apple0315)\ **Post date:** [February 18, 2016, 1:02pm UTC](https://forums.percona.com/t/larger-lsn-appears-in-innobackupex-prepare-output/4732/1 "2016-02-18T13:02:59Z")
First, I took a full backup. cat xtrabackup\_checkpoints I get: backup\_type = full-prepared from\_lsn = 0 to\_lsn = 238403986 last\_lsn = 238403993 compact = 0 recover\_binlog\_info = 0 Then, prepare the backup using innobackupex --apply-log . Output: [B]160218 11:50:18 innobackupex: Starting the apply-log operation IMPORTANT: Please check that the apply-log run completes successfully. At the end of a successful apply-log run innobackupex prints “completed OK!”. innobackupex version 2.3.3 based on MySQL server 5.6.24 Linux (x86\_64) (revision id: 525ca7d) xtrabackup: cd to /root/innobackup\_2/. xtrabackup: This target seems to be not prepared yet. xtrabackup: xtrabackup\_logfile detected: size=2097152, start\_lsn=(238403986) xtrabackup: using the following InnoDB configuration for recovery: xtrabackup: innodb\_data\_home\_dir = ./ xtrabackup: innodb\_data\_file\_path = ibdata1:10M:autoextend xtrabackup: innodb\_log\_group\_home\_dir = ./ xtrabackup: innodb\_log\_files\_in\_group = 1 xtrabackup: innodb\_log\_file\_size = 2097152 xtrabackup: using the following InnoDB configuration for recovery: xtrabackup: innodb\_data\_home\_dir = ./ xtrabackup: innodb\_data\_file\_path = ibdata1:10M:autoextend xtrabackup: innodb\_log\_group\_home\_dir = ./ xtrabackup: innodb\_log\_files\_in\_group = 1 xtrabackup: innodb\_log\_file\_size = 2097152 xtrabackup: Starting InnoDB instance for recovery. xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter) InnoDB: Using atomics to ref count buffer pool pages InnoDB: The InnoDB memory heap is disabled InnoDB: Mutexes and rw\_locks use GCC atomic builtins InnoDB: Memory barrier is not used InnoDB: Compressed tables use zlib 1.2.8 InnoDB: Using CPU crc32 instructions InnoDB: Initializing buffer pool, size = 100.0M InnoDB: Completed initialization of buffer pool InnoDB: Highest supported file format is Barracuda. InnoDB: Log scan progressed past the checkpoint lsn 238403986 InnoDB: Database was not shutdown normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files… InnoDB: Restoring possible half-written data pages InnoDB: from the doublewrite buffer… InnoDB: Doing recovery: scanned up to log sequence number 238403993 (0%) InnoDB: 128 rollback segment(s) are active. InnoDB: Waiting for purge to start InnoDB: 5.6.24 started; log sequence number 238403993 xtrabackup: Last MySQL binlog file position 481, file name mysql-bin.000002 xtrabackup: starting shutdown with innodb\_fast\_shutdown = 1 InnoDB: FTS optimize thread exiting. InnoDB: Starting shutdown… InnoDB: Shutdown completed; log sequence number 238405699 xtrabackup: using the following InnoDB configuration for recovery: xtrabackup: innodb\_data\_home\_dir = ./ xtrabackup: innodb\_data\_file\_path = ibdata1:10M:autoextend xtrabackup: innodb\_log\_group\_home\_dir = ./ xtrabackup: innodb\_log\_files\_in\_group = 2 xtrabackup: innodb\_log\_file\_size = 50331648 InnoDB: Using atomics to ref count buffer pool pages InnoDB: The InnoDB memory heap is disabled InnoDB: Mutexes and rw\_locks use GCC atomic builtins InnoDB: Memory barrier is not used InnoDB: Compressed tables use zlib 1.2.8 InnoDB: Using CPU crc32 instructions InnoDB: Initializing buffer pool, size = 100.0M InnoDB: Completed initialization of buffer pool InnoDB: Setting log file ./ib\_logfile101 size to 48 MB InnoDB: Setting log file ./ib\_logfile1 size to 48 MB InnoDB: Renaming log file ./ib\_logfile101 to ./ib\_logfile0 InnoDB: New log files created, LSN=238405699 InnoDB: Highest supported file format is Barracuda. InnoDB: 128 rollback segment(s) are active. InnoDB: Waiting for purge to start InnoDB: 5.6.24 started; log sequence number [COLOR=#FF0000]238406156 xtrabackup: starting shutdown with innodb\_fast\_shutdown = 1 InnoDB: FTS optimize thread exiting. InnoDB: Starting shutdown… InnoDB: Shutdown completed; log sequence number [COLOR=#FF0000]238406166 160218 11:50:22 completed OK![/B] ## Then I restored the database using the prepared bakup. Then I inserted one record into a table. Then I run show engine innodb status\G Output: [B]— LOG Log sequence number [COLOR=#00FF00]238405798 Log flushed up to [COLOR=#00FF00]238405798 Pages flushed up to [COLOR=#00FF00]238405798 Last checkpoint at [COLOR=#00FF00]238405798 Max checkpoint age 80826164 Checkpoint age target 78300347 Modified age 0 Checkpoint age 0 0 pending log writes, 0 pending chkp writes 19 log i/o’s done, 0.00 log i/o’s/second[/B] My question: Why the green LSN is smaller than the red LSN. I can understand that the LSN will increase during the backup preparation. But new LSN in the restored database should start from the largest LSN generated in preparation which should be the red LSN I think. How come the green LSN is smaller than the red ones? Thanks.