How to fix CR_NET_PACKET_TOO_LARGE (2020): Got packet bigger than max_allowed_packet in MySQL

MySQLINTERMEDIATEMEDIUMUpdated Dec 22, 2025· 193 views

This MySQL client error occurs when a network packet exceeds the maximum allowed size configured in the server. The error typically appears during large data transfers, BLOB/CLOB operations, or bulk imports when individual packets exceed the max_allowed_packet limit. Increasing this server variable or breaking operations into smaller chunks resolves the issue.

Quick fix

Fixes CR_NET_PACKET_TOO_LARGE (2020): Got packet bigger than max_allowed_packet

-- Check server max_allowed_packet
SHOW VARIABLES LIKE 'max_allowed_packet';

-- Check global and session values
SELECT @@global.max_allowed_packet, @@session.max_allowed_packet;

-- Check in bytes (divide by 1024*1024 for MB)
SELECT @@global.max_allowed_packet / 1024 / 1024 as max_mb;

-- Common default values:
-- MySQL 5.7: 4MB (4194304 bytes)
-- MySQL 8.0: 64MB (67108864 bytes)
-- MariaDB: 16MB (16777216 bytes)
  1. Check current max_allowed_packet settings
  2. Increase max_allowed_packet on MySQL server
  3. Set max_allowed_packet for specific sessions
  4. Break large operations into smaller chunks
mysql — error
-- Check server max_allowed_packet
SHOW VARIABLES LIKE 'max_allowed_packet';
-- Check global and session values
SELECT @@global.max_allowed_packet, @@session.max_allowed_packet;
-- Check in bytes (divide by 1024*1024 for MB)
SELECT @@global.max_allowed_packet / 1024 / 1024 as max_mb;
-- Common default values:
-- MySQL 5.7: 4MB (4194304 bytes)
-- MySQL 8.0: 64MB (67108864 bytes)
-- MariaDB: 16MB (16777216 bytes)
CR_NET_PACKET_TOO_LARGE (2020): Got packet bigger than max_allowed_packet

What this error means

The CR_NET_PACKET_TOO_LARGE (2020) error is a MySQL client error that occurs when the server receives a network packet larger than its configured `max_allowed_packet` limit. This limit controls the maximum size of a single packet that can be sent or received by the MySQL server. Key aspects of this error: 1. **Packet Size Limits**: MySQL communicates with clients using network packets. Each SQL statement, result set, or data transfer is broken into packets. The `max_allowed_packet` variable sets the maximum size for any single packet. 2. **Large Operations**: This error commonly occurs during: - Inserting or updating large BLOB/CLOB/TEXT columns - Bulk data imports (LOAD DATA INFILE, large INSERT statements) - Replication operations with large rows - Stored procedures returning large result sets - Binary log events exceeding the limit 3. **Client-Server Communication**: Both client and server have packet size limits. If either side exceeds its limit, the connection fails with this error. 4. **Default Values**: The default `max_allowed_packet` is typically 4MB-16MB depending on MySQL version and configuration, which may be insufficient for modern applications handling large media files or datasets.

Typical symptoms

  • MySQL client fails with "CR_NET_PACKET_TOO_LARGE (2020): Got packet bigger than max_allowed_packet"
  • Large INSERT or UPDATE statements fail during execution
  • BLOB/CLOB/TEXT column operations fail with packet size errors
  • LOAD DATA INFILE commands fail for large files
  • Replication stops with "Got packet bigger than max_allowed_packet" errors
  • Stored procedures or functions returning large result sets fail
  • Error occurs intermittently with specific data sizes
  • Application works with small datasets but fails with larger ones
  • MySQL dump/restore operations fail during large table transfers

Common causes

  1. Server max_allowed_packet setting is too small for the operation
  2. Client max_allowed_packet setting differs from server setting
  3. Large BLOB, CLOB, TEXT, or JSON column values exceeding packet limit
  4. Bulk INSERT statements with many rows or large values
  5. Replication packets exceeding max_allowed_packet on slave server
  6. Binary log events larger than max_allowed_packet
  7. MySQL dump files with large row sizes
  8. Stored procedures returning large result sets
  9. Application sending large prepared statements or parameter sets
  10. MySQL version differences with different default packet sizes

How to fix "CR_NET_PACKET_TOO_LARGE (2020): Got packet bigger than max_allowed_packet"

1Check current max_allowed_packet settings

First, check the current max_allowed_packet value on both server and client:

sql
-- Check server max_allowed_packet
SHOW VARIABLES LIKE 'max_allowed_packet';

-- Check global and session values
SELECT @@global.max_allowed_packet, @@session.max_allowed_packet;

-- Check in bytes (divide by 1024*1024 for MB)
SELECT @@global.max_allowed_packet / 1024 / 1024 as max_mb;

-- Common default values:
-- MySQL 5.7: 4MB (4194304 bytes)
-- MySQL 8.0: 64MB (67108864 bytes)
-- MariaDB: 16MB (16777216 bytes)

