This page documents system variables related to the XtraDB/InnoDB storage engine. For options that are not system variables, see InnoDB Options.
Description: If the server supports InnoDB tables, will be set to YES, otherwise will be set to NO. Removed in MariaDB 10.0, use the Information Schema PLUGINS table or SHOW ENGINES instead.
Description: Setting this to 1 results in the built-in InnoDB storage engine being ignored. In some versions of MariaDB, XtraDB is the default and is always present, so this variable is ignored and setting it results in a warning. From MariaDB 10.0.1 to MariaDB 10.0.8, when InnoDB was the default instead of XtraDB, this variable needed to be set. Usually used in conjunction with the plugin-load=innodb=ha_innodb option to use the InnoDB plugin.
reflex Similar to innodb_max_dirty_pages_pct flushing but flushes blocks constantly and contiguously based on the oldest modified age. If the age exceeds 1/2 of the maximum age capacity, flushing will be weak contiguous. If the age exceeds 3/4, flushing will be strong. Strength can be adjusted by the variable innodb_io_capacity.
estimate The default, and independent of innodb_io_capacity. If the oldest modified age exceeds 1/2 of the maximum age capacity, blocks will be flushed every second at a rate determined by the number of modified blocks, LSN progress speed and the average age of all modified blocks.
keep_average Attempts to keep the I/O rate constant by using a shorter loop cycle of one tenth of a second. Designed for SSD cards.
Description: If set to 1, the default, the server will dynamically adjust the flush rate of dirty pages in the InnoDB buffer pool. This assists to reduce brief bursts of I/O activity.
Description: Adaptive flushing is enabled when this this low water mark percentage of the InnoDB redo log capacity is reached.
Description: Determines the method of flushing dirty blocks from the InnoDB buffer pool. If set to native or 0, the original InnoDB method is used. The maximum checkpoint age is determined by the total length of all transaction log files. When the checkpoint age reaches the maximum checkpoint age, blocks are flushed. This can cause lag if there are many updates per second and many blocks with an almost identical age need to be flushed. If set to estimate or 1, the default, the oldest modified age will be compared with the maximum age capacity. If it's more than 1/4 of this age, blocks are flushed every second. The number of blocks flushed is determined by the number of modified blocks, the LSN progress speed and the average age of all modified blocks. It's therefore independent of the innodb_io_capacity for the 1-second loop, but not entirely so for the 10-second loop. If set to keep_average or 2, designed specifically for SSD cards, a shorter loop cycle is used in an attempt to keep the I/O rate constant. Removed in MariaDB 10.0/XtraDB 5.6 and replaced with InnoDB flushing method from MySQL 5.6.
Description: If set to 1, the default, the InnoDB hash index is enabled.
Description: Specifies the number of partitions for use in adaptive searching. If set to 1, no extra partitions are created. XtraDB-only. From MariaDB 10.2.6 (which uses InnoDB as default instead of XtraDB), this is an alias for innodb_adaptive_hash_index_parts to allow for easier upgrades.
Description: Specifies the number of partitions for use in adaptive searching. If set to 1, no extra partitions are created.
Description: Maximum time in microseconds to automatically adjust the innodb_thread_sleep_delay value to, based on the workload. Useful in extremely busy systems with hundreds of thousands of simultaneous connections.
Description: Size in bytes of the InnoDB memory pool used for storing information about internal data structures. Defaults to 8MB, if your application has many tables and a large structure, and this is exceeded, operating system memory will be allocated and warning messages written to the error log, in which case you should increase this value. Deprecated in MariaDB 10.0 and removed in MariaDB 10.2 along with InnoDB's internal memory allocator.
Description: Time in seconds between auto-commits for idle connections using the InnoDB memcached interface (not implemented in MariaDB).
Description: Renamed innodb_buffer_pool_restore_at_startup since XtraDB 5.5.10-20.1, which was in turn replaced by innodb_buffer_pool_load_at_startup in MariaDB 10.0.
Description: Size in MB to increment an auto-extending shared tablespace file when it becomes full. If innodb_file_per_table was set to 1, this setting does not apply to the resulting per-table tablespace files, which are automatically extended in their own way.
Description: Check if spaces needs scrubbing every innodb_background_scrub_data_check_interval seconds. See Data Scrubbing.
Description: Enable scrubbing of compressed data by background threads (same as encryption_threads). See Data Scrubbing.
Description: Scrub spaces that were last scrubbed longer than this number of seconds ago. See Data Scrubbing.
Description: Enable scrubbing of uncompressed data by background threads (same as encryption_threads). See Data Scrubbing.
Description: If set to 1 (0 is default), XtraDB will wait until the LRU dump is completely restored upon restart before reporting back to the server that it has successfully started up. Available with XtraDB only, not InnoDB.
Description: Determines how often (as a percent) the buffer pool dump status should be printed in the logs. For example, 10 means that the buffer pool dump status is printed when every 10% of the number of buffer pool pages are dumped. The default is 0 (only start and end status is printed).
Description: Whether to record pages cached in the buffer pool on server shutdown, which reduces the length of the warmup the next time the server starts. The related innodb_buffer_pool_load_at_startup specifies whether the buffer pool is automatically warmed up at startup.
Description: Immediately records pages stored in the buffer pool. The related innodb_buffer_pool_load_now does the reverse, and will immediately warm up the buffer pool.
Description: Dump only the hottest N% of each buffer pool, defaults to 100 until MariaDB 10.2.1. Since MariaDB 10.2.2, defaults to 25% along with the changes to innodb_buffer_pool_dump_at_shutdown and innodb_buffer_pool_load_at_startup.
Description: Evict pages from the buffer pool. If set to "uncompressed" then all uncompressed pages are evicted from the buffer pool. Variable to be used only for testing. Only exists in DEBUG builds.
Valid Values: "" or "uncompressed"
Description: The file that holds the buffer pool list of page numbers set by innodb_buffer_pool_dump_at_shutdown and innodb_buffer_pool_dump_now.
Description: If innodb_buffer_pool_size is set to more than 1GB, innodb_buffer_pool_instances divides the InnoDB buffer pool into this many instances. The default was 1 in MariaDB 5.5, but for large systems with buffer pools of many gigabytes, many instances can help reduce contention concurrency. The default is 8 in MariaDB 10 (except on Windows 32-bit, where it varies according to innodb_buffer_pool_size, or from MariaDB 10.2.2, where it is set to 1 if innodb_buffer_pool_size < 1GB). Each instance manages its own data structures and takes an equal portion of the total buffer pool size, so for example if innodb_buffer_pool_size is 4GB and innodb_buffer_pool_instances is set to 4, each instance will be 1GB. Each instance should ideally be at least 1GB in size.
Description: Aborts the process of restoring buffer pool contents started by innodb_buffer_pool_load_at_startup or innodb_buffer_pool_load_now.
Description: Specifies whether the buffer pool is automatically warmed up when the server starts by loading the pages held earlier. The related innodb_buffer_pool_dump_at_shutdown specifies whether pages are saved at shutdown.
Description: Immediately warms up the buffer pool by loading the stored data pages. The related innodb_buffer_pool_dump_now does the reverse, and immediately records pages stored in the buffer pool.
Description: When set to 1 (0 is default), XtraDB will preallocate pages in the buffer pool on starting up so that NUMA allocation decisions are made while the buffer cache is still clean. XtraDB only. This option was made ineffective in MariaDB 10.0.23. Added as a deprecated and ignored option in MariaDB 10.2.6 (which uses InnoDB as default instead of XtraDB) to allow for easier upgrades.
Description: Time in seconds between automatic buffer pool dumps. If set to a non-zero value, XtraDB will also perform an automatic restore of the buffer pool at startup. If set to 0, automatic dumps are not performed, nor automatic restores on startup. Replaced by innodb_buffer_pool_load_at_startup in MariaDB 10.0.
Description: Used with Percona's SHM buffer pool patch in XtraDB 5.5. Was shortly deprecated in XtraDB XtraDB 5.5.13-20.4, and removed in XtraDB 5.6. XtraDB only.
Description: Used with Percona's SHM buffer pool patch in XtraDB 5.5. Later deprecated in XtraDB 5.5, and removed in XtraDB 5.6.
Description: InnoDB buffer pool size in bytes. The primary value to adjust on a database server with entirely/primarily XtraDB/InnoDB tables, can be set up to 80% of the total memory in these environments. If set to 2 GB or more, you will probably want to adjust innodb_buffer_pool_instances as well. See the XtraDB/InnoDB Buffer Pool for more on setting this variable, and also Setting Innodb Buffer Pool Size Dynamically if doing so dynamically.
Description: Maximum size of the XtraDB/InnoDB Change Buffer as a percentage of the total buffer pool. The default is 25%, and this can be increased up to 50% for servers with high write activity, and lowered down to 0 for servers used exclusively for reporting.
Description: Sets how InnoDB change buffering is performed. See XtraDB/InnoDB Change Buffering for details on the settings.
Description: If set to 1, an XtraDB/InnoDB Change Buffering debug flag is set. 1 forces all changes to the change buffer, while 2 causes a crash at merge. 0, the default, indicates no flag is set. Only available in debug builds.
Description: The maximum value of the checkpoint age. If set to 0, has no effect. Removed in MariaDB 10.0/XtraDB 5.6 and replaced with InnoDB flushing method from MySQL 5.6.
Removed: MariaDB 10.0/XtraDB 5.6 - replaced with InnoDB flushing method from MySQL 5.6.
Description: A replacement for InnoDB's innodb_checksums and XtraDB's innodb_fast_checksum, specifies how the InnoDB tablespace checksum is generated and verified.
innodb: Backwards compatible with earlier versions.
crc32: A newer, faster algorithm, but incompatible with earlier versions. Tablespace blocks will be converted to the new format over time, meaning that a mix of checksums may be present.
full_crc32: From MariaDB 10.4.3. Permits encryption to be supported over a SPATIAL INDEX, which crc32 does not support. Newly-created data files will carry a flag that indicates that all pages of the file will use a full CRC-32C checksum over the entire page contents (excluding the bytes where the checksum is stored, at the very end of the page). Such files will always use that checksum, no matter what the parameter innodb_checksum_algorithm is assigned to. ROW_FORMAT=COMPRESSED tables will only use the old format. These tables do not support new features, such as larger innodb_page_size or instant ADD/DROP COLUMN. Also cleans up the MariaDB tablespace flags - flags are reserved to store the page_compressed compression algorithm, and to store the compressed payload length, so that checksum can be computed over the compressed (and possibly encrypted) stream and can be validated without decrypting or decompressing the page. In the full_crc32 format, there no longer are separate before-encryption and after-encryption checksums for pages. The single checksum is computed on the page contents that is written to the file.See MDEV-12026 for details.
none: Writes a constant rather than calculate a checksum.
strict_*: The strict_* options are the same as the regular options, but InnoDB will halt if it comes across a mix of checksum values. These are faster, as both new and old checksum values are not required, but can only be used when setting up tablespaces for the first time.
Description: By default, InnoDB performs checksum validation on all pages read from disk, which provides extra fault tolerance. You would usually want this set to 1 in production environments, although setting it to 0 can provide marginal performance improvements. Deprecated and functionality replaced by innodb_checksum_algorithm in MariaDB 10.0, and should be removed to avoid conflicts. ON is equivalent to --innodb_checksum_algorithm=innodb and OFF to --innodb_checksum_algorithm=none.
Description: XtraDB has enhanced page cleaner heuristics, and with these in place, the default InnoDB adaptive flushing may be too aggressive. As a result, a new LSN age factor formula has been introduced, controlled by this variable. The default setting, high_checkpoint, uses the new formula, while the alternative, legacy, uses the original algorithm. XtraDB only. Added as a deprecated and ignored option in MariaDB 10.2.6 (which uses InnoDB as default instead of XtraDB) to allow for easier upgrades.
Description: If set to ON (OFF is default), per-index compression statistics are stored in the INFORMATION_SCHEMA.INNODB_CMP_PER_INDEX table. These are expensive to record, so this setting should only be changed with care, such as for performance tuning on development or slave servers.
Description: Limit to the number of transaction threads that can can commit simultaneously. 0, the default, imposes no limit. While you can change from one positive limit to another at runtime, you cannot set this variable to 0, or change it from 0, while the server is running.
Description: Compression algorithm used on page compression. Can only be set to supported values. Not all distributions support all these compression methods. Setting this alone is not sufficient to compress tables - see Choosing compression algorithm.
none: Default. Data is not compressed.
zlib: Pages are compressed with bundled zlib compression method.
lz4: Pages are compressed using https://code.google.com/p/lz4/ compression method.
lzo: Pages are compressed using http://www.oberhumer.com/opensource/lzo/ compression method.
lzma: Pages are compressed using http://tukaani.org/xz/ compression method.
bzip2: Pages are compressed using http://www.bzip.org/ compression method.
snappy: Pages are compressed using https://code.google.com/p/snappy/ (from MariaDB 10.1.3).
Description: Whether or not compression is the default for new tables. By default OFF, which means new tables are not compressed.
Description: Specifies the percentage cutoff for expensive [compressed table, after which free space is added to each new compressed page, dynamically adjusted up to the level set by innodb_compression_pad_pct_max. Zero disables checking of compression efficiency and adjusting padding.
Description: The level of zlib compression, from 1 to 9, used with InnoDB compressed tables and indexes. 1 gives the best speed, 9 the best compression. Defaults to 6. Note that not all compression methods allow choosing the compression level and in those cases the compression level value is ignored. See InnoDB/XtraDB Page Compression.
Description: The maximum percentage of reserved free space within each compressed page. Reserved free space is used when the page's data is reorganized and might be recompressed. Only used when innodb_compression_failure_threshold_pct is not zero, and the rate of compression failures exceeds its setting.
Description: Number of times a newly-entered thread can enter and leave InnoDB until it is again subject to the limitations of innodb_thread_concurrency and may possibly be queued.
Description: When set to assert, the default, XtraDB will intentionally crash the server when it detects corrupted data in a single-table tablespace, with an assertion failure. When set to warn, it will pass corruption as corrupt table instead of crashing, and disable all further I/O (except for deletion) on the table file. If set to salvage, read access is permitted, but corrupted pages are ignored. innodb_file_per_table must be enabled for this option. Previously named innodb_pass_corrupt_table. XtraDB only. Added as a deprecated and ignored option in MariaDB 10.2.6 (which uses InnoDB as default instead of XtraDB) to allow for easier upgrades.
Description: Individual InnoDB data files, paths and sizes. The value of innodb_data_home_dir is joined to each path specified by innodb_data_file_path to get the full directory path. If innodb_data_home_dir is an empty string, absolute paths can be specified here. A file size is specified with K for kilobytes, M for megabytes and G for gigabytes, and whether or not to autoextend the data file is also specified.
Description: Directory path for all InnoDB data files in the shared tablespace (assuming innodb_file_per_table is not enabled). File-specific information can be added in innodb_data_file_path, as well as absolute paths if innodb_data_home_dir is set to an empty string.
Description: By default, the InnoDB deadlock detector is enabled. If set to off, deadlock detection is disabled and MariaDB will rely on innodb_lock_wait_timeout instead. This may be more efficient in systems with high concurrency as deadlock detection can cause a bottleneck when a number of threads have to wait for the same lock.
Description: Encryption key used for page encryption. See Table and Tablespace Encryption.
Description: ID of encryption key used by default to encrypt InnoDB tablespaces. See Data at Rest Encryption and Encryption Keys.
Description: Specifies the default row format to be used for InnoDB tables. The compressed row format cannot be set as the default.
Description: When set to 1 (the default is 0), InnoDB defragmentation is enabled. When set to FALSE, all existing defragmentation will be paused and new defragmentation commands will fail. Paused defragmentation commands will resume when this variable is set to true again. See Defragmenting InnoDB Tablespaces.
Description:. Indicates how full defragmentation should fill a page. Together with innodb_defragment_fill_factor_n_recs ensures defragmentation won't pack the page too full and cause page split on the next insert on every page. The variable indicating more defragmentation gain is the one effective. See Defragmenting InnoDB Tablespaces.
Description: Number of records of space that defragmentation should leave on the page. This variable, together with innodb_defragment_fill_factor, is introduced so defragmentation won't pack the page too full and cause page split on the next insert on every page. The variable indicating more defragmentation gain is the one effective. See Defragmenting InnoDB Tablespaces.
Description: Maximum times per second for defragmenting a single index. This controls the number of times the defragmentation thread can request X_LOCK on an index. The defragmentation thread will check whether 1/defragment_frequency (s) has passed since it last worked on this index, and put the index back in the queue if not enough time has passed. The actual frequency can only be lower than this given number. See Defragmenting InnoDB Tablespaces.
Description: Number of pages considered at once when merging multiple pages to defragment. See Defragmenting InnoDB Tablespaces.
Description: Number of defragment stats changes there are before the stats are written to persistent storage. Defaults to zero, meaning disable defragment stats tracking. See Defragmenting InnoDB Tablespaces.
Description: Size in bytes of a soft limit the memory used by tables in the data dictionary. Once this limit is reached, XtraDB will attempt to remove unused entries. If set to 0, the default and standard InnoDB behavior, there is no limit to memory usage. Removed in MariaDB 10.0/XtraDB 5.6 and replaced by MySQL 5.6's new table_definition_cache implementation.
Removed: MariaDB 10.0/XtraDB 5.6 - replaced by MySQL 5.6's new table_definition_cache implementation.
Description: If set to 1 (0 is default), the operating system file system cache for merge-sort temporary files is disabled.
Description: Tell InnoDB to stop any writes to disk.
Description: If set to 1, the default, to improve fault tolerance InnoDB first stores data to a doublewrite buffer before writing it to data file. Disabling will provide a marginal peformance improvement.
Description: The absolute or relative path and filename to a dedicated tablespace for the doublewrite buffer. In heavy workloads, the doublewrite buffer can impact heavily on the server, and moving it to a different drive will reduce contention on random reads. Since the doublewrite buffer is mostly sequential writes, a traditional HDD is a better choice than SSD. This Percona XtraDB variable has not been ported to XtraDB 5.6.
Description: XtraDB 5.6.13-61 introduced an algorithm to assist with reducing mutex contention when the buffer pool free list is empty, controlled by this variable. If set to backoff, the default, the new algorithm will be used. If set to legacy, the original InnoDB algorithm will be used. XtraDB only. Added as a deprecated and ignored option in MariaDB 10.2.6 (which uses InnoDB as default instead of XtraDB) to allow for easier upgrades. See #1651657 for the reasons this was changed back to legacy in XtraDB 5.6.36-82.0.
Description: Unneeded after XtraDB 1.0.5. If set to 0, the default, InnoDB will keep transactions between the transaction log and binary logs in the same order. Safer, but slower. If set to 1, transactions can be group-committed, but there is no guarantee of the order being kept, and a small risk of the two logs getting out of sync. In write-intensive environments, can lead to a significant improvement in performance.
Description: Enables encryption of the InnoDB redo log. This also enables encryption of some temporary files created internally by InnoDB, such as those used for merge sorts and row logs. See Data at Rest Encryption and Enabling Encryption for Redo Log.
Description: Enables automatic encryption of all InnoDB tablespaces. See Data at Rest Encryption and Enabling Encryption for Automatically Encrypted Tablespaces.
OFF - Disables table encryption.
ON - Enables table encryption, but allows unencrypted tables to be created.
FORCE - Enables table encryption, and doesn't allow unencrypted tables to be created (CREATE TABLE ... ENCRYPTED=NO will fail).
Description: Re-encrypt in background any page having a key older than this number of key versions. When setting up encryption, this variable must be set to a non-zero value. Otherwise, when you enable encryption through innodb_encrypt_tables MariaDB won't be able to automatically encrypt any unencrypted tables. See Data at Rest Encryption and Background Operations.
Description: Use this many iops for background key rotation operations performed by the background encryption threads. See Data at Rest Encryption and Background Operations.
Description: Number of background encryption threads threads performing background key rotation and scrubbing. When setting up encryption, this variable must be set to a non-zero value. Otherwise, when you enable encryption through innodb_encrypt_tables MariaDB won't be able to automatically encrypt any unencrypted tables. See Data at Rest Encryption and Background Encryption Threads.
Description: Removed in XtraDB 5.5 and replaced by innodb_rollback_segments. Usually there is one rollback segment protected by single mutex, a source of contention in high write environments. This option specifies a number of extra user rollback segments. Changing the default will make the data readable by XtraDB only, and is incompatible with InnoDB. After modifying, the server must be slow-shutdown. If there is existing data, it must be dumped before changing, and re-imported after the change has taken effect.
Description: Usually, InnoDB has 1024 undo slots in its rollback segment, so 1024 transactions can run in parallel. New transactions will fail if all slots are used. Setting this variable to 1 expands the available undo slots to 4072. Not recommended unless you get the Warning: cannot find a free slot for an undo log error in the error log, as it makes data files unusable for ibbackup, or MariaDB servers not run with this option. See also undo log.
Description: Enables the fake changes feature. In replication, setting up or restarting a slave can cause a replication reads to perform more slowly, as MariaDB is single-threaded and needs to read the data before it can execute the queries. This can be speeded up by prefetching threads to warm the server, replaying the statements and then rolling back at commit. This however has a overhead from locking rows only then to undo changes at rollback. Fake changes attempts to reduce this overhead by reading the rows for INSERT, UPDATE and DELETE statements but not updating them. The rollback is then very fast with little or nothing to do. XtraDB only. Added as a deprecated and ignored option in MariaDB 10.2.6 (which uses InnoDB as default instead of XtraDB) to allow for easier upgrades.
Description: Implements a more CPU efficient XtraDB checksum algorithm, useful for write-heavy loads with high I/O. If set to 1 on a server with tables that have been created with it set to 0, reads will be slower, so tables should be recreated (dumped and reloaded). XtraDB will fail to start if set to 0 and there are tables created while set to 1. Replaced with innodb_checksum_algorithm in MariaDB 10.0/XtraDB 5.6.
0 - InnoDB performs a slow shutdown, including full purge (before MariaDB 10.3.6, not always, due to MDEV-13603) and change buffer merge. Can be very slow, even taking hours in extreme cases.
1 - the default, InnoDB performs a fast shutdown, not performing a full purge or an insert buffer merge.
2, the InnoDB redo log is flushed and a cold shutdown takes place, similar to a crash. The resulting startup then performs crash recovery. Extremely fast, in cases of emergency, but risks corruption.
3 (from MariaDB 10.3.6) - active transactions will not be rolled back, but all changed pages will be written to data files. The active transactions will be rolled back by a background thread on a subsequent startup. The fastest option that will not involve InnoDB redo log apply on subsequent startup. See MDEV-15832.
Description: In MariaDB, the fatal semaphore timeout is configurable. This variable sets the maximum number of seconds for semaphores to time out in InnoDB.
Description: File format for new InnoDB tables. Can either be Antelope, the default and the original format, or Barracuda, which supports compression. Note that this value is also used when a table is re-created with an ALTER TABLE which requires a table copy. See XtraDB/InnoDB File Format for more on the file formats. Removed in 10.3.1 and restored as a deprecated and unused variable in 10.4.3 for compatibility purposes.
Description: If set to 1, the default, InnoDB checks the shared tablespace file format tag. If this is higher than the current version supported by XtraDB/InnoDB (for example Barracuda when only Antelope is supported), XtraDB/InnoDB will will not start. If it the value is not higher, XtraDB/InnoDB starts correctly and the innodb_file_format_max value is set to this value. If innodb_file_format_check is set to 0, no checking is performed. See XtraDB/InnoDB File Format for more on the file formats.
Description: The highest XtraDB/InnoDB file format. This is set to the value of the file format tag in the shared tablespace on startup (see innodb_file_format_check). If the server later creates a higher table format, innodb_file_format_max is set to that value. See XtraDB/InnoDB File Format for more on the file formats.
Description: If set to ON, then new InnoDB tables are created with their own InnoDB file-per-table tablespaces. If set to OFF, then new tables are created in the InnoDB system tablespace instead. Page compression is only available with file-per-table tablespaces. Note that this value is also used when a table is re-created with an ALTER TABLE which requires a table copy.
Description: Percentage of B-tree page filled during bulk insert (sorted index build). Used as a hint rather than an absolute value. Setting to 70, for example, reserves 30% of the space on each B-tree page for the index to grow in future.
Description: Interval in seconds to write and flush the InnoDB redo log. Before MariaDB 10, this was fixed at one second, which is still the default, but this can now be changed. It's usually increased to reduce flushing and avoid impacting performance of binary log group commit.
Description: Set to 1, along with sync_binlog=1 for the greatest level of fault tolerance. The value of innodb_use_global_flush_log_at_trx_commit determines whether this variable can be reset with a SET statement or not.
1 The default, the log buffer is written to the InnoDB redo log file and a flush to disk performed after each transaction. This is required for full ACID compliance.
0 Nothing is done on commit; rather the log buffer is written and flushed to the InnoDB redo log once a second. This gives better performance, but a server crash can erase the last second of transactions.
2 The log buffer is written to the InnoDB redo log after each commit, but flushing takes place once a second. Performance is slightly better, but a OS or power outage can cause the last second's transactions to be lost.
3 (from MariaDB 10.0) Emulates MariaDB 5.5 group commit (3 syncs per group commit). See Binlog group commit and innodb_flush_log_at_trx_commit.
Description: XtraDB/InnoDB flushing method. Windows always uses async_unbuffered and this variable then has no effect. On Unix, by default fsync() is used to flush data and logs. Adjusting this variable can give performance improvements, but behavior differs widely on different filesystems, and changing from the default has caused problems in some situations, so test and benchmark carefully before adjusting. In MariaDB, Windows recognises and correctly handles the Unix methods, but if none are specified it uses own default - unbuffered write (analog of O_DIRECT) + syncs (e.g FileFlushBuffers()) for all files.
O_DSYNC - O_DSYNC is used to open and flush logs, and fsync() to flush the data files.
O_DIRECT - O_DIRECT or directio(), is used to open data files, and fsync() to flush data and logs.
fsync - Default on Unix. Can be specified directly, but if the variable is unset on Unix, fsync() will be used by default.
O_DIRECT_NO_FSYNC - introduced in MariaDB 10.0. Uses O_DIRECT during flushing I/O, but skips fsync() afterwards. Not suitable for XFS filesystems.
ALL_O_DIRECT - introduced in MariaDB 5.5 and available with XtraDB only. Uses O_DIRECT for opening both data and logs and fsync() to flush data but not logs. Use with large InnoDB files only, otherwise may cause a performance degradation. Set innodb_log_block_size to 4096 on ext4 filesystems. This is the default log block size on ext4 and will avoid unaligned AIO/DIO warnings.
Description: Determines whether, when dirty pages are flushed to the data file, neighboring pages in the data file are flushed at the same time. If set to none, the feature is disabled. If set to area, the default, the standard InnoDB behavior is used. For each page to be flushed, dirty neighboring pages are flushed too. If there's little head seek delay, such as SSD or large enough write buffer, one of the other two options may be more efficient. If set to cont, for each page to be flushed, neighboring contiguous blocks are flushed at the same time. Being contiguous, a sequential I/O is used, unlike the random I/O used in area. Replaced by innodb_flush_neighbors in MariaDB 10.0/XtraDB 5.6.
Description: Determines whether flushing a page from the buffer pool will flush other dirty pages in the same group of pages (extent). In high write environments, if flushing is not aggressive enough, it can fall behind resulting in higher memory usage, or if flushing is too aggressive, cause excess I/O activity. SSD devices, with low seek times, would be less likely to require dirty neighbor flushing to be set.
1: The default, flushes contiguous dirty pages in the same extent from the buffer pool.
0: No other dirty pages are flushed.
2: Flushes dirty pages in the same extent from the buffer pool.
Description: If set to ON, the default, the innodb_io_capacity setting is ignored for I/O bursts occuring at checkpoints.
Description: Determines how quickly adaptive flushing will respond to changing workloads. The value is the number of iterations that a previously calculated flushing state snapshot is kept. Increasing the value smooths and slows the rate that the flushing operations change, while decreasing it causes flushing activity to spike quickly in response to workload changes.
Description: Set to 0 by default, if set to 1, XtraDB/InnoDB will be permitted to load tables marked as corrupt. Only use this to recover data you can't recover any other way, or in troubleshooting. Always restore to 0 when the returning to regular use.
Description: If set to 1 (0 is default) CREATE TABLEs without a primary or unique key where all keyparts are NOT NULL will not be accepted, and will return an error.
Description: XtraDB/InnoDB crash recovery mode. 0 is the default. The other modes are for recovery purposes only, and no data can be changed while another mode is active. Some queries relying on indexes are also blocked. See XtraDB/InnoDB Recovery Modes for more on mode specifics.
Description: Before XtraDB 5.6.13-61.0, if the checkpoint age is in the sync preflush zone while a thread is writing to the XtraDB redo log, it will try to advance the checkpoint by issuing a flush list flush batch if this is not already being done. XtraDB has enhanced page cleaner tuning, and may already be performing furious flushing, resulting in the flush simply adding unneeded mutex pressure. Instead, the thread now waits for the flushes to finish, and then has two options, controlled by this variable. XtraDB only. Added as a deprecated and ignored option in MariaDB 10.2.6 (which uses InnoDB as default instead of XtraDB) to allow for easier upgrades.
exponential_backoff - thread sleeps while it waits for the flush list flush to occur. The sleep time randomly progressively increases, periodically reset to avoid runaway sleeps.
sync_preflush - thread issues a flush list batch, and waits for it to complete. This is the same as is used when the page cleaner thread is not running.
Description: Diagnostic variable intended only to be set at runtime. It specifies the qualified name (for example test/ft_innodb) of an InnoDB table that has a FULLTEXT index, and after being set the INFORMATION_SCHEMA tables INNODB_FT_INDEX_TABLE, INNODB_FT_INDEX_CACHE, INNODB_FT_CONFIG, INNODB_FT_DELETED, and INNODB_FT_BEING_DELETED will contain search index information for the specified table.
Description: Cache size available for a parsed document while creating an InnoDB FULLTEXT index.
Description: If set to 1, additional full-text search diagnostic output is enabled.
Description: If set to 1, the default, a set of stopwords is associated with an InnoDB FULLTEXT index when it is created. The stopword list comes from the table set by the session variable innodb_ft_user_stopword_table, if set, otherwise the global variable innodb_ft_server_stopword_table, if that is set, or the built-in list if neither variable is set.
Description: Maximum length of words stored in an InnoDB FULLTEXT index. A larger limit will increase the size of the index, slowing down queries, but permit longer words to be searched for. In most normal situations, longer words are unlikely search terms.
Description: Minimum length of words stored in an InnoDB FULLTEXT index. A smaller limit will increase the size of the index, slowing down queries, but permit shorter words to be searched for. For data stored in a Chinese, Japanese or Korean character set, a value of 1 should be specified to preserve functionality.
Description: Number of words processed during each OPTIMIZE TABLE on an InnoDB FULLTEXT index. To ensure all changes are incorporated, multiple OPTIMIZE TABLE statements could be run in case of a substantial change to the index.
Description: Limit in bytes of the InnoDB FULLTEXT index query result cache per fulltext query. The latter stages of the full-text search are handled in memory, and limiting this prevents excess memory usage. If the limit is exceeded, the query returns an error.
Description: Table name containing a list of stopwords to ignore when creating an InnoDB FULLTEXT index, in the format db_name/table_name. The specified table must exist before this option is set, and must be an InnoDB table with a single column, a VARCHAR named VALUE. See also innodb_ft_enable_stopword.
Description: Number of parallel threads used when building an InnoDB FULLTEXT index. See also innodb_sort_buffer_size.
Description:Total memory allocated for the cache for all InnoDB FULLTEXT index tables. A force sync is triggered if this limit is exceeded.
Description: Allows the insert buffer activity to be adjusted. The following formula is used: [real activity] = [default activity] * (innodb_io_capacity/100) * (innodb_ibuf_accel_rate/100). As innodb_ibuf_accel_rate is increased from its default value of 100, the lowest setting, insert buffer activity is increased. See also innodb_io_capacity. This Percona XtraDB variable has not been ported to XtraDB 5.6.
Description: Specifies whether the insert buffer can be processed before it's full. If set to 0, the standard InnoDB method is used, and the buffer is not processed until it's full. If set to 1, the default, the insert buffer can be processed before it is full. This Percona XtraDB variable has not been ported to XtraDB 5.6.
Description: Maximum size in bytes of the insert buffer. Defaults to half the size of the buffer pool so you may want to reduce if you have a very large buffer pool. If set to 0, the insert buffer is disabled, which will cause all secondary index updates to be performed synchronously, usually at a cost to performance. This Percona XtraDB variable has not been ported to XtraDB 5.6.
Description: Up to what percentage of dirty pages should be flushed when innodb finds it has spare resources to do so.
Description: Enable scrubbing of data. See Data Scrubbing.
Description: If set to 1, permits importing of .ibd files exported with the XtraBackup --export option. Previously named innodb_expand_import. Removed in MariaDB 10.0/XtraDB 5.6 and replaced with MySQL 5.6's transportable tablespaces.
Description: Enable semaphore request instrumentation. This could have some effect on performance but allows better information on long semaphore wait problems.
Description: Limit on I/O activity for XtraDB/InnoDB background tasks, including merging data from the insert buffer and flushing pages. Should be set to around the number of I/O operations per second that system can handle, based on the type of drive/s being used. You can also set it higher when the server starts to help with the extra workload at that time, and then reduce for normal use. Ideally, opt for a lower setting, as at higher value data is removed from the buffers too quickly, reducing the effectiveness of caching. See also innodb_flush_sync.
Description: Upper limit to which InnodDB can extend innodb_io_capacity in case of emergency. Only applicable if no value was specified for innodb_io_capacity when the server started up.
Description: Time in seconds before killing an idle XtraDB transaction. If set to 0 (the default), the feature is disabled. Used to prevent accidental user locks. XtraDB only. Added as a deprecated and ignored option in MariaDB 10.2.6 (which uses InnoDB as default instead of XtraDB) to allow for easier upgrades.
Description: If set to 1, tables that use dynamic and compressed row formats (which require innodb_file_format to be barracuda and innodb_file_per_table to be true) are permitted to have index key prefixes up to 3072 bytes. If not set, the limit is 767 bytes. Removed in 10.3.1 and restored as a deprecated and unused variable in 10.4.3 for compatibility purposes.
Description: Deprecated and removed in XtraDB 5.6. DROP TABLE processing can take a long time when innodb_file_per_table is set to 1 and there's a large buffer pool. If innodb_lazy_drop_table is set to 1 (0 is default), XtraDB attempts to optimize DROP TABLE processing by deferring the dropping of related pages from the buffer pool until there is time, only initially marking them.
Description: Specifies the algorithm that InnoDB/XtraDB uses to decide which of the waiting transactions should be granted the lock once it has been released. The possible values are: FCFS (First-Come-First-Served) where locks are granted in the order they appear in the lock queue and VATS (Variance-Aware-Transaction-Scheduling) where locks are granted based on the Eldest-Transaction-First heuristic. Note that VATS should not be used with Galera. From MariaDB 10.1.30, InnoDB will refuse to start if VATS is used with Galera. From MariaDB 10.2, VATS is default, but from MariaDB 10.2.12, the value will be changed to FCFS and a warning produced when using Galera.
Description: Time in seconds that an InnoDB transaction waits for an InnoDB row lock (not table lock) before giving up with the error ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction. When this occurs, the statement (not transaction) is rolled back. The whole transaction can be rolled back if the innodb_rollback_on_timeout option is used. Increase this for data warehousing applications or where other long-running operations are common, or decrease for OLTP and other highly interactive applications. This setting does not apply to deadlocks, which InnoDB detects immediately, rolling back a deadlocked transaction. 0 (from MariaDB 10.3.0) means no wait. See WAIT and NOWAIT.
Description: If set to OFF, fake transactions (see innodb_fake_changes) don't take row locks. This is an experimental feature to attempt to deal with drawbacks in fake changes blocking real locks. It is not safe for use in all environments. XtraDB only. Added as a deprecated and ignored option in MariaDB 10.2.6 (which uses InnoDB as default instead of XtraDB) to allow for easier upgrades.
Description: Set to 0 by default, in which case XtraDB/InnoDB uses gap locking. If set to 1, gap locking is disabled for searches and index scans. Deprecated in MariaDB 10.0, use READ COMMITTED transaction isolation level instead.
Description: The directory for XtraDB redo log archiving. XtraDB only. Added as a deprecated and ignored option in MariaDB 10.2.6 (which uses InnoDB as default instead of XtraDB) to allow for easier upgrades.
Description: Time in seconds since the last change after which the archived XtraDB redo log should be deleted. XtraDB only. Added as a deprecated and ignored option in MariaDB 10.2.6 (which uses InnoDB as default instead of XtraDB) to allow for easier upgrades.
Description: Whether or not XtraDB redo log archiving is enabled. XtraDB only. Added as a deprecated and ignored option in MariaDB 10.2.6 (which uses InnoDB as default instead of XtraDB) to allow for easier upgrades.
Description: Size in bytes of the XtraDB redo log records. Generally 512, the default, or 4096, are the only two useful values. If the server is restarted and this value is changed, all old log files need to be removed. Should be set to 4096 for SSD cards or if innodb_flush_method is set to ALL_O_DIRECT on ext4 filesystems. XtraDB only. Added as a deprecated and ignored option in MariaDB 10.2.6 (which uses InnoDB as default instead of XtraDB) to allow for easier upgrades.
Description: Size in bytes of the buffer for writing InnoDB redo log files to disk. Increasing this means larger transactions can run without needing to perform disk I/O before committing.
Description: Experimental feature (as of MariaDB 10.0.9), this variable specifies how to generate and verify XtraDB redo log checksums. XtraDB only. Added as a deprecated and ignored option in MariaDB 10.2.6 (which uses InnoDB as default instead of XtraDB) to allow for easier upgrades.
none - No checksum. A constant value is instead written to logs, and no checksum validation is performed.
innodb - The default, and the original InnoDB algorithm. This is inefficient, but compatible with all MySQL, MariaDB and Percona versions that don't support other checksum algorithms.
crc32 - CRC32© is used for log block checksums, which also permits recent CPUs to use hardware acceleration (on SSE4.2 x86 machines and Power8 or later) for the checksums.
strict_* - Whether or not to accept checksums from other algorithms. If strict mode is used, checksums blocks will be considered corrupt if they don't match the specified algorithm. Normally they are considered corrupt only if no other algorithm matches.
Description: If set to 1, CRC32C for Innodb or innodb_log_checksum_algorithm for XtraDB algorithm is used for InnoDB redo log pages. If disabled, the checksum field contents are ignored.
Description: Whether or not images of recompressed pages are stored in the InnoDB redo log.
Description: Size in bytes of each InnoDB redo log file in the log group. The combined size can be no more than 4GB prior to MariaDB 10.0, and no more than 512GB in MariaDB 10.0 and later. Larger values mean less disk I/O due to less flushing checkpoint activity, but also slower recovery from a crash.
Description: Number of physical files in the InnoDB redo log.
Description: Path to the InnoDB redo log files. If none is specified, innodb_log_files_in_group files named ib_logfile0 and so on, with a size of innodb_log_file_size are created in the data directory.
Description: Whether InnoDB redo log activity should be reduced when natively creating indexes or rebuilding tables. Reduced logging requires additional page flushing and interferes with Mariabackup. Setting this OFF avoids delay due to page flushing and allows concurrent backup.
Description: InnoDB redo log write ahead unit size to avoid read-on-write. Should match the OS cache block IO size.
Description: Specifies how far down the buffer pool LRU list the cleaning thread should look for dirty pages to flush. This process is performed once a second. In an I/O intensive-workload, can be increased if there is spare I/O capacity, or decreased if in a write-intensive workload with little spare I/O capacity.
Description: Limit in bytes of the changed page bitmap files. For faster incremental backup with Xtrabackup, XtraDB tracks pages with changes written to them according to the XtraDB redo log and writes the information to special changed page bitmap files. These files are rotated when the server restarts or when this limit is reached. XtraDB only. See also innodb_track_changed_pages and innodb_max_changed_pages. Added as a deprecated and ignored option in MariaDB 10.2.6 (which uses InnoDB as default instead of XtraDB) to allow for easier upgrades.
Description: Limit to the number of changed page bitmap files (stored in the Information Schema INNODB_CHANGED_PAGES table). Zero is unlimited. See innodb_max_bitmap_file_size and innodb_track_changed_pages. Previously named innodb_changed_pages_limit. XtraDB only. Added as a deprecated and ignored option in MariaDB 10.2.6 (which uses InnoDB as default instead of XtraDB) to allow for easier upgrades.
Description: Maximum percentage of unwritten (dirty) pages in the buffer pool. This variable was changed to a double in MariaDB 10.0.15.
Description: Low water mark percentage of dirty pages that will enable preflushing to lower the dirty page ratio. If set to 0, the default until MariaDB 10.0.15, preflushing is disabled. This variable was changed to a double in MariaDB 10.0.15.
Description: When purge operations are lagging on a busy server, setting innodb_max_purge_lag can help. By default set to 0, no lag, the figure is used to calculate a time lag for each INSERT, UPDATE, and DELETE when the system is lagging. XtraDB/InnoDB keeps a list of transactions with delete-marked index records due to UPDATE and DELETE statements. The length of this list is purge_lag, and the calculation, performed every ten seconds, is as follows: ((purge_lag/innodb_max_purge_lag)×10)–5 milliseconds.
Description: Maximum delay in milliseconds imposed by the innodb_max_purge_lag setting. If set to 0, the default, there is no maximum.
Description: If an undo tablespace is larger than this, it will be marked for truncation if innodb_undo_log_truncate is set.
Description: Size in bytes of the block used for merge sorting in fast index creation. Replaced in MariaDB 10.0/XtraDB 5.6 by innodb_sort_buffer_size.
Description: Unused. Restored as a deprecated and ignored option in MariaDB 10.2.6 (which uses InnoDB as default instead of XtraDB) to allow for easier upgrades.
Description: Sets the number of threads to use in Multi-Threaded Flush operations. For more information, see Fusion-io Multi-threaded Flush. This feature was deprecated in version 10.2.9 and removed from version 10.3.2 of MariaDB. Instead, use the innodb_page_cleaners system variable.
Description: Disables the specified counters in the INFORMATION_SCHEMA.INNODB_METRICS table.
Description: Enables the specified counters in the INFORMATION_SCHEMA.INNODB_METRICS table.
Description: Resets the count value of the specified counters in the INFORMATION_SCHEMA.INNODB_METRICS table to zero.
Description: Resets all values for the specified counters in the INFORMATION_SCHEMA.INNODB_METRICS table.
Description: Whether or not to use the NUMA interleave memory policy to allocate the InnoDB buffer pool. Before MariaDB 10.2.4, required that MariaDB be compiled on a NUMA-enabled Linux system.
Description: Percentage of the buffer pool to use for the old block sublist.
Description: Time in milliseconds an inserted block must stay in the old sublist after its first access before it can be moved to the new sublist. '0' means "no delay". Setting a non-zero value can help prevent full table scans clogging the buffer pool. See also innodb_old_blocks_pct.
Description: The maximum size for temporary log files during online DDL (data and index structure changes). The temporary log file is used for each table being altered, or index being created, to store data changes to the table while the process is underway. The table is extended by innodb_sort_buffer_size up to the limit set by this variable. If this limit is exceeded, the online DDL operation fails and all uncommitted changes are rolled back. A lower value reduces the time a table could lock at the end of the operation to apply all the log's changes, but also increases the chance of the online DDL changes failing.
Description: Maximum .ibd files MariaDB can have open at the same time. Only applies to systems with multiple XtraDB/InnoDB tablespaces, and is separate to the table cache and open_files_limit. In MariaDB 10.0 the default, if innodb_file_per_table is disabled, is 300 or the value of table_open_cache, whichever is higher. It will also auto-size up to the default value if it is set to a value less than 10.
Description: When set to 1 (0 is default), OPTIMIZE TABLE will only process InnoDB FULLTEXT index data. Only intended for use during fulltext index maintenance.
Description: Number of page cleaner threads. The default is 4, but the value will be set to the number of innodb_buffer_pool_instances if this is lower. If set to 1, only a single cleaner thread is used, as was the case until MariaDB 10.2.1. Cleaner threads flush dirty pages from the buffer pool, performing flush list and LRU flushing.
Description: Size in bytes of the page size for all XtraDB/InnoDB tablespaces. The default, 16k, is suitable for most uses, but a smaller page size might work more effectively in a situation with many small writes (OLTP), or with SSD storage, which usually has smaller block sizes. The page size is set when a MariaDB instance starts, and it remains constant afterwards. MariaDB 10.1 allows up to 64K pages for tables with DYNAMIC, COMPACT and REDUNDANT row types, allowing more blob fields to be present in a table. Tables with COMPRESSED row type can for now still only be <= 16K page size. Single row size must be still <= 16K and max key length is not affected. Note that Percona previously implemented its own experimental version of innodb_page_size, which was deprecated in XtraDB 5.5.30-30.2, and replaced in XtraDB 5.6 with the MySQL 5.6 version.
Valid Values: 4k or 4096, 8k or 8192, 16k or 16384. MariaDB 10.1.0 and MySQL 5.7.6 also permits 32k and 64k.
Removed: XtraDB 5.5 - renamed innodb_corrupt_table_action.
Description: Enable prefix optimization to sometimes avoid cluster index lookups.
Description: If set to 1 (0 is default), all XtraDB/InnoDB transaction deadlock information is written to the error log.
Description: Units of InnoDB redo log records that will trigger a purge operation. Together with innodb_purge_threads has a small effect on tuning.
Description: Frequency with which undo records are purged. Set by default to every 128 times, reducing this increases the frequency at which rollback segments are freed. See also innodb_undo_log_truncate.
Description: Number of background threads dedicated to XtraDB/InnoDB purge operations. Since MariaDB 10.0, the range has been 1 to 32. At least one background thread is always used from MariaDB 10.0. The default has been increased from 1 to 4 in MariaDB 10.2.2. Setting to a value greater than 1 creates that many separate purge threads. This can improve efficiency in some cases, such as when performing DML operations on many tables. In MariaDB 5.5, the options are 0 and 1. If set to 0, the default, purging is done with the master thread. If set to 1, purging is done on a separate thread, which could reduce contention. See also innodb_purge_batch_size.
Description: Originally, random read-ahead was always set as an optimization technique, but was removed in MariaDB 5.5. innodb_random_read_ahead permits it to be re-instated if set to 1 (0) is default.
Description: If set to linear, the default, XtraDB/InnoDB will automatically fetch remaining pages if there are enough within the same extent that can be accessed sequentially. If set to none, read-ahead is disabled. random has been removed and is now ignored, while both sets to both linear and random. Also see innodb_read_ahead_threshold for more control on read-aheads. Removed in MariaDB 10.0/XtraDB 5.6 and replaced by MySQL 5.6's innodb_random_read_ahead.
Description: Minimum number of pages XtraDB/InnoDB must read from an extent of 64 before initiating an asynchronous read for the following extent.
Description: Number of I/O threads for XtraDB/InnoDB reads. You may on rare occasions need to reduce this default on Linux systems running multiple MariaDB servers to avoid exceeding system limits.
Description: If set to 1 (0 is default), the server will be read-only. For use in distributed applications, data warehouses or read-only media.
Description: If set to 1 (0 is default) and recovery is necessary on startup, the server will write detailed recovery statistics to the error log at the end of the recovery process. This Percona XtraDB variable has not been ported to XtraDB 5.6.
Description: Time in milliseconds for the slave server to delay the replication thread if innodb_thread_concurrency is reached.
Description: InnoDB usually rolls back the last statement of a transaction that's been timed out (see innodb_lock_wait_timeout). If innodb_rollback_on_timeout is set to 1 (0 is default), InnoDB will roll back the entire transaction. Before MariaDB 5.5, rolling back the entire transaction was the default behavior.
Description: Specifies the number of rollback segments that XtraDB/InnoDB will use within a transaction (see undo log). Deprecated and replaced by innodb_undo_logs in MariaDB 10.0.
Description: Use a backup-safe TRUNCATE TABLE implementation and crash-safe rename operations inside InnoDB. This is not compatible with hot backup tools other than Mariabackup. Users who need to use such tools may set this to OFF.
Description: Enable InnoDB redo log scrubbing. See Data Scrubbing.
Description: Used with Data Scrubbing in 10.1.3 only - replaced in 10.1.4 by innodb_scrub_log_speed. InnoDB redo log scrubbing interval in milliseconds.
Description: InnoDB redo log scrubbing speed in bytes/sec. See Data Scrubbing.
Description: Set a thread scheduling priority for cleaner and LRU manager threads. The range from 0 to 39 corresponds in reverse order to Linux nice values of -20 to 19. So 0 is the lowest priority (Linux nice value 19) and 39 is the highest priority (Linux nice value -20). XtraDB only. Added as a deprecated and ignored option in MariaDB 10.2.6 (which uses InnoDB as default instead of XtraDB) to allow for easier upgrades.
Description: Specifies the number of locks held for each InnoDB transaction to be displayed in SHOW ENGINE INNODB STATUS output. XtraDB only. Added as a deprecated and ignored option in MariaDB 10.2.6 (which uses InnoDB as default instead of XtraDB) to allow for easier upgrades.
Description: If set to 1, and innodb_status_output_locks is also ON, the traditional InnoDB behavior is followed and locked records will be shown in SHOW ENGINE INNODB STATUS output. If set to 0, the default, only high-level information about the lock is shown. XtraDB only. Added as a deprecated and ignored option in MariaDB 10.2.6 (which uses InnoDB as default instead of XtraDB) to allow for easier upgrades.
Description: Simulate compression failures. Used for testing robustness against random compression failures. XtraDB only.
Description: Size of the sort buffers used for sorting data when an InnoDB index is created, as well as the amount by which the temporary log file is extended during online DDL operations to record concurrent writes. Before MariaDB 10.0, this was not configurable and the current default setting of 1MB was fixed. The larger the setting, the fewer merge phases are required between buffers while sorting. When a CREATE TABLE or ALTER TABLE creates a new index, three buffers of this size are allocated, as well as pointers for the rows in the buffer.
Description: Maximum delay (not strictly corresponding to a time unit) between spin lock polls. Default changed from 6 to 4 in MariaDB 10.3.5, as this was verified to give the best throughput by OLTP update index and read-write benchmarks on Intel Broadwell (2/20/40) and ARM (1/46/46).
Description: If set to 1 (the default), persistent statistics are automatically recalculated when the table changes significantly (more than 10% of the rows). Affects tables created or altered with STATS_PERSISTENT=1 (see CREATE TABLE), or when innodb_stats_persistent is enabled. innodb_stats_persistent_sample_pages determines how much data to sample when recalculating. See InnoDB Persistent Statistics.
Description: If set to 0 (1 is default), index statistics will not be automatically calculated except when an ANALYZE TABLE is run, or the table is first opened. Replaced by innodb_stats_auto_recalc in MariaDB 10.0/XtraDB 5.6.
Removed: MariaDB 10.0 - replaced by innodb_stats_auto_recalc.
Description: Include delete marked records when calculating persistent statistics.
Description: Determines how NULLs are treated for XtraDB/InnoDB index statistics purposes. If set to nulls_equal, the default, all NULL index values are treated as a single group. This is usually fine, but if you have large numbers of NULLs the average group size is slanted higher, and the optimizer may miss using the index for ref accesses when it would be useful. If set to nulls_unequal, the opposite approach is taken, with each NULL forming its own group of one. Conversely, the average group size is slanted lower, and the optimizer may use the index for ref accesses when not suitable. Setting to nulls_ignored ignores NULLs altogether from index group calculations. See also Index Statistics, aria_stats_method and myisam_stats_method.
Description: The number of rows modified before we calculate new statistics. If set to 0, the default, current limits are used.
Description: If set to 1, the default, XtraDB/InnoDB updates statistics when accessing the INFORMATION_SCHEMA.TABLES or INFORMATION_SCHEMA.STATISTICS tables, and when running metadata statements such as SHOW INDEX or SHOW TABLE STATUS. If set to 0, statistics are not updated at those times, which can reduce the access time for large schemas, as well as make execution plans more stable.
Description: ANALYZE TABLE produces index statistics, and this setting determines whether they will be stored on disk, or be required to be recalculated more frequently, such as when the server restarts. This information is stored for each table, and can be set with the STATS_PERSISTENT clause when creating or altering tables (see CREATE TABLE). See InnoDB Persistent Statistics.
Description: Number of index pages sampled when estimating cardinality and statistics for indexed columns. Increasing this value will increases index statistics accuracy, but use more I/O resources when running ANALYZE TABLE. See InnoDB Persistent Statistics.
Description: Gives control over the index distribution statistics by determining the number of index pages to sample. Higher values produce more disk I/O, but, especially for large tables, produce more accurate statistics and therefore make more effective use of the query optimizer. Lower values than the default are not recommended, as the statistics can be quite inaccurate. Enabling innodb_stats_traditional will help large tables by using more samples. Deprecated in MariaDB 10.0 - use innodb_stats_transient_sample_pages instead.
Description: When enabled (the default), traditional statistics calculation based on the number of configured pages is used. When disabled, the innodb_stats_sample_pages (MariaDB 5.5) or innodb_stats_transient_sample_pages (MariaDB 10) is multiplied by log2(pages in table) to give a larger sample of pages for larger tables for the purposes of index statistics calculation.
Description: Gives control over the index distribution statistics by determining the number of index pages to sample. Higher values produce more disk I/O, but, especially for large tables, produce more accurate statistics and therefore make more effective use of the query optimizer. Lower values than the default are not recommended, as the statistics can be quite inaccurate. Enabling innodb_stats_traditional will help large tables by using more samples. If persistent statistics are used on a table (see innodb_stats_persistent), the setting from innodb_stats_persistent_sample_pages) applies instead.
Description: Setting to 0 (1 is default) may help reduce contention of the &dict_operation_lock, but also disables the Data_free option in SHOW TABLE STATUS. This Percona XtraDB variable has not been ported to XtraDB 5.6.
Description: Enable InnoDB monitor output to the error log.
Description: Enable InnoDB lock monitor output to the error log and SHOW ENGINE INNODB STATUS. Also requires innodb_status_output=ON to enable output to the error log.
Description: If set to 1 (0 is the default before MariaDB 10.2.2), XtraDB/InnoDB will return errors instead of warnings in certain cases, similar to strict SQL mode.
Description: If set to 1, the default, XA transactions are supported. XA support ensures data is written to the binary log in the same order to the actual database, which is critical for replication and disaster recovery, but comes at a small performance cost. If your database is set up to only permit one thread to change data (for example, on a replication slave with only the replication thread writing), it is safe to turn this option off. Removed in MariaDB 10.3, XA transactions are always supported.
Description: By default 1, can be increased to split internal thread co-ordinating, giving higher concurrency when there are many waiting threads.
Description: The number of times a thread waits for an XtraDB/InnoDB mutex to be freed before the thread is suspended.
Description: If autocommit is set to to 0 (1 is default), setting innodb_table_locks to 1, the default, will cause XtraDB/InnoDB to lock a table internally upon a LOCK TABLE.
Description: Once this number of threads is reached (excluding threads waiting for locks), XtraDB/InnoDB will place new threads in a wait state in a first-in, first-out queue for execution, in order to limit the number of threads running concurrently. A setting of 0, the default, permits as many threads as necessary. A suggested setting is twice the number of CPU's plus the number of disks.
Description: If set to 1, thread concurrency will be handled in a lock-free timer-based manner rather than the default mutex-based method. Depends on atomic op builtins being available. This Percona XtraDB variable has not been ported to XtraDB 5.6.
Description: Time in microseconds that XtraDB/InnoDB threads sleep before joining the queue. Setting to 0 disables sleep.
Description: Allows an alternate location to be set for temporary non-tablespace files. If not set (the default), files will be created in the usual tmpdir location.
Description: For faster incremental backup with Xtrabackup, XtraDB tracks pages with changes written to them according to the XtraDB redo log and writes the information to special changed page bitmap files. This read-only variable is used for controlling this feature. See also innodb_max_changed_pages and innodb_max_bitmap_file_size. XtraDB only. Added as a deprecated and ignored option in MariaDB 10.2.6 (which uses InnoDB as default instead of XtraDB) to allow for easier upgrades.
Description: Available on debug builds only. XtraDB only. Added as a deprecated and ignored option in MariaDB 10.2.6 (which uses InnoDB as default instead of XtraDB) to allow for easier upgrades.
Description: Path to the directory (relative or absolute) that InnoDB uses to create separate tablespaces for the undo logs. . (the default value before 10.2.2) leaves the undo logs in the same directory as the other log files. From MariaDB 10.2.2, the default value is NULL, and if no path is specified, undo tablespaces will be created in the directory defined by datadir. Use together with innodb_undo_logs and innodb_undo_tablespaces. Undo logs are most usefully placed on a separate storage device.
Description: When enabled, undo tablespaces that are larger than innodb_max_undo_log_size are marked for truncation. See also innodb_purge_rseg_truncate_frequency.
Description: Specifies the number of rollback segments that XtraDB/InnoDB will use within a transaction (or the number of active undo logs). By default set to the maximum, 128, it can be reduced to avoid allocating unneeded rollback segments. See the Innodb_available_undo_logs status variable for the number of undo logs available. See also innodb_undo_directory and innodb_undo_tablespaces. Replaces innodb_rollback_segments in MariaDB 10.0. The Information Schema XTRADB_RSEG Table contains information about the XtraDB rollback segments.
Description: Number of tablespaces files used for dividing up the undo logs. By default, undo logs are all part of the system tablespace, which contains one undo tablespace more than the innodb_undo_tablespaces setting. When the undo logs can grow large, splitting them over multiple tablespaces will reduce the size of any single tablespace. Must be set before InnoDB is initialized, or else MariaDB will fail to start, with an error saying that InnoDB did not find the expected number of undo tablespaces. The files are created in the directory specified by innodb_undo_directory, and are named undoN, N being an integer. The default size of an undo tablespace is 10MB. innodb_undo_logs must have a non-zero setting for innodb_undo_tablespaces to take effect.
Description: Implement atomic writes on supported SSD devices. See atomic write support for other variables affected when this is set.
Description: Preallocate files fast, using operating system functionality. On POSIX systems, posix_fallocate system call is used. Automatically set to 1 when innodb_use_atomic_writes is set - see FusionIO DirectFS atomic write support.
Description: Determines whether a user can set the variable innodb_flush_log_at_trx_commit. If set to 1, a user cannot reset the value with a SET command, while if set to 1, a user can reset the value of innodb_flush_log_at_trx_commit. XtraDB only. Added as a deprecated and ignored option in MariaDB 10.2.6 (which uses InnoDB as default instead of XtraDB) to allow for easier upgrades.
Description: Whether to enable Multi-Threaded Flush operations. For more information, see Fusion. This feature was deprecated in version 10.2.9 and removed from version 10.3.2 of MariaDB. Instead, use innodb_page_cleaners system variable.
Description: Usually with InnoDB, data changed by a transaction is written to an undo space to permit read consistency, and freed when the transaction is complete. Many, or large, transactions, can cause the main tablespace to grow dramatically, reducing performance. This option, introduced in XtraDB 5.1 and removed for 5.5, allows multiple threads to perform the purging, resulting in slower, but much more stable performance.
Description: If set to ON (OFF is default), a signal handler for SIGUSR2 is installed when the InnoDB server starts. When a long semaphore wait is detected at sync/sync0array.c, a SIGUSR2 signal is sent to the waiting thread and thread that has acquired the RW-latch. For both threads a full stacktrace is produced as well as if possible. XtraDB only. Added as a deprecated and ignored option in MariaDB 10.2.6 (which uses InnoDB as default instead of XtraDB) to allow for easier upgrades.
Description: If set the 1, the default, XtraDB/InnoDB will use the operating system's memory allocator. If set to 0 it will use its own. Deprecated in MariaDB 10.0 and removed in MariaDB 10.2 along with InnoDB's internal memory allocator.
Description: If set to 1 (0 is default), XtraDB will use the SYS_STATS system table for extra table index statistics. When a table is opened for the first time, statistics will then be loaded from SYS_STATS instead of sampling the index pages. Statistics are designed to be maintained only by running an ANALYZE TABLE. Replaced by MySQL 5.6's Persistent Optimizer Statistics.
Description: Use trim to free up space of compressed blocks. See InnoDB/XtraDB Page Compression - Persistent Trim). Note that this setting works best with NVMFS (see InnoDB holepunch compression vs the filesystem in MariaDB 10.1).
Description: InnoDB version number. From MariaDB 10.3.7, as the InnoDB implementation in MariaDB has diverged from MySQL, the MariaDB version is instead reported. For example, the InnoDB version reported in MariaDB 10.1 (which is based on MySQL 5.6) included encryption and variable-size page compression before MySQL 5.7 introduced them. MariaDB 10.2 (based on MySQL 5.7) introduced persistent AUTO_INCREMENT (MDEV-6076) in a GA release before MySQL 8.0. MariaDB 10.3 (based on MySQL 5.7) introduced instant ADD COLUMN (MDEV-11369) before MySQL.
Description: Number of I/O threads for XtraDB/InnoDB writes. You may on rare occasions need to reduce this default on Linux systems running multiple MariaDB servers to avoid exceeding system limits.


Thomas County Sheriffs Office is currently accepting applications for a full-time deputy until March 15th, 2019. Certification preferred but not required. Prior NLETC background and preliminary testing mandatory. Thomas County drug testing will be mandatory. EOE. Contact Sheriff Gary Eng at 308-645-9905 for application.
The Library Board will be conducting interviews for a Library Director Sept 17th starting at 3:30 p.m. in the County Commissioners room.


text:
Tag: sounders
Brian Schmetzer's Rave Green Army
On November 3, 2016 By HanneIn soccerLeave a comment
What a night, right? The Cubs won the world series after a really long time. The Sounders front office got one right!
I had 1200 words worth of Sounders verbal diarrhea to post about last nights announcement making Brian Schmetzer the permanent head coach. But none of it seems to be enough, so have some photos.
From the first time I met Schmetzer and he invited me to practice to meet the team
"I learned all about life with a ball at my feet." ~ Ronaldinho
On March 6, 2016 March 6, 2016 By HanneIn soccerLeave a comment
It's that time of year again.
I like to think I keep fairly busy: work, extra baby-sitting gigs, writing group, GSRWA and of course the basics like sleeping, eating and doing laundry. But from March through October, a full eight months out of the year soccer seems to squeeze out an extraordinary amount of time.
Soccer (or football for my annoying European friends who will point out that it's what the cool kids call it – you know who you are).
For eight months there are home games, away game. Injury reports, interviews. New socks, old USL era shirts. MLS live, FS1. Western Conference, Eastern Conference. CONCACAF, Open Cup. Cascadia Cup.Supporter's shield. MLS Cup. ECS.
Although MLS is still rather new in Seattle (this is our 8th season), this Sounder schedule is nothing new for me. Since 1994 my schedule has revolved around this team. Clipping news paper articles (I only stopped a few years ago), road trips to Vancouver and collecting autographs like trophies of my dedication to the team.
Now, on the morning of our season opener, I think of all the things I wanted to get done over the off-season – 90% didn't happen, oops. But hey, there is always next off season, right?
Oh, and if you need me? You can find me at the stadium. Or call me in November.
C'mon boys, take 'em all!
"Soccer isn't the same as Bach or Buddhism. But it is often more deeply felt than religion, and just as much a part of the community's fabric, a repository of traditions" – Franklin Foer
On October 21, 2015 October 20, 2015 By HanneIn UncategorizedLeave a comment
Sounder love.
The Sounders have been part of my life since 1994. Twenty-one years spent laughing, crying, cheering, angry, elated, frustrated, thrilled, disappointed, overjoyed and well, fucking pissed (I mean, losing to Portland in the playoffs? For the love of…).
I was a shy kid growing up. Like, painfully shy. So when I saw kids getting autographs from my favorite players, the ones I wrote about in my 3rd grade journal in Mrs. Rivas' class, I wanted autographs too. Only I wasn't brave enough to ask. I remember my parents sending me over, but I would hang back and as things started to feel too chaotic, I would turn back and shrug. I could get an autograph the next time. Or the next time.
In 1997, I started saving everything Sounders. Programs, ticket stubs, newspaper articles. I would search every page of the sports section until I found the tiny article, usually on the back page and cut them out. I remember going to Denmark that summer and asking the petsitter to save the sports page every day so that I didn't miss anything. A few articles with pictures went on my wall, the way other girls has posters of JTT (Jonathan Taylor Thomas – the other JT wasn't famous yet). My favorite was an action shot of Wade Webber and his bleach blonde hair.
In 2002 my dad and I saw Coach Schmetzer at Quest during the very first game at the new stadium. My dad suggested we say hello. I was too nervous, but my dad marched up and said hello and told him all about my scrapbook full of old Sounders stuff. The whole thing was a blur to me, but ended with an invite to the team practice at Memorial Stadium to have it signed by the guys. Thinking back on it, I can still feel the excitement radiating through my body. Coach Schmetzer waved us over and said I could go right out onto the field. I took half a step onto the turf and froze. I was terrified. I remember he eventually walked me around to the different groups of guys, starting the conversation for me and the players took it from there. They asked about me, about being a fan of the sport/team, they looked through my stuff and were really kind to me.
I hugged my scrapbook to my chest the entire ride home.
I arrived early before the next game, waiting by the entrance with a carnation for each of the guys, thanking them for signing my stuff. When they approached, they remembered my name, would chat for a minute, take a picture with me and suddenly I didn't feel so invisible anymore.
After the game I would wait with the rest of the fans wanting an autograph and I remember Scott Jenkins taking the time to talk instead of signing my program and moving on to the next. Viet once ran to the locker room and grabbed a game worn jersey and an autographed ball. And Craig always had the biggest smile and a hug for me (and still does today, 13 years later).
This is why I support not only this team, but these guys (playing or not) so many years later. None of this was required by the team, the coach. This was never about being a publicity stunt or trying to gain more fans. This was about being nice. They did something nice for someone just because. And it taught me that you never know how much your kindness can effect another person. Today. Tomorrow. Or 13 years from now.
Sports fans come and go, but when you're 'Sounders Til I Die', there is no end. Not the end of the game. Not the end of the season. And certainly not the end of any one players career. #EBFG
"Best way to live in California is to be from somewheres else." ― Cormac McCarthy
On August 6, 2014 August 6, 2014 By HanneIn Travel, Uncategorized1 Comment
Had a (mostly) fantastic long weekend down in the Bay area and along the Oregon coast. A little rocky to start – some asshole in front of us lost some of their camping supplies and we hit their frying pan. Luckily it was only a tiny scratch and we laughed about it the rest of the way down. The drive down was long, hot and oh-so-boring. We hit temps as high as 110, added nearly an hour in construction detours and with nothing but dry, brown grass, it's not exactly my favorite drive.
We arrived just past dinner time on Friday, checked in and headed to my favorite 'Crawdaddies' for dinner. It's a hot, garlic, shrimpy mess – but well worth it. Saturday we were up and headed into San Francisco. We explored the wharf, found the house/park they used for Full House (yep), Lombard Street and then popped over the Golden Gate Bridge.
The reason for the trip was the Sounders vs. San Jose Saturday evening. Jason wanted to go to see the new Levi's Stadium and I, of course, to see my team. Clearly he got the better half of the deal. We weren't awful (and much better than the game against LA) but it was still uninspired and we just couldn't connect. We ended up going to see Guardians of the Galaxy afterward to ease the pain. Great movie!
The drive up along the coast was much better than the drive down. It was cooler (fucking cold, according to Jason). But it was sad in some ways, many of the small towns along the way in very sad shape. Eureka, once busy with lumber mills and fisherman, has taken an obvious nose dive. The town is run down, homeless (most looked like they were on some sort of drug) were roaming the streets and the conversation we were privy to in the pub was… sad. Gold Beach was similar, though the people were friendly. The bartender invited himself up for a cup of noodles or bagel dog – when I said I didn't have either of those (or know what a bagel dog was), he invited himself up for a popsicle. Um, okay. But it was funny – everyone knew every one and at the grocery store, the lady in front of us mentioned something about her brother going away. Jason asked where (thinking he was joining the army or something big like that) and the lady at check-out looked up and was like who the fuck are you? Clearly we were outsiders and they all know each others business. Turns out the chick's brother was only headed down to LA (must be for school).
The best part of the drive back might have been the Trees of Mystery. What a great (little) hike and then the gondola ride further up into the forest. It was cloudy so we couldn't see far, but it was still fantastic. No bigfoot sightings, but plenty of Elk, deer, a lizard and other little creatures (and road kill) along the way. My favorite tree was this one – a single tree with 12 smaller trees growing off of it. Amazing! Others grew in absurd angles, in tight clusters and/or with massive girth.
It, of course, wasn't a trip to Cali without a stop at In & Out.
No visit is complete without a peek at the resident sea lions.
The last stop was my forever favorite, Newport, Oregon. We met my parents at the KOA where they spent two nights with the dog. Once they were packed up we headed in to Newport for lunch at my most favorite Mo's (on the water, not the one across the street). Shrimp salad in an avocado, chowder and garlic cheese bread. I don't think, in 15 years, I've ever had anything else. In fact, I don't remember ever ordering anything else. Jason headed out right after lunch with a long drive back to the Tri-Cities, but we hung a bit longer and walked through a few shops.
Overall, the trip was fun. I just wish we could've come home with three points (or even one), but we can't win them all.
Capitan Douchwaffle, at your service. 😉
OKC – ENERGY!
On June 29, 2014 By HanneIn Uncategorized2 Comments
Looking for the Mark Harmon post? Click here.
Looking for the Tornado post? Click here.
So while the main reason for my trip to OKC the past four years has been Mark Harmon, this year I lucked out by having TWO legit reasons to brave the heat, humidity and crazy southerners. Soccer!
As most of my friends know, I'm part of a new soccer podcast call the Soccer Talk Show (find us on facebook OR @soccertalkshow on twitter). We're pretty much Sounders only, but I have always been of the belief that 'once a sounder, always a sounder' – except Shalrie Joseph. I hope he doesn't see that.
Or maybe I do. Meh.
I met up with Philip Lund (2013 Sounder & fellow Dane- hollaback with the diggitydansk) at their Fri am practice for my first ever interview. I had zero clue as to what I was doing, and probably looked less than legit with just my iphone to record, but overall I think it went pretty well. Jay and I have some recording to do, but once the podcast is up, I'll link to it here and on social media. We had a great chat for the podcast and an even better chat after I stopped recording and let loose a bit with my own pet peeves on how the team is run. I mean, most everyone knows that I'm #teamschmetzer – but it was nice to get more of an inside perspective.
Saturday after the cancelled baseball game, the weather picked up and I made my way to the Energy FC game. Nice to chat with Philip again, and meet a family who has spent some time living in Wa (and are also Sounders fans – small world). Funny to find those connections. I sat in the 'fan zone' – remember, I'm legit now with my Energy tee – complete with Philip's name/number on the back in Zebra duct tape (because supplies are limited in OKC, apparently). It was fairly disorganized, but with a few 'leaders' in the group. I give them props for having some decent chants, though they rarely run through more than 1-2 times. It doesn't give people much time to learn them and jump in. And at one point they were ragging on the east side for not cheering. Um, encourage, not discourage them to sing. But it's only their first season – they'll grow. Look at the ECS.
The game was good, but I was worried the first half. The Energy were much slower than Sacremento, but the biggest thing was size/force. Whenever it was 1 v 1, the other team almost always came away with it. They were much bigger size-wise, so OKC has to find a way to be faster and get in there and take the ball away.
But, I must've been decent luck, because they ended the game with a 2-0 win!
Funny to see Jimmy Nielsen as coach. I want to like him. He's Danish and did very well in MLS. But totally still bitter about the Open Cup that Salazar handed them. Sorry, club over country. But I'm sure he's nice?
After the game I met a SKC fan and we talked about that game, and the fact that they were just kicked out by Portland (and then beat Portland a few days later in a regular season match.
<– me in my okc gear. which looks like sounders gear. I like.
Why I haven't (and won't) jump on the Seahawks bandwagon.
On January 16, 2014 By HanneIn UncategorizedLeave a comment
I don't like football.
It's a 60 minute game that takes half a day to watch. I don't see the skill beyond basic catch, or body slamming someone to the ground. The sport produces so many brain injuries, that a player killed himself but did so in a way that doctors could still look at his brain because he KNEW he was so messed up from repeated hard tackles. These men are getting paid millions to sustain brain damage at the delight of millions. I don't claim soccer to be an injury-less sport. People have dropped dead on the pitch mid-game (unchecked heart issue), left with broken bones, concussions, etc. But unlike football, it's not a massive epidemic of brain injury.
But even all that aside… it just isn't for me.
Maybe I'm still bitter about the lack of attention the Sounders/soccer has received over the years. Since joining the MLS we've gotten more coverage and actual color photos, but there still isn't a 'soccer page' in the Seattle Times the way they have one for football or MLB. I was at QFC the other day and they have Seahawks flowers. A bouquet of flowers dyed blue and green with a small Seahawks balloon in the middle. Where are the Sounders balloons? We've made the playoffs the past 5 years. Actually, I used to make Sounder flowers. I'd buy a couple bouquets of white flowers and dye them blue the night before a soccer game. I'd arrive 2 hours before kick off and hand them out to the players (and coach Schmetzer) at memorial stadium as they arrived.
I don't hate the Seahawks, I don't hope they lose. But I do find this bandwagon business amusing. Amusing because I'm an outsider. I know what it's like to love a team through the hard times and then watch as THOUSANDS descend upon your team claiming to be 'hard core' (I'm looking at YOU non-USL sounder fans). It's insulting irritating.
And hey Starbucks, where's my 'full -90' .90cent coffee in honor of the Sounders?

redpajama_set_name: RedPajamaCommonCrawl


text:
Tag: 1970s
08/30/2017 08/28/2017 Laurence Jones 1970s, Foreign Cars, Station Wagon, Streets of San Francisco, Toyota
(Found In) Civic Center (San Francisco, California): 1977 Toyota Corona Station Wagon
In a number of ways Toyota was the most "American" of Japanese manufacturers. Once on their feet in the U.S. market in the early 70's, they fielded a line up not dissimilar, albeit smaller and far more efficient, than Detroit rivals.
Mainstream models came in sizes small (Corolla), medium (Corona) and large (Crown/Cressida). There was a "pony" car (Celica) to boot. That's no different than Ford in the 1960's minus a halo coupe once you think about it.We've made friends with the 3rd Generation car. Today we see what the 5th generation had to offer when you opted for the wagon version.
Continue reading "(Found In) Civic Center (San Francisco, California): 1977 Toyota Corona Station Wagon" →
08/25/2017 08/24/2017 Laurence Jones 1970s, Dynamic Divergence, Ford Motor Division, Mercury, Orphan Brand
Dynamic Divergence: My Mother (And) The Car
Social Networking can bring about some really awkward interactions with parents if they are young enough and/or technologically savvy. In my case, they center around my mother and her opinions on some of the curbside classics I find and post to Facebook from time to time.
Due to her direct experience as a fashion conscious (and cautious) teenager in the mid 1970s, a number of classic cars can elicit some pretty strong memories. "Oh god! That is the same Comet grandma tried to buy for me my junior year" was her robust response to this Split Pea Green Comet I found in the El Cerrito hills.
Continue reading "Dynamic Divergence: My Mother (And) The Car" →
08/15/2017 Laurence Jones 1970s, Coupe, Ford, Ford Motor Division, Fuselage, Outside in Oakland
(Found In) Bushrod Park (Oakland, California): 1972 Ford LTD Hardtop Coupe
In the vehicles that are the zeitgeist of the time, the various Ford LTDs are vastly underrated as symbols for the time. Starting as yet another push by Ford upmarket, it calling into question the reason behind the Mercury brand yet again in 1965.
By the early 70's it was a reputable status symbol for those that wanted style, comfort, and isolation along with size without the expense of traditional posh offerings. As luxury efforts moved down market, there was little reason to upgrade beyond the whisper silent LTD.
1972 proved to be a bridge year. The traits and ethos of what had been traditional spectrum offerings of Full Sized cars was rapidly coming to a close. In a number of ways, this was the swan song season to the variety once well known, and offered most resplendently at the top of the Ford line.
Continue reading "(Found In) Bushrod Park (Oakland, California): 1972 Ford LTD Hardtop Coupe" →
Continue reading "(Found In) Outer Richmond (San Francisco, California): 1972 Oldsmobile Vista Cruiser Station Wagon" →
07/18/2017 07/13/2017 Laurence Jones 1970s, Buick, Coupe, Fuselage, General Motors, Outside in Oakland
When did Buick become a car for the elderly? It's really hard to say. For most of the early post-war era, Buick more or less espoused the belief in more subtle, less ostentatious luxury, in comparison to GM cousin brand Cadillac. During that same period, there were extensions downward to price categories just above Chevrolet, and attempts at re-cementing their reputation as Banker's Hot Rods as well.
Another belief was offering a whole lotta car for a minimum of a premium. As the Special nameplate drifted out of sight to re-appear as a luxury compact in the fall of 1960, the least dear Buick for your pocketbook became the LeSabre. Perhaps being a perennial customer favorite with people starting in 1959 lead to something of a reputation.
Continue reading "(Found In) Northgate (Oakland, California): 1972 Buick LeSabre Hardtop Coupe" →
05/13/2017 05/13/2017 Laurence Jones 1970s, 1980s, 1990s, Dynamic Divergence
Dynamic Divergence: Malaise Memories
There's the very pertinent reality that, in terms of car enthusiasm there's a huge bias towards cars of the immediate Post-War. In the glow of the found memories of mid-century economic prosperity, the reverence for cars with fins and full metal jackets lined inside and out still looms heavily over the shadow of car enthusiasm.
The cars that command average American Salaries if not more at auctions have years of birth of at least 45 years old, are considered at their finest bloom once they've hit the silver fox age of 50, and become really intensive things to insure and keep in good health once they hit 60 and beyond. Hiding in the shadows are the cars under 45 years old to those that are being ditched as students graduate college, leaving behind family hand-me-downs and first rides from the era of The X-Files and Moesha. "Malaise Machines," they're called.
Continue reading "Dynamic Divergence: Malaise Memories" →
05/03/2017 05/03/2017 Laurence Jones 1970s, Coupe, Fuselage, General Motors, Oldsmobile, Orphan Brand, Streets of San Francisco
(Found In) Park Merced (San Francisco, California): 1972 Oldsmobile Ninety Eight Coupe
The Oldsmobile Ninety Eight once sat in a rarefied holy trinity at the temple of General Motors opulence. The eldest and the most modest of the trio between the most Senior Buick, the now Electra 225, and the myriad of Cadillac DeVilles and Fleetwoods, the Ninety Eight negotiated for the least of your finances for the most security and the most sensible set of luxury trappings for your dollar.
Often great enough for many a generation of buyers who felt like they had "made it" the Ninety Eight was ready, willing and able to celebrate Oldsmobile's 75th year of manufacturing automobiles with a even more goodies for customers on deck after a full redesign for 1971.
Continue reading "(Found In) Park Merced (San Francisco, California): 1972 Oldsmobile Ninety Eight Coupe" →
05/01/2017 04/30/2017 Laurence Jones 1970s, Coupe, General Motors, Oldsmobile, Orphan Brand, Streets of San Francisco
(Found In) Mission District (San Francisco, California): 1971 Oldsmobile Cutlass "S" Hardtop Coupe
As Oldsmobile rose to their zenith in the 1970's, it started to do so by playing musicial chairs with the various marketing images that made for being the toast of the town image that it had fostered since the 1950's. The Olds-multiplicity of the brand had been a constant mix of practicality, performance and posh since the end of World War II. For the Elegant Ninety Eights there were the Superlative Super 88's. For the practical F-85 there was the swashbuckling Cutlass. For the sword of intermediates, a crowned princess Supreme started an ascent to the top of the charts like Diana, Mary and Florence starting in 1966.
The "Little Limousine" sparkled the most when it focused on a formal roof'd coupe. Where did that leave it's athletic, buxom and liberated sister ship the Cutlass S? In a curious place as Oldsmobile never wanted to commit to one specific identity.
Continue reading "(Found In) Mission District (San Francisco, California): 1971 Oldsmobile Cutlass "S" Hardtop Coupe" →
(Found In) Mission District (San Francisco, California): 1972 Toyota Crown Mark II Station Wagon
Out of the Japanese brands that landed in the American Market during the 1950's and 1960's, Toyota learned the quickest how to adapt to the foreign to them trends that set the Jones's hearts alight. One trend realized was the splintering of the American Market, as the generation of Boomers headed to dealerships, they weren't happy with one-size fits all motoring in escalating finery that had dominated the automotive landscape from The Great Depression through the Fabulous Fifties.
Indeed, after landing a hit with the Corona during the 2nd half of the 1960's, Toyota went above and below, bringing the baby bear Corolla and the Papa Bear Crown stateside. For those moving immediately out of their Coronas could find themselves in the Mama Bear Corona Mark II.
Continue reading "(Found In) Mission District (San Francisco, California): 1972 Toyota Crown Mark II Station Wagon" →
04/10/2017 04/10/2017 Laurence Jones 1970s, Coupe, Fuselage, Mopar, Muscle Cars, Orphan Brand, Outside in Oakland, Plymouth
(Found In) McClymonds (Oakland, California): 1972 Plymouth Satellite Sebring 2 Door Hardtop Coupe
Chrysler Corporation products of the early 1970's embraced more fully than any other brand of car the intergalactic possibilities and fantasies of Science Fiction in the earthbound chariots they offered to consumers. Going from rectilinear boxes of the 1960's, Chrysler flooded every sight line with bulbous curves with their new Fuselage look for everything above the Valiant and Dart.
First filling the largest shadows with the C-Body full sized line, the 1971 re-skin of the intermediate B-bodies took on a futuristic shape that in all irony, would soon lose market share to a heap of neo-classical tastes.
Continue reading "(Found In) McClymonds (Oakland, California): 1972 Plymouth Satellite Sebring 2 Door Hardtop Coupe" →


text:
Viewing: / Notes / 2013 / October / 30 / Relating to grown-ups
Relating to grown-ups
People occasionally ask me why I concocted this blog.
Simple answer: to make the "Business Lessons From Rock" case—namely, that rock & roll bands have much to teach us about developing bold, creative, passionate teams—and to promote my upcoming book of the same name.
But then people say, "What got you going on THAT?"
Well, when I first began management consulting and team training 28 years ago I felt a little dislocated in my new environment. I had played rock & roll for a living until then and had avoided anything resembling a corporate life. So when I started working in business I just couldn't relate to the lack of play, fun, humor, passion, engagement, creativity, personality, chutzpah, and free-thinking independence that I frequently encountered. These were qualities in abundant supply in the music world.
I felt like a kid surrounded by grown-ups who had forgotten how to have fun and be themselves. But as I began to work more closely with leaders I began to see them (even the top executives) as kids also, underneath their well-designed work costumes. Viewing them this way, I could better relate to them—and help liberate them from their limiting beliefs, careful disguises, and blocked self-expression.
15 years later I realized that this was what Tom Peters had been evangelizing in his books and talks. So I began working with Tom's company and got my start as a blogger on his website, which then led me to start this blog.
A decade later, now working on my own, I'm more clear than ever that too many folks in the workforce are dealing with an almost incapacitating fear of being themselves, of thinking for themselves, of expressing themselves, and of standing up for themselves. It's also evident to me that some combination of play, fun, humor, passion, personality, etc. is what's urgently needed to displace that fear.
And—surprise!—these are the very same qualities needed for teams and organizations to be successful in the creative economy.
Here's an earlier post about a band that demonstrates these qualities.
RDF, Steve Jobs, and The Beatles
View the archive »
Never miss a post… get 'em by email or rss »
Joel D Canfield says:
Even the most progressive people-oriented businesses I've worked in could have used an injection of humor and play. I'm glad to see a groundswell of appreciation for balance in those things in current biz lit.
Hurry up with that book.
John G. O'Leary says:
Still waiting for my agent to approve my latest changes. It's basically done. (Famous last words.)
"help liberate them from their limiting beliefs, careful disguises, and blocked self-expression." how?
Short answer: by helping them develop a creative, passionate, celebratory, anything-is-possible mindset—for themselves and their teams. (The longer answer, of course, is in my book.)
Updates & rss