# MySQL 5.7.23 replica failed to execute load data infile

**URL:** <https://forums.percona.com/t/mysql-5-7-23-replica-failed-to-execute-load-data-infile/6728>\
**Category:** Percona Server for MySQL 5.7\
**Created:** [December 7, 2018, 9:40am UTC](https://forums.percona.com/t/mysql-5-7-23-replica-failed-to-execute-load-data-infile/6728 "2018-12-07T09:40:19Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![AlexM](https://avatars.discourse-cdn.com/v4/letter/a/3da27b/32.png) [@AlexM](https://forums.percona.com/u/AlexM)\
**Post date:** [December 7, 2018, 9:40am UTC](https://forums.percona.com/t/mysql-5-7-23-replica-failed-to-execute-load-data-infile/6728/1 "2018-12-07T09:40:19Z")

</div>

Hello,

Server migrated from Percona MySQL 5.7.19 to 5.7.23 failed to apply Load Data infile during replication.  
Specs:

- Master-master replication
- Statement based replication
- Percona MySQL 5.7.23 (both servers)
- CentOS 6.9

Error:  
Error ‘The MySQL server is running with the --secure-file-priv option so it cannot execute this statement’ on query. Default database: ‘xxxxxx’. Query: ‘LOAD DATA INFILE ‘/var/lib/mysql/SQL\_LOAD-597abdb6-26dd-11e8-bac8-f403434e0298-206-1.data’ IGNORE INTO TABLE `xxxxxx` FIELDS TERMINATED BY ‘,’ ENCLOSED BY ‘’ ESCAPED BY ‘\’ LINES TERMINATED BY ‘\n’ (`xxx,xxx`) SET `create_date`= now(), `create_user`= ‘xxxxxxxxx’, `update_user`= ‘xxxxxxx’’

The systems were previously running Percona MySQL 5.7.19. We did not experience this problem with that version.

Is this a Percona MySQL 5.7.23 bug?

Thank you,  
Alex Malberty  
BabyCenter LLC  
Johnson&Johnson

---

<div class="post-metadata">

**Author:** ![AlexM](https://avatars.discourse-cdn.com/v4/letter/a/3da27b/32.png) [@AlexM](https://forums.percona.com/u/AlexM)\
**Post date:** [December 10, 2018, 9:28am UTC](https://forums.percona.com/t/mysql-5-7-23-replica-failed-to-execute-load-data-infile/6728/2 "2018-12-10T09:28:13Z")

</div>

As a temporary fix, we setup secure\_file\_priv = ‘’, but I would like to revert that change.

---

<div class="post-metadata">

**Author:** ![vinicius.grippa](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/vinicius.grippa/32/1246_2.png) [@vinicius.grippa](https://forums.percona.com/u/vinicius.grippa)\
**Post date:** [December 11, 2018, 12:58pm UTC](https://forums.percona.com/t/mysql-5-7-23-replica-failed-to-execute-load-data-infile/6728/3 "2018-12-11T12:58:30Z")

</div>

Hi Alex,

I was able to reproduce your issue. This is indeed a bug and it affects MySQL upstream as well, here is the bug description:

[url][MySQL Bugs: #92132: secure-file-priv breaks LOAD DATA INFILE replication in statement mode on 5.7.23](https://bugs.mysql.com/bug.php?id=92132%5B/url%5D)

The workaround as you mentioned is to set secure\_file\_priv but this might be a security issue. Another option is to set the binlog\_format to ROW os MIXED.

---

<div class="post-metadata">

**Author:** ![AlexM](https://avatars.discourse-cdn.com/v4/letter/a/3da27b/32.png) [@AlexM](https://forums.percona.com/u/AlexM)\
**Post date:** [December 11, 2018, 2:15pm UTC](https://forums.percona.com/t/mysql-5-7-23-replica-failed-to-execute-load-data-infile/6728/4 "2018-12-11T14:15:48Z")

</div>

Thank you Vinicious. We will change replication to ROW based.