Also check client settings if available in your connection configuration.

2Increase max_allowed_packet on MySQL server

Increase the max_allowed_packet value in MySQL configuration:

bash
# Edit MySQL configuration file
sudo nano /etc/mysql/my.cnf
# or
sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf
# or
sudo nano /etc/my.cnf

# Add or modify under [mysqld] section
[mysqld]
max_allowed_packet = 256M

# Common values:
# 64M  - Moderate applications
# 128M - Applications with medium-sized BLOBs
# 256M - Large media files or datasets
# 512M - Very large operations
# 1G   - Maximum recommended for most systems

# Also set for client connections (optional)
[client]
max_allowed_packet = 256M

[mysql]
max_allowed_packet = 256M

Restart MySQL to apply changes:

bash
# Restart MySQL service
sudo systemctl restart mysql
# or
sudo service mysql restart

# Verify new setting
mysql -e "SHOW VARIABLES LIKE 'max_allowed_packet';"

Note: Very large values (>1GB) may cause memory issues or be truncated by operating system limits.

3Set max_allowed_packet for specific sessions

For temporary fixes or specific operations, set max_allowed_packet at session level:

sql
-- Set for current session only
SET SESSION max_allowed_packet = 268435456; -- 256MB

-- Or set globally without restart (affects new connections)
SET GLOBAL max_allowed_packet = 268435456;

-- Verify the change took effect
SELECT @@session.max_allowed_packet;

In application code, set the parameter during connection:

php
// PHP PDO example
$pdo = new PDO($dsn, $user, $pass, [
    PDO::MYSQL_ATTR_INIT_COMMAND => "SET SESSION max_allowed_packet=268435456"
]);

// PHP mysqli example
$mysqli = new mysqli($host, $user, $pass, $db);
$mysqli->query("SET SESSION max_allowed_packet=268435456");
python
# Python MySQL connector
import mysql.connector

config = {
    'user': 'username',
    'password': 'password',
    'database': 'mydb',
    'connection_timeout': 30
}

connection = mysql.connector.connect(**config)
cursor = connection.cursor()
cursor.execute("SET SESSION max_allowed_packet=268435456")
javascript
// Node.js mysql2
const mysql = require('mysql2/promise');

const connection = await mysql.createConnection({
  host: 'localhost',
  user: 'root',
  password: 'password',
  database: 'mydb'
});

await connection.execute('SET SESSION max_allowed_packet=268435456');
4Break large operations into smaller chunks

For operations that consistently exceed limits, implement chunking:

sql
-- Instead of one large INSERT:
INSERT INTO large_table VALUES (1, 'huge data...'), (2, 'more data...'), ...;

-- Use multiple smaller INSERTs:
INSERT INTO large_table VALUES (1, 'chunk1...');
INSERT INTO large_table VALUES (2, 'chunk2...');
-- etc.

-- Or use transactions with chunked inserts:
START TRANSACTION;
INSERT INTO large_table VALUES (1, 'data1');
INSERT INTO large_table VALUES (2, 'data2');
-- ... up to reasonable chunk size
COMMIT;

For BLOB operations, consider:

sql
-- Store large files in chunks
CREATE TABLE file_chunks (
    file_id INT,
    chunk_number INT,
    chunk_data LONGBLOB,
    PRIMARY KEY (file_id, chunk_number)
);

-- Or use file system storage with path references
ALTER TABLE documents ADD COLUMN file_path VARCHAR(500);
-- Store files on disk, keep only metadata in database

Application-level chunking example:

php
// PHP chunked insert example
$largeData = [...]; // Array of data
$chunkSize = 1000;

foreach (array_chunk($largeData, $chunkSize) as $chunk) {
    $placeholders = implode(',', array_fill(0, count($chunk), '(?, ?)'));
    $stmt = $pdo->prepare("INSERT INTO table (col1, col2) VALUES $placeholders");
    
    $flattened = [];
    foreach ($chunk as $row) {
        $flattened[] = $row[0];
        $flattened[] = $row[1];
    }
    
    $stmt->execute($flattened);
}
5Configure replication and binary logging

For replication environments, ensure consistent max_allowed_packet settings:

bash
# On master server my.cnf
[mysqld]
max_allowed_packet = 256M

# On slave server my.cnf
[mysqld]
max_allowed_packet = 256M
slave_max_allowed_packet = 256M  # MariaDB specific

# For MySQL replication thread
[mysqld]
slave_max_allowed_packet = 256M

Check and adjust binary logging:

sql
-- Check binlog format
SHOW VARIABLES LIKE 'binlog_format';

-- ROW-based replication may create larger events
-- Consider using MIXED or STATEMENT format if packet size is issue

-- Check max_binlog_size
SHOW VARIABLES LIKE 'max_binlog_size';

-- Ensure max_binlog_size is reasonable (default 1GB)
-- In my.cnf:
max_binlog_size = 100M

For large transactions, consider:

sql
-- Split large transactions
START TRANSACTION;
-- Some operations
COMMIT;

