I have not had much experience switching the myisam_data_pointer_size option from 4 to 6.

Simply put, I think you got it right based on the Documentation. Here is why:

According to the MySQL Documentation 5.5 on myisam_data_pointer_size:

The default pointer size in bytes, to be used by CREATE TABLE for MyISAM tables when no MAX_ROWS option is specified. This variable cannot be less than 2 or larger than 7. The default value is 6. See Section C.5.2.12, “The table is full”.

The fact that you changed it from 4 shows that the table was created originally in an earlier version of MySQL (default pointer size is 4 in MySQL 4.1).

Looking at the additional MySQL 4.1 reference for “The table is full”:

You are using a MyISAM table and the space required for the table exceeds what is permitted by the internal pointer size. MyISAM creates tables to permit up to 4GB by default, but this limit can be changed up to the maximum permissible size of 65,536TB (2567 – 1 bytes).

If you need a MyISAM table that is larger than the default limit and your operating system supports large files, the CREATE TABLE statement supports AVG_ROW_LENGTH and MAX_ROWS options. See Section 12.1.5, “CREATE TABLE Syntax”. The server uses these options to determine how large a table to permit.

If the pointer size is too small for an existing table, you can change the options with ALTER TABLE to increase a table's maximum permissible size. See Section 12.1.2, “ALTER TABLE Syntax”.

Since you ran the change and MySQL did not keel over in agony, you must have gotten it right.

CAVEAT #1

I noticed the table characteristics you posted

• Rows: 1786679 (that's 1,786,679 rows)
• Avg_row_length: 2403
• Row_format: Dynamic

What disturbs me is the average length. Why? I have easily seen 1 Billion Row MyISAM tables and never had a client switch its pointer size. This may be a good time to reevaluate the table's layout.

Here are some possible ways to shrink the table without touching the pointer size ?

• Does the table have a lot of TEXT/BLOB fields ?
• Could those TEXT/BLOB field be removed an placed in another table ?
• Could the table stand some normalization ?
• Do you have INT fields that could be shrunk to TINY, SMALLINT, or MEDIUMINT ?

CAVEAT #2

The next time you get table is full, please do not automatically assume that the table reached its internal limit. Always check the datadir to make sure the disk itself is not full.

You can only use a single storage engine type per mongod instance. There is only a single dbPath setting for a mongod deployment, and you cannot mix & match data files from different storage engines within the same data path.

However, you can use different storage engine configurations within members of a replica set (for example, mmap primary and WiredTiger secondaries). If you do this, you should be wary of differences in performance and be sure to test thoroughly in a QA/staging environment with representative workload.

Another available option is to set storage-engine specific options when creating a collection. For example, you could override the instance-level defaults for WiredTiger and set different options for specific collections (i.e. higher level of compression, or perhaps no compression).