Dear list,
I need to add an index for a new attribute in an active-active replication scenario.
I know I need to run slapindex to create the index for existing entries after I changed the configuration file (yes, still on 2.4 with slapd.conf). But what is the correct procedure to update both servers? I'm a bit worried that the setup will become out-of-sync if I just update one server at a time. Would it be better to stop the service on both servers and re-index the databases at the same time before going online again?
Regards,
Uwe
--On Wednesday, September 14, 2022 6:03 PM +0200 Uwe Sauter uwe.sauter.de@gmail.com wrote:
Dear list,
I need to add an index for a new attribute in an active-active replication scenario.
I know I need to run slapindex to create the index for existing entries after I changed the configuration file (yes, still on 2.4 with slapd.conf). But what is the correct procedure to update both servers? I'm a bit worried that the setup will become out-of-sync if I just update one server at a time. Would it be better to stop the service on both servers and re-index the databases at the same time before going online again?
Stop server 1 change slapd.conf slapindex -q -f /path/to/slapd.conf -b "your base" <attr name> start server 1
stop server 2 change slapd.conf slapindex -q -f /path/to/slapd.conf -b "your base" <attr name> start server 2
Neither server cares about the indexing in place on the other server. The main issue would be that queries that are expecting the index to exist will be slow until it is in place.
--Quanah
Stop server 1 change slapd.conf slapindex -q -f /path/to/slapd.conf -b "your base" <attr name> start server 1
stop server 2 change slapd.conf slapindex -q -f /path/to/slapd.conf -b "your base" <attr name> start server 2
Neither server cares about the indexing in place on the other server. The main issue would be that queries that are expecting the index to exist will be slow until it is in place.
--Quanah
Thanks Quanah, worked like a charm.
I wasn't sure wether indexing would be sync'd between servers.
Regards,
Uwe
Uwe Sauter uwe.sauter.de@gmail.com schrieb am 14.09.2022 um 17:46 in
Nachricht 449ea0c3-97d9-7228-ef16-a36022c320ad@gmail.com:
Stop server 1 change slapd.conf slapindex -q -f /path/to/slapd.conf -b "your base" <attr name> start server 1
stop server 2 change slapd.conf slapindex -q -f /path/to/slapd.conf -b "your base" <attr name> start server 2
Neither server cares about the indexing in place on the other server. The
main issue would be that
queries that are expecting the index to exist will be slow until it is in
place.
--Quanah
Thanks Quanah, worked like a charm.
I wasn't sure wether indexing would be sync'd between servers.
Using cn=config with replcated configs it's sufficient to add the index to the config: The index is created on each server then.
Regards,
Uwe
--On Thursday, September 15, 2022 8:55 AM +0200 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
I wasn't sure wether indexing would be sync'd between servers.
Using cn=config with replcated configs it's sufficient to add the index to the config: The index is created on each server then.
He already stated he's using slapd.conf, so that's immaterial. But I would note that with large databases it can take a long time to create a new index while waiting on cn=config, and it is likely better to still stop slapd once the index config has replicated and build the new index with slapadd -q as I noted.
--Quanah
Quanah Gibson-Mount wrote:
--On Thursday, September 15, 2022 8:55 AM +0200 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
I wasn't sure wether indexing would be sync'd between servers.
Using cn=config with replcated configs it's sufficient to add the index to the config: The index is created on each server then.
He already stated he's using slapd.conf, so that's immaterial. But I would note that with large databases it can take a long time to create a new index while waiting on cn=config,
There's nothing to wait for. Index generation is in a background thread, it doesn't block cn=config.
--On Thursday, September 15, 2022 5:49 PM +0100 Howard Chu hyc@symas.com wrote:
There's nothing to wait for. Index generation is in a background thread, it doesn't block cn=config. --
On a large DB, it can take several hours until the index is actually ready for use. So if you need it to be functional, it's better to slapindex -q.
--Quanah
Quanah Gibson-Mount quanah@fast-mail.org schrieb am 15.09.2022 um 18:09
in Nachricht <1F341BC71D7ADCBA8A4880D3@[192.168.1.17]>:
‑‑On Thursday, September 15, 2022 5:49 PM +0100 Howard Chu hyc@symas.com wrote:
There's nothing to wait for. Index generation is in a background thread, it doesn't block cn=config. ‑‑
On a large DB, it can take several hours until the index is actually ready for use. So if you need it to be functional, it's better to slapindex ‑q.
But in both cases you can't use it before the index is done. I don't see the big difference.
Regards, Ulrich
‑‑Quanah
--On Friday, September 16, 2022 9:27 AM +0200 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
Quanah Gibson-Mount quanah@fast-mail.org schrieb am 15.09.2022 um 18:09
in Nachricht <1F341BC71D7ADCBA8A4880D3@[192.168.1.17]>:
‑‑On Thursday, September 15, 2022 5:49 PM +0100 Howard Chu hyc@symas.com wrote:
There's nothing to wait for. Index generation is in a background thread, it doesn't block cn=config. ‑‑
On a large DB, it can take several hours until the index is actually ready for use. So if you need it to be functional, it's better to slapindex ‑q.
But in both cases you can't use it before the index is done. I don't see the big difference.
The difference is that slapindex -q <attr> can take a few seconds to a few minutes on a large index, while the background indexer may take numerous hours. If you need that index available immediately to resolve perf issues, it makes alot more sense to use slapindex -q.
--Quanah
openldap-technical@openldap.org
-
Howard Chu -
Quanah Gibson-Mount -
Ulrich Windl -
Uwe Sauter