How to add couchbase index replicate without deleting it - couchbase

I have in my environment one secondary index (without replication) and I want to know how do I create the replicates without dropping the index?
I don't want to delete the index and recreate it with the replicates because I am not using the primary index, hence the constraint.
Thanks

Upcoming 6.50 release you can modify index replication count (Example 4) https://docs.couchbase.com/server/6.5/n1ql/n1ql-language-reference/alterindex.html
Another alternative to #Lho Ben solution (CE version) is (9. Duplicate Indexes) described here https://blog.couchbase.com/create-right-index-get-right-performance/

If it's not possible to alter the index replicat count with your Couchbase version:
You should :
Create the same index with different name (this time replicated)
Drop the index not replicated after the creation of the first index.
reference :
https://docs.couchbase.com/server/current/n1ql/n1ql-language-reference/alterindex.html

You can create equivalent indexes with right number of replica count to ensure scans continue to work and drop older index. We support altering replica count through ALTER INDEX in enterprise edition.

Related

Does MySQL obtains a lock on the table while adding a new composite index?

I have a table on production which is causing performance issues. I've identified a few quick indexes I can add to resolve the issue. Does MySQL obtains a lock on the table while adding a new index? Does it depend on the nature of index (unique, composite etc)?
Note that I don't have any specific need to add a new column so won't be running any ALTER command.
A UNIQUE index must check for uniqueness.
Any change to the PRIMARY KEY requires rebuilding the index. (For InnoDB)
New versions of MySQL can add an index with very little impact.
Composite does not matter.
Adding a "new column" is a different question. This, also, "depends". New versions can do such "instantly" if you don't have the "after" clause.

MySQL - Can I create an index only to one particular partition

Since partition also splits the table into subtables, I wanted to know if there is any way to index the partitioned table one by one based on the partition name or id. I am asking this because, my table can have 1 Billion+ rows and add index query takes long hours/day, so wanted to check if I can start adding index based on the partition that I think is more important first or vice versa.
No, MySQL has no syntax to support creating indexes on a partitioned table one partition at a time. The index will be added to all partitions in one ALTER TABLE or CREATE INDEX statement.
At my company, we execute schema changes using pt-online-schema-change, a script that allows clients to continue reading and writing the table while the alter is running. It might even take longer to run the schema change, but since it doesn't block clients, this doesn't cause a problem.
The script is part of the Percona Toolkit, which is a free, open-source collection of tools written in Perl and Bash.

Creating a index before a FK in MySQL

I have a not so big table, around 2M~ rows.
Because some business rule I had to add a new reference on this table.
Right now the application is writing values but not using the column.
Now I need to update all null rows to the correct values, create a FK, and start using the column.
But this table has a lot of reads, and when I try to alter table to add the FK the table is locked and the read queries get blocked.
There is any way to speed this?
Leaving all fields in NULL values helps to speed up (since I think there will be no need to check if the values is valid)?
Creating a index before helps to speed up?
In postgres I could create a not valid FK and then validate it(which caused only row lock, not table lock), there is anything similar in MySQL?
What's taking time is building the index. A foreign key requires an index. If there is already an index on the appropriate column(s), the FK will use it. If there is no index, then adding the FK constraint implicitly builds a new index. This takes a while, and the table is locked in the meantime.
Starting in MySQL 5.6, building an index should allow concurrent read and write queries. You can try to make this explicit:
ALTER TABLE mytable ADD INDEX (col1, col2) LOCK=NONE;
If this doesn't work (like if it gives an error because it doesn't recognize the LOCK=NONE syntax), then you aren't using a version of MySQL that supports online DDL. See https://dev.mysql.com/doc/refman/5.6/en/innodb-online-ddl-operations.html
If you can't build an index or define a foreign key without locking the table, then I suggest trying the free tool pt-online-schema-change. We use this at my job, and we make many schema changes per day in production, without blocking any queries.

CREATE INDEX MySQL 5.6.13 On Production Database

I am running MySQL 5.6.13 and I would like to run a CREATE INDEX ... BTREE statement on my production database.
The table is InnoDB and has ~ 4 million rows, and I would like very much not to lock it.
According to the docs, it appears as if this statement will not completely lock my table and return quickly. But, I wanted a second opinion before I made this change.
Would it be safe to create this index?
By default, InnoDB in MySQL 5.6 will perform a read lock while creating the index, so you can still have other concurrent clients SELECT from the table, but not do insert/update/delete on that table while the index is being created.
You can optionally allow the index creation to be completely online and not even do the read lock:
ALTER TABLE my_table ADD INDEX a (a), LOCK=NONE;
See http://dev.mysql.com/doc/refman/5.6/en/innodb-create-index-overview.html for more details about online DDL statements in MySQL.
Also see this blog posted today from a MySQL Community Manager: Top 10 advances to availability since MySQL 5.5
PS: It's not necessary to specify BTREE for the index type. InnoDB supports only BTREE indexes, so it ignores that option.

Impact of extending a column that's a part of a multicolumn primary key on index

I need to extend a column in a quite big table (~90M rows). (MySQL 5.1, InnoDB)
It's a varchar(15) column that needs to be extended to varchar(20).
This column is a part of the primary key.
I did some reading in the mysql documents and it looks like a temporary table will be created for that process and at the end there will be a swap done. So it won't lock the table.
But how will be the index rebuild look? I assume it will have to be modified or not?
Will it be rebuild 'on side' and then swapped, so no major impact?
I'm concerned about the performance once the alteration is made.
Cheers!
nobody seemed to know the answer so I reached out to the MySQL community forum.
Here's the thread: http://forums.mysql.com/read.php?22,572693,572865#msg-572865
In shortcut:
The index will be re-created during the data copy to the temporary table.
It will be in place during the table swap.