START TRANSACTION;
-- More operations
COMMIT;

-- Instead of one huge transaction
6Optimize database schema and queries

Consider schema changes to avoid large packet issues:

sql
-- Use appropriate data types
-- Instead of LONGTEXT for all text, use:
VARCHAR(255)  -- For short text
TEXT          -- Up to 64KB
MEDIUMTEXT    -- Up to 16MB
LONGTEXT      -- Up to 4GB (may cause packet issues)

-- Similarly for BLOB:
TINYBLOB      -- Up to 255 bytes
BLOB          -- Up to 64KB
MEDIUMBLOB    -- Up to 16MB
LONGBLOB      -- Up to 4GB

-- Consider compression for large text/BLOB columns
ALTER TABLE documents 
MODIFY COLUMN content LONGBLOB 
COMPRESSION='zlib';

-- Or use COMPRESS()/UNCOMPRESS() functions
INSERT INTO table (compressed_data) 
VALUES (COMPRESS('large text data...'));

SELECT UNCOMPRESS(compressed_data) FROM table;

-- Partition large tables
CREATE TABLE large_table (
    id INT,
    data TEXT,
    created_at DATETIME
) PARTITION BY RANGE (YEAR(created_at)) (
    PARTITION p2023 VALUES LESS THAN (2024),
    PARTITION p2024 VALUES LESS THAN (2025),
    PARTITION p2025 VALUES LESS THAN (2026)
);

Query optimization:

sql
-- Use LIMIT for large result sets
SELECT * FROM large_table LIMIT 1000;

-- Fetch in batches
SELECT * FROM large_table WHERE id > ? LIMIT 1000;

-- Avoid SELECT * on tables with large columns
SELECT id, name, created_at FROM large_table;
-- Instead of SELECT *

-- Use indexed columns in WHERE clauses
SELECT * FROM large_table WHERE indexed_column = ?;

Advanced notes

The CR_NET_PACKET_TOO_LARGE error has several advanced considerations:

1. Operating System Limits: On Linux, check ulimit -a for process memory limits. The max_allowed_packet cannot exceed available memory. Also check /proc/sys/net/core/rmem_max and /proc/sys/net/core/wmem_max for socket buffer limits.

2. MySQL Memory Allocation: MySQL allocates buffers based on max_allowed_packet. Very large values (>1GB) can cause out-of-memory errors, especially with many concurrent connections. Calculate: total_memory_usage = max_connections * max_allowed_packet * 2 (read and write buffers).

3. Replication Topology: In complex replication setups (chain, star, circular), ensure all servers have consistent max_allowed_packet values. The smallest value in the chain determines the effective limit.

4. Group Replication and InnoDB Cluster: MySQL Group Replication has additional packet size considerations. Check group_replication_communication_max_message_size which defaults to 10MB.

5. MySQL Router and ProxySQL: When using proxies, packet size limits may be enforced at multiple layers. Configure all components consistently.

6. Character Set Impact: UTF-8 multi-byte characters increase packet size. A VARCHAR(255) in utf8mb4 can use up to 1020 bytes (255 * 4 bytes).

7. Compression Protocols: Enable --compress client option or use mysql_compression=1 in connectors to reduce network packet size at the cost of CPU.

8. Monitoring and Alerting: Monitor packet size usage:

sql
-- Check for large packets in performance_schema
SELECT * FROM performance_schema.events_statements_summary_by_digest 
WHERE SUM_TIMER_WAIT > 1000000000 
ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;

9. Version-Specific Behaviors: MySQL 8.0 increased default max_allowed_packet to 64MB. MariaDB may have different defaults and additional variables like slave_max_allowed_packet.

For production systems, conduct load testing with realistic data sizes to determine optimal max_allowed_packet values before deployment.

Frequently asked questions

What does "CR_NET_PACKET_TOO_LARGE (2020): Got packet bigger than max_allowed_pac" mean?
The CR_NET_PACKET_TOO_LARGE (2020) error is a MySQL client error that occurs when the server receives a network packet larger than its configured max_allowed_packet limit. This limit controls the maximum size of a single packet that can be sent or received by the MySQL server. Key aspects of this error: 1.
How do I fix "CR_NET_PACKET_TOO_LARGE (2020): Got packet bigger than max_allowed_pac"?
This MySQL client error occurs when a network packet exceeds the maximum allowed size configured in the server. The error typically appears during large data transfers, BLOB/CLOB operations, or bulk imports when individual packets exceed the max_allowed_packet limit. Increasing this server variable or breaking operations into smaller chunks resolves the issue.
What causes "CR_NET_PACKET_TOO_LARGE (2020): Got packet bigger than max_allowed_pac"?
Server max_allowed_packet setting is too small for the operation Client max_allowed_packet setting differs from server setting Large BLOB, CLOB, TEXT, or JSON column values exceeding packet limit
Is the "CR_NET_PACKET_TOO_LARGE (2020): Got packet bigger than max_allowed_pac" